Risco de contratos inteligentes em DeFi: auditorias e falhas

O risco de contratos inteligentes em DeFi é a possibilidade de que erros de código, premissas frágeis de projeto ou controles administrativos mal desenhados causem perdas, mesmo quando o protocolo funciona “como programado”. Uma auditoria reduz esse risco ao submeter o código a revisão especializada, mas não o elimina: a documentação técnica da comunidade Ethereum afirma que auditorias de contratos inteligentes não pegam todos os erros.

O que é um contrato inteligente e por que o risco é diferente

Contrato inteligente é um programa executado em uma blockchain que mantém estado (por exemplo, saldos) e libera ações conforme regras escritas em código. Em finanças descentralizadas (DeFi), contratos desse tipo fazem o papel de corretoras ou mercados de empréstimo, sem um intermediário que possa interromper ou corrigir cada operação.

Três características elevam o risco em relação ao software tradicional:

• Contratos, por padrão, são imutáveis depois de implantados; corrigir um erro costuma exigir um mecanismo de atualização, que traz outros riscos.
• O código controla ativos de valor diretamente e é público, o que permite que atacantes o estudem.
• Transações confirmadas em blockchain geralmente não podem ser desfeitas por quem as sofreu.

Tipos de falha mais comuns

Reentrância

Reentrância ocorre quando um contrato chama outro (ou envia valor) antes de concluir a atualização do próprio estado, e o contrato chamado volta a invocar a função original. A documentação oficial da linguagem Solidity descreve o exemplo clássico: uma função de saque que envia o saldo antes de zerá-lo permite que o destinatário malicioso saque repetidas vezes. A mitigação documentada é a ordem “verificações, efeitos, interações”: validar, atualizar o estado e só então chamar contratos externos. A mesma documentação recomenda ainda o padrão em que o destinatário retira os fundos por conta própria, em vez de o contrato enviá-los.

Erros de lógica

São falhas em que o código faz exatamente o que foi escrito, mas não o que se pretendia: cálculos de taxa incorretos, regras de liquidação com brechas, validações ausentes. A documentação do Solidity lembra que mesmo um contrato sem erros pode ser afetado por defeitos do compilador ou da plataforma.

Oráculos

Oráculo é o mecanismo que leva dados externos (como preços) à blockchain. Segundo o ethereum.org, um contrato só é tão confiável quanto o dado que recebe, e os oráculos obrigam a confiar nos operadores da informação, o que enfraquece a premissa de “ausência de confiança”. Segundo a página do ethereum.org sobre segurança de contratos, um atacante pode inflar artificialmente o preço à vista de um ativo com um empréstimo relâmpago (flash loan) e, assim, distorcer um oráculo que dependa desse preço. Entre as mitigações descritas estão redes de oráculos descentralizadas, que combinam várias fontes, e preços médios no tempo (TWAP), que ficam mais resistentes a manipulações de curto prazo quanto maior o período considerado.

Chaves administrativas e capacidade de atualização

Muitos protocolos têm contas com poderes especiais: pausar, alterar parâmetros, trocar a lógica do contrato. O padrão comum de atualização usa um proxy, contrato que guarda o estado e encaminha as chamadas para um contrato de lógica que pode ser trocado. A documentação da OpenZeppelin explica que o administrador do proxy pode ser um endereço simples, uma carteira multiassinatura ou uma estrutura de governança complexa; quem o controla pode substituir a lógica do contrato.

O ethereum.org aponta que um único endereço “dono” é um ponto único de falha. As mitigações citadas incluem controle de acesso por funções, carteiras multiassinatura (M de N aprovações) e atraso programado (timelock). Um protocolo descrito como “descentralizado” pode, assim, ter pontos centrais de controle, o que é fator de risco a avaliar.

Caso documentado: The DAO (2016)

The DAO foi uma “organização autônoma descentralizada” criada por uma empresa alemã, a Slock.it, e seus cofundadores. Segundo o relatório de investigação da SEC (Release 81207, de 25 de julho de 2017), entre 30 de abril e 28 de maio de 2016 ela vendeu cerca de 1,15 bilhão de tokens em troca de aproximadamente 12 milhões de ether, avaliados em cerca de US$ 150 milhões ao término da oferta. Antes de financiar qualquer projeto, um atacante usou uma falha no código para subtrair aproximadamente um terço dos ativos. Segundo o relatório, o ataque ocorreu em 17 de junho de 2016, e cerca de 3,6 milhões de ETH foram desviados. Os fundadores e outros defenderam então uma alteração no protocolo do Ethereum (um “hard fork”), ativada em 20 de julho de 2016 após adesão da maioria da rede, que devolveu os fundos a um endereço de recuperação, de onde os detentores poderiam trocar seus tokens por ETH. Um grupo minoritário não adotou a mudança, por entender que ela contrariava a ideia de que um blockchain é imutável, e seguiu na versão anterior, hoje conhecida como Ethereum Classic.

