Ir para o conteúdo
Financial Context Wiki

Como interpretar uma auditoria de smart contracts

Uma auditoria de smart contracts é uma revisão delimitada de código, builds, implantações, premissas e propriedades especificadas; achados e correções devem ser conciliados com o sistema em produção.

Atualizado

Somente para fins educacionais; não constitui aconselhamento de investimento ou segurança. Relatório, resultado de ferramenta, achado resolvido ou fonte correspondente não é certificação, seguro, indenização nem prova de segurança da implantação.

Resposta direta

Uma auditoria examina, por período declarado, requisitos, código, entradas de build, lógica de implantação e premissas especificadas. Métodos complementares identificam defeitos, demonstram exploits, avaliam impacto e conferem correções. A conclusão vale apenas para o snapshot e as evidências do relatório.

O snapshot fixa repositório e commit ou tree hash, submódulos, dependências, compilador, configurações, código gerado, scripts, chains, endereços, proxy, implementação ou beacon, constructor ou initializer, bibliotecas, administradores, timelocks e bloco ou hora. Exclusões importam: frontend, keeper, oracle, bridge, governança ou signatário off-chain podem dominar o risco fora do escopo.

São necessários threat model e especificação: ativos, atores, papéis, fronteiras de confiança, capacidades, ordenação, reorgs, dependências, transições e propriedades de safety e liveness. Invariante sem unidades, precondições, quantificadores e exceções pode verificar perfeitamente a conduta errada.

Use quatro registros: identidade de escopo, build e implantação; requisitos, ameaças e invariantes; achados, evidências e reteste; risco residual, aceitação e divulgação. Ausência de critical não certifica segurança, resolved não implica implantação e uma prova cobre apenas propriedade, modelo e premissas codificados.

Como funciona

Revisão manual acompanha arquitetura, fundos, estado entre funções e intenção econômica. Análise estática detecta padrões e fluxos, mas gera falsos positivos e negativos. Testes unitários, integração, fork e diferenciais comparam condutas concretas. Fuzzing com estado e invariantes dependem de handlers, seletores, seeds, corpus, execuções, profundidade e ambiente modelado.

Execução simbólica e verificação formal demonstram asserções selecionadas sob semântica e premissas compatíveis. Resultado unknown, timeout ou comportamento sem suporte não é prova. Mesmo uma propriedade provada pode omitir economia do oracle, governança, configuração, chain ou requisito pretendido. A revisão humana responde pela especificação; observação de IA não é método independente.

Cada achado identifica artefato e implantação, pré-requisito, PoC mínimo, caminho, alcance, privilégios, capital, repetibilidade, impacto, rubrica e recomendação. Explorabilidade ou probabilidade e impacto são dimensões separadas. Máximo teórico, nome da falha ou etiqueta de ferramenta não estabelece perda executável.

open, acknowledged, risk accepted, partially fixed, resolved e retested não são padrões universais. Fechamento defensável liga o problema ao commit exato, registra caminhos alterados e adjacentes e quem retestou o quê e quando. Risco aceito continua risco; reteste limitado não amplia o escopo.

Implantações atualizáveis exigem conciliação: slots do proxy, implementação ou beacon e admin; initializer/reinitializer, bloqueio da implementação, compatibilidade de storage, autorização, timelock ou bypass, migração e rollback. Reproduza bytecode de criação e runtime e compare bibliotecas, parâmetros, papéis e estado em cada chain.

O relatório final informa revisão, auditores, datas, escopo, métodos, configurações, limites, achados, evidências, remediação, riscos e divulgação. Depois, monitore hashes, papéis, parâmetros, dependências e incidentes. Mudança material cria novo delta; badge antigo não acompanha código futuro.

