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, ao longo de um período especificado, procurando defeitos diante de um modelo de ameaças especificado. Ela produz um relatório que lista os achados por severidade, o projeto responde, e um relatório final normalmente registra o que foi corrigido.

Cada ocorrência de “especificado” ali está cumprindo uma função. O escopo é negociado, e um relatório sobre três contratos não diz nada sobre o quarto, aquele que guarda os fundos.

Leia primeiro a seção de escopo

O escopo diz quais arquivos foram revisados e em qual hash de commit. Daí seguem duas perguntas, e ambas podem ser respondidas em poucos minutos.

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

Os achados e a sua resolução

Os relatórios classificam os achados por severidade. O que importa mais do que as contagens é a resolução: corrigido, reconhecido ou contestado.

“Reconhecido” significa que o projeto leu o achado e escolheu não mudar nada. Isso pode ser inteiramente razoável — o achado pode descrever uma contrapartida aceita — mas significa que um problema conhecido está no ar, e ele não vai aparecer num resumo que só reporta o selo.

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

Em que as auditorias são estruturalmente ruins

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

• Falhas de desenho econômico. Código que se comporta exatamente como foi escrito, em que os incentivos que ele cria são exploráveis. Isso exige modelar a economia do sistema, que é uma disciplina diferente e frequentemente está fora do escopo.
• Componibilidade. Um contrato pode ser sólido sozinho e inseguro quando combinado com outro protocolo que ninguém antecipou.
• Premissas do oráculo. Contratos que dependem de dados externos de preço 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 multiassinatura pequena tem um risco que nenhuma revisão de código aborda, porque o código permite a atualização por projeto.

Esse último merece ênfase. Se um contrato pode ser atualizado, a auditoria descreve a implementação atual e quem detém as chaves de atualização pode substituí-la. O que importa então é quem são essas pessoas e que processo as governa — uma questão de governança usando um selo técnico.

Como é um bom relatório

Publicado na íntegra em vez de resumido. Escopo declarado com hashes de commit. Achados com severidade, 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 você possa compará-lo com o histórico de implantação.

Um projeto que publica tudo isso está fazendo algo sensivelmente diferente de um que exibe um logotipo. O logotipo é a parte que custa menos.

Como usar uma

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 alega ser uma — o aviso legal nele geralmente diz isso explicitamente, na seção que ninguém cita.

As perguntas práticas permanecem: que proporção das suas posições está exposta a este contrato, você toleraria perdê-la, e o rendimento oferecido é plausivelmente uma compensação por esse risco? Nada disso muda com a presença de um relatório, que é exatamente por que o selo é usado do jeito que é.

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

“Auditoria” cobre uma gama de atividades com custo e rigor muito diferentes, e o relatório nem sempre torna a distinção óbvia.

Uma revisão manual feita por profissionais de engenharia experientes que leem o código é o extremo caro. A análise automatizada capta padrões conhecidos de forma barata 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 tanto quanto a especificação. Plataformas de auditoria competitiva distribuem a revisão para uma multidão, o que encontra uma ampla gama de problemas mas produz uma cobertura menos consistente.

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

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

Uma auditoria é um instantâneo; 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, fica exposto a um escrutínio contínuo que uma revisão pontual não oferece.

O tamanho importa. Um pagamento máximo muito abaixo do que um exploit renderia não é um incentivo, é um gesto — quem encontra uma falha crítica num contrato que guarda uma soma grande enfrenta um problema aritmético óbvio se a recompensa for trivial em comparação. Recompensas dimensionadas 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 guardaram valor significativo por um longo período sem incidentes passaram pela revisão mais rigorosa disponível: a atenção sustentada de pessoas com motivação financeira para quebrá-los.

Isso não é prova — falhas dormentes existem e vários protocolos de longa data falharam tarde. Mas um contrato implantado recentemente, com um relatório e sem histórico de operação, foi revisado por uma empresa durante algumas semanas. Um mais antigo com o mesmo relatório sobreviveu adicionalmente a anos de interesse hostil, e isso é uma qualidade de evidência diferente.

Combinar os dois é a abordagem prática: leia o relatório pelo que foi examinado, e pese o histórico de implantação pelo que o relatório não pôde cobrir.