O relatório da SEC também concluiu, naquele caso e sob aqueles fatos, que os tokens da DAO eram valores mobiliários sob a lei americana, e que a automação por contratos inteligentes não retira uma atividade do alcance da lei de valores mobiliários. A SEC decidiu não abrir ação de enforcement. O relatório se refere apenas a “uma falha no código” e a vulnerabilidades no código; não descreve a classe técnica da falha. A associação do episódio com reentrância é comum na literatura técnica, mas não consta da fonte primária consultada e, por isso, não é afirmada aqui. O relatório também registra que a Slock.it divulgou que o código havia sido revisado por uma empresa de auditoria de segurança; ele não avalia o escopo nem a qualidade dessa revisão, e por isso o episódio não permite concluir nada sobre a eficácia de auditorias em geral.

O episódio é lembrado por mostrar que código com ativos reais exige revisão rigorosa e que “o código é a regra” convive com a realidade jurídica e social em torno do projeto.

Outros casos documentados

Os dois casos abaixo, de 2022, são descritos apenas com o que as próprias fontes afirmam. As fontes os descrevem como problemas de chaves e operação (Ronin) e de governança (Beanstalk), e não como reentrância ou erro de cálculo; ilustram que o risco em DeFi também está em chaves, operação e governança, pontos que uma auditoria de código pode não alcançar.

• Ronin (março de 2022): conforme o relatório pós-incidente da própria Ronin, em 23 de março de 2022 foram retirados da ponte (bridge) da rede 173.600 ETH e 25,5 milhões de USDC. O invasor obteve controle de cinco das nove chaves de validadores (quatro da Sky Mavis e uma da Axie DAO) e forjou saques; segundo o relatório, o ataque partiu do comprometimento de um funcionário por phishing e usou uma permissão de assinatura de 2021 que não havia sido revogada. O incidente só foi percebido em 29 de março, por falta de monitoramento de grandes saídas. O FBI declarou, em 14 de abril de 2022, ter confirmado que os grupos Lazarus e APT38, associados à Coreia do Norte, são responsáveis pelo furto de US$ 620 milhões em Ethereum.
• Beanstalk (abril de 2022): segundo a equipe do protocolo, em 17 de abril de 2022 um atacante usou um empréstimo relâmpago para explorar o mecanismo de governança, resultando no furto de cerca de US$ 77 milhões em ativos de usuários de fora do Beanstalk. A equipe descreveu o problema como “previamente desconhecido” e suspendeu a governança e o protocolo.

Os valores são os informados pelas próprias fontes e podem diferir de outras estimativas.

O que uma auditoria cobre e o que não cobre

Uma auditoria é a revisão, por especialistas independentes, do código-fonte e do projeto em um momento determinado. O ethereum.org a descreve como uma rodada adicional de revisão, que pode apanhar problemas que os desenvolvedores não viram. O escopo exato é definido caso a caso entre o protocolo e a auditora e deve constar do relatório; dependendo desse escopo, pode incluir:

• revisão manual de padrões de vulnerabilidade conhecidos;
• análise com ferramentas automatizadas e testes;
• recomendações de correção e verificação de que foram aplicadas.

Costuma ficar fora, ou coberto apenas parcialmente:

• erros não identificados: o ethereum.org afirma que “auditorias de contratos inteligentes não pegarão todos os bugs”;
• alterações posteriores ao código auditado, inclusive atualizações via proxy, e integrações com contratos de terceiros;
• risco econômico (desenho de incentivos, dependência de oráculos, liquidez);
• risco operacional e de chaves, como a gestão de carteiras administrativas;

Segundo o ethereum.org, auditorias podem ser complementadas por programas de recompensa por falhas (bug bounty), testes de fuzzing e verificação formal, esta última capaz de provar a ausência de erros apenas em relação às propriedades que foram especificadas. Nenhuma dessas práticas oferece garantia absoluta contra perdas.

Sinais a observar

• Existência de relatórios de auditoria de empresas independentes, com data, escopo e versão do código; se os achados críticos foram corrigidos; programa de bug bounty.
• Se o código em produção corresponde ao auditado e se houve atualizações posteriores.
• Quem controla chaves administrativas: um endereço único, multiassinatura ou governança; existência de atraso programado antes de mudanças.
• Dependência de oráculos e de quais fontes de preço, e de outros protocolos.
• Transparência da equipe e da documentação sobre limites e riscos conhecidos, e resposta a incidentes passados.

Fechamento

A segurança de um protocolo DeFi é uma soma de código, economia, governança e operação, e cada camada pode falhar. Auditoria é uma camada útil, não um selo de segurança. Em contexto pessoal ou empresarial, a avaliação merece ser feita caso a caso, com apoio técnico e jurídico quando apropriado; o contato está disponível. Este texto é informativo e não constitui recomendação de investimento.