Fluxo:

  1. Congele manifesto: repositório, commit, dependências, compilador, configurações, código gerado e de implantação, chains, endereços, proxy, parâmetros, bloco, revisão, inclusões e exclusões.
  2. Defina ativos, atores, papéis, fronteiras, capacidades, ciclo de vida, ordenação, liveness, dependências e invariantes mensuráveis.
  3. Reproduza o build e mapeie arquitetura, storage, dados, fundos e controle; concilie fonte, artefatos, bibliotecas, bytecode, initializer, papéis e implantação.
  4. Execute métodos manuais, estáticos, unitários, integração, fork, diferenciais, fuzz, invariantes, simbólicos ou formais, registrando versões, configurações, seeds, corpus, cobertura, timeouts e incógnitas.
  5. Registre artefato, pré-requisito, prova, explorabilidade, impacto, severidade, exposição, recomendação e evidência confidencial sem tratar etiqueta como julgamento.
  6. Congele a correção e reteste problema, caminhos e invariantes; valide storage, inicialização, migração, rollback, build e recibos antes de atribuir status.
  7. Publique escopo, métodos, limites e riscos; concilie artefatos em cada chain e mantenha monitoramento, divulgação, resposta e bug bounty atuais.

Exemplos

  • Inflação de vault exige registro completo. O atacante deposita 1 asset, recebe 1 share e doa 1,000,000 assets; ficam 1,000,001 assets e 1 share. A vítima deposita 500,000 assets; o piso inseguro dá floor(500,000 * 1 / 1,000,001) = 0 shares. Se aceito, há 1,500,001 assets; o atacante resgata e ganha 500,000 assets sobre sua contribuição de 1,000,001-asset. Se zero shares reverte, a perda não ocorre.
  • Cobertura de arquivos não é cobertura da implantação. Há 24 source units, 4 deployment scripts e 3 keeper services: 31 items. Entram 20 source units e 2 scripts; cobertura 22 / 31 = 70.96774194%, com 9 items excluídos. Se o proxy usa unidade excluída, a implementação tem 0% apesar de 70.96774194%.
  • Fuzz não prova ausência. A execução faz 2,000 sequences * 64 calls = 128,000 calls; falha em 3 sequences, ou 3 / 2,000 = 0.15%. Após correção, 10,000 sequences * 64 calls = 640,000 calls não falham. É zero no corpus; sob independência e gerador estável, o limite aproximado de 95% é 3 / 10,000 = 0.03% por sequência.
  • Fechamento e identidade são independentes. Há 12 findings: 2 critical, 3 high, 4 medium, 3 low. Fecham 2 + 2 + 3 + 2 = 9: 9 / 12 = 75%; restam high, medium e low. Hash auditado H1, implantação H2: verificação falha. Trocar por H1 e conciliar slot, initializer e papéis prova identidade só no bloco.

Riscos

  • Repositório, commit, submódulo ou fonte gerada são ambíguos.
  • Compilador, otimizador, bibliotecas ou dependências não estão fixados.
  • Scripts, constructor, initializer ou salt CREATE2 são excluídos.
  • Chain, endereço, proxy, beacon ou implementação errados são inspecionados.
  • Fonte, artefato e bytecode não conciliam.
  • Threat model omite ator, privilégio, ativo ou fronteira.
  • Especificação ou invariante tem unidades, precondições ou exceções erradas.
  • Caminhos de admin, guardian, timelock, pausa, upgrade ou migração são omitidos.
  • Premissas de oracle, token, bridge, keeper, governança ou chain falham.
  • Análise estática gera falso positivo sem triagem.
  • Revisão, teste ou fuzzing omite caminho não gerado.
  • Harness, selector, seed, corpus, profundidade ou modelo são enviesados.
  • Timeout, semântica sem suporte ou unknown são tratados como prova.
  • Prova correta formaliza requisito ou sistema incompleto.
  • Severidade é ancorada no nome, não em explorabilidade e impacto.
  • Valor teórico é confundido com perda alcançável ou lucro.
  • Correção introduz regressão ou quebra invariante econômico.
  • Storage, initializer, upgrade ou migração corrompem estado.
  • Problema aceito, aberto ou parcial é ocultado pelo badge.
  • Relatório é tratado como seguro, certificação ou cobertura permanente.

Erros comuns

  • “Sem critical, o contrato é seguro.” Só descreve achados no escopo, tempo e métodos.
  • “Alta cobertura ou zero falhas fuzz provam ausência.” Medem código e caminhos selecionados.
  • “Verificação formal prova todo o protocolo.” Prova propriedades do modelo sob premissas.
  • “Resolved significa todas as implantações corrigidas.” Exige reteste e conciliação de build, bytecode, proxy, parâmetros e papéis.
  • “Auditor reputado garante indenização ou upgrades.” Responsabilidade depende do contrato e mudanças posteriores ficam fora.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...