A verificação de contratos no Ethereum relaciona o código-fonte legível ao bytecode de um endereço de contrato específico. A pergunta central é se o código-fonte e os parâmetros de compilação apresentados reproduzem o código comparado. Uma correspondência fornece evidência dessa relação. Correção, auditoria independente e segurança exigem outras evidências.
Para interpretar um selo de código verificado, examine o endereço, os parâmetros de compilação e o tipo de correspondência informado. Este artigo explica essas diferenças e apresenta um checklist para consultar registros existentes, apenas por leitura.
Código-fonte e bytecode implantado
Desenvolvedores escrevem contratos inteligentes em uma linguagem de alto nível, como Solidity. Depois, compilam esse código-fonte em bytecode para que a máquina virtual Ethereum, a EVM, execute a lógica do contrato. Código-fonte e bytecode representam etapas relacionadas do programa, mas oferecem formas diferentes de examiná-lo.
A verificação de código-fonte confere se determinado código compila para o bytecode executado no endereço de contrato identificado. O endereço delimita a afirmação: o resultado diz respeito àquele alvo de comparação. Não deve ser estendido a todo contrato com nome ou descrição semelhante.
O benefício prático é a legibilidade. O código-fonte verificado facilita investigar o comportamento do contrato em uma linguagem de alto nível, sem precisar ler instruções de máquina. Isso permite uma análise, mas não comprova que alguém tenha realizado uma avaliação de segurança. Essas distinções estão na documentação do Ethereum sobre verificação de código-fonte.
Se precisar retomar os conceitos básicos, consulte o guia sobre código, estado e funções de um contrato inteligente no Ethereum. Aqui, o foco é a correspondência entre o código publicado e o bytecode comparado.
O que uma correspondência reproduzível comprova
A compilação é determinística quando utiliza os mesmos arquivos de código-fonte e as mesmas configurações. Entre as configurações relevantes estão a versão do compilador e os parâmetros do otimizador. Portanto, a reprodução depende do conjunto de entradas, e não apenas de uma listagem de código considerada isoladamente.
Uma correspondência relaciona essas entradas ao bytecode comparado. Ao consultar um registro de verificação, procure quais arquivos e configurações ele descreve. Informar somente o nome do compilador deixa essa descrição incompleta.
A explicação simplificada também tem limites. A documentação do Ethereum apresenta a recompilação seguida de comparação como uma simplificação e menciona exceções, incluindo contratos com variáveis imutáveis. Este artigo não detalha como as ferramentas tratam esses casos. Uma divergência concreta exigiria examinar seus detalhes; esse resumo não permite diagnosticar sua causa.
A conclusão deve manter esse alcance: as entradas informadas corresponderam ao código segundo o método de comparação descrito. Para saber se a evidência também estabelece a identidade exata dos arquivos de código-fonte, é necessário observar o tratamento dos metadados.
Correspondência completa e parcial têm alcances diferentes
Algumas diferenças no código-fonte, como comentários e nomes de variáveis, podem deixar o bytecode compilado inalterado. Por isso, arquivos diferentes podem corresponder ao mesmo bytecode quando suas diferenças não afetam a comparação. Um comentário legível deve ser avaliado como explicação; a correspondência do bytecode, sozinha, não comprova que aquele comentário estava no código original.
A documentação descreve uma verificação mais forte de identidade que considera o hash dos metadados anexado ao bytecode. Quando tanto o bytecode quanto esse hash correspondem ao código-fonte e às configurações apresentados, o método de verificação completa descrito estabelece a identidade exata do código-fonte, byte por byte.
Essa conclusão depende de a comparação necessária realmente apresentar correspondência. Quando os hashes dos metadados diferem ou não são considerados, a documentação fornecida chama o resultado de correspondência parcial. Ao descrever a evidência, preserve a categoria informada.
Se o registro não explicar como os metadados foram tratados, deixe em aberto a força da conclusão sobre a identidade do código-fonte. Mesmo uma identidade exata continua sendo um resultado sobre identidade: ela não comprova a correção ou a segurança do comportamento do programa.
Por que verificado não comprova auditoria ou segurança
Uma auditoria é uma forma de revisão independente do código. Já a verificação formal avalia a correção em relação a propriedades especificadas, usando um modelo e uma especificação formais. Ambas tratam de questões que vão além de reproduzir bytecode. As conclusões formais também ficam limitadas às propriedades, à especificação e ao modelo envolvidos.
Auditorias têm limites. O guia de segurança de contratos inteligentes do Ethereum explica que elas não encontram todos os bugs. A evidência de uma revisão deve conservar esse limite, sem ser transformada em garantia geral de segurança.
A dedução é a seguinte: como a correspondência estabelece uma relação entre código-fonte e bytecode, enquanto auditorias e métodos formais avaliam outras questões, o resultado de verificação de código-fonte, isoladamente, não comprova auditoria, correção ou segurança. Isso também não significa que um contrato verificado seja necessariamente inseguro, incorreto ou não auditado. Essas conclusões precisam de evidências próprias.
Exemplo hipotético: dois registros de verificação
Imagine uma atividade didática com dois registros fictícios para um único endereço de contrato inventado. O registro A identifica arquivos de código-fonte, configurações do compilador e uma correspondência de bytecode, mas informa que os metadados foram excluídos. O registro B identifica seus arquivos e configurações e informa correspondência tanto do bytecode quanto do hash dos metadados anexado. Essas condições pertencem ao exemplo hipotético; não são observações sobre um contrato real.
Na terminologia da documentação, o registro A descreve uma correspondência parcial. O registro B descreve uma correspondência completa segundo o método apresentado. A diferença está na força da evidência de identidade do código-fonte: B inclui a comparação dos metadados necessária para a conclusão de identidade exata.
Agora suponha que nenhum dos registros apresente evidência de revisão independente. A dedução é que esses registros não comprovam uma auditoria. Também seria injustificado afirmar que nenhuma auditoria jamais ocorreu. O exercício mostra como registrar uma lacuna sem substituí-la por tranquilização ou acusação.
Checklist de evidências para uma consulta somente de leitura
O checklist abaixo é uma dedução editorial baseada nos requisitos da comparação e no papel separado da revisão de segurança. Use-o para organizar registros e documentação existentes.
- Identifique o alvo. Registre o endereço de contrato ao qual o resultado de verificação se aplica.
- Identifique as entradas. Anote os arquivos de código-fonte e as configurações de compilação, incluindo a versão do compilador e a configuração do otimizador informadas.
- Leia o resultado. Diferencie uma correspondência explicitamente relatada de uma listagem de código cujo resultado de comparação não foi especificado.
- Preserve a categoria. Registre se os hashes dos metadados corresponderam, divergiram ou foram excluídos. Se a categoria não estiver explicada, mantenha a questão em aberto.
- Separe as evidências de segurança. Registre revisões independentes ou análises formais separadamente, conservando o escopo e os limites das conclusões documentadas.
- Escreva apenas a conclusão sustentada. Descreva o que correspondeu e o que permanece sem comprovação. Preencher este checklist não certifica segurança.
Se faltar uma evidência necessária, a conclusão correspondente permanece aberta para revisão. Uma explicação útil torna esse limite visível, em vez de atribuir à palavra verificado mais significado do que o registro sustenta.
Material educativo preparado com auxílio de IA a partir da documentação primária fornecida. O exemplo fictício serve para exercitar a interpretação de evidências.