O que uma auditoria de contrato inteligente diz — e o que não diz

“Auditado” aparece em páginas de destino como se fosse uma certificação com significado definido. Não é. É um serviço profissional de escopo variável, e a diferença entre uma revisão minuciosa e uma superficial é invisível a partir do selo.

O que uma auditoria realmente é

Uma empresa é contratada para revisar um conjunto especificado de contratos, em um commit especificado, durante um período especificado, procurando defeitos em relação a um modelo de ameaças especificado. Ela produz um relatório listando os achados por gravidade, o projeto responde, e um relatório final normalmente registra o que foi corrigido.

Cada uso da palavra “especificado” ali está fazendo um trabalho real. O escopo é negociado, e um relatório sobre três contratos não diz nada sobre o quarto, que é o que guarda os fundos.

Leia primeiro a seção de escopo

O escopo informa quais arquivos foram revisados e em qual hash de commit. Duas perguntas seguem daí, e ambas podem ser respondidas em poucos minutos.

O escopo inclui os contratos que realmente guardam ou movimentam valor, ou apenas contratos periféricos? E o commit revisado corresponde ao que está implantado? O código muda depois de uma auditoria, e um relatório sobre um commit anterior a várias atualizações descreve um software que já não existe. Verificar o bytecode implantado contra o código-fonte auditado é a checagem que fecha essa lacuna, e raramente é feita por quem apenas lê o selo.

Os achados e sua resolução

Os relatórios classificam os achados por gravidade. Mais importante do que a contagem é a resolução: corrigido, reconhecido ou contestado.

“Reconhecido” significa que o projeto leu o achado e optou por não mudar nada. Isso pode ser inteiramente razoável — o achado pode descrever uma troca aceita — mas significa que um problema conhecido está ativo em produção, e isso não vai aparecer em um resumo que só menciona o selo.

Um relatório sem nenhum achado não é um triunfo. Em geral significa um escopo estreito ou uma revisão superficial. Revisões competentes de sistemas não triviais encontram coisas.

Naquilo em que auditorias são estruturalmente fracas

Certas categorias são difíceis de capturar apenas revisando código:

• Falhas de desenho econômico. Código que se comporta exatamente como escrito, mas cujos incentivos criados são exploráveis. Isso exige modelar a economia do sistema, o que é uma disciplina diferente e frequentemente fica fora do escopo.
• Composabilidade. Um contrato pode ser sólido isoladamente e inseguro quando combinado com outro protocolo que ninguém previu.
• Premissas sobre oráculos. Contratos que dependem de dados de preço externos herdam a confiabilidade desses dados, e o oráculo geralmente fica fora do escopo.
• Governança e chaves. Um contrato atualizável controlado por uma multisig pequena tem um risco que nenhuma revisão de código resolve, porque o próprio código permite a atualização por design.

Esse último ponto merece destaque. Se um contrato pode ser atualizado, a auditoria descreve a implementação atual, e os detentores das chaves de atualização podem substituí-la. O que importa então é quem são esses detentores e qual processo os governa — uma questão de governança disfarçada de selo técnico.

Como é um bom relatório

Publicado na íntegra, não resumido. Escopo declarado com hashes de commit. Achados com gravidade, descrição e resolução. Uma seção de metodologia descrevendo o que foi e o que não foi examinado. E uma data, para que se possa comparar com o histórico de implantações.

Um projeto que publica tudo isso está fazendo algo bem diferente de um que apenas exibe um logotipo. O logotipo é a parte mais barata.

Como usar uma auditoria

Trate uma auditoria como evidência de que um projeto gastou dinheiro com escrutínio e se dispôs a publicar o resultado, o que é um sinal real sobre como ele opera. Não a trate como garantia de segurança, porque o relatório não afirma ser isso — o aviso legal nele geralmente diz isso de forma explícita, na seção que ninguém cita.

As perguntas práticas permanecem: que proporção do seu patrimônio está exposta a esse contrato, você toleraria perdê-la, e o rendimento oferecido é plausivelmente uma compensação por esse risco? Nada disso muda com a existência de um relatório, e é exatamente por isso que o selo é usado da forma como é.

Nem todas as revisões têm a mesma profundidade

“Auditoria” abrange uma gama de atividades com custo e rigor muito diferentes, e o relatório nem sempre deixa essa distinção clara.

Uma revisão manual feita por engenheiros experientes lendo o código é a ponta mais cara. A análise automatizada capta padrões conhecidos com baixo custo e deixa passar qualquer coisa nova. A verificação formal prova matematicamente que o código satisfaz uma especificação, o que é poderoso e vale exatamente o que vale a especificação. Plataformas de auditoria competitiva terceirizam a revisão para uma multidão, o que encontra uma ampla gama de problemas mas produz uma cobertura menos consistente.

Cada abordagem tem seu papel. O que importa é saber qual delas você está vendo, e a seção de metodologia diz isso. Um relatório que não descreve seu método está pedindo para ser aceito apenas com base na força do logotipo.

Programas de recompensa por bugs dizem algo que um relatório não consegue

Uma auditoria é um retrato de um momento; um programa de recompensa por bugs é contínuo. Um projeto que mantém um programa substancial e bem delimitado, com histórico público de pagamentos, está exposto a um escrutínio permanente que uma revisão pontual não oferece.

O tamanho importa. Um pagamento máximo muito abaixo do que uma exploração renderia não é um incentivo, é um gesto — um pesquisador que encontra uma falha crítica em um contrato que guarda uma soma grande enfrenta um problema aritmético óbvio se a recompensa for irrisória em comparação. Recompensas proporcionais ao valor em risco são um sinal genuíno de quão a sério um projeto leva a possibilidade de estar errado.

Tempo em produção também é evidência

Contratos que mantiveram valor significativo por um longo período sem incidentes foram submetidos à revisão mais rigorosa disponível: atenção sustentada de pessoas financeiramente motivadas a quebrá-los.

Isso não é prova — falhas adormecidas existem, e vários protocolos de longa existência falharam tardiamente. Mas um contrato recém-implantado, com um relatório e nenhum histórico de operação, foi revisado por uma única empresa durante algumas semanas. Um contrato mais antigo com o mesmo relatório também sobreviveu a anos de interesse adversarial, e isso é um tipo de evidência diferente.

Combinar as duas coisas é a abordagem prática: leia o relatório para saber o que foi examinado, e avalie o histórico de implantação para o que o relatório não conseguiu cobrir.