O Estado Lamentável da Auditoria Web3, E O Que Pode Ser Feito

O Balancer, um protocolo antigo e bem auditado, foi recentemente "hackeado". O Yearn Finance, igualmente bem auditado, também foi. Há anos, o Euler Finance foi "hackeado" através de uma função introduzida em resposta a uma auditoria anterior. O USPD foi auditado antes da implementação e depois o próprio processo de implementação não auditado foi hackeado, levando a uma perda total em cerca de 3 meses após o lançamento. Ninguém que tenha estado atento acredita que as auditorias são uma garantia de que algo é seguro. Muitos questionam se valem alguma coisa.

Isto não é novo. Isto não é um problema da web3. E, na verdade, isto não é uma observação particularmente profunda. Mas as auditorias continuam a ser muito relevantes. Os projetos pagam por auditorias. Os projetos promovem auditorias. As pessoas fingem ler auditorias. Frequentemente, quando um produto auditado é explorado, as pessoas perguntam por que e como isso aconteceu.

Em vez de responder diretamente a qualquer uma dessas questões, vamos analisar algumas auditorias recentes de produtos lançados recentemente. O objetivo aqui não é troçar ou criticar ninguém. Foram selecionadas aleatoriamente, principalmente devido ao foco em coisas recentes. Isso não significa que sejam particularmente más. Nem sequer são assim tão más!

O nosso ponto aqui não é que os auditores estejam a fazer algo errado. Os auditores fazem aquilo que os projetos que os contratam pedem. O âmbito da auditoria é definido pelo projeto. Como exemplo extremo: se Do Kwon tivesse contratado auditores para o seu esquema de stablecoin, eles teriam notado que era potencialmente instável. O problema teria sido marcado como "reconhecido" e nada teria sido feito ou alterado.

Este problema não tem absolutamente nada a ver com estudos como aqueles que afirmavam que o ecossistema Terra-LUNA do Do era altamente robusto. É difícil prever o futuro e esse tipo de estudos é corretamente visto como marketing interesseiro que, no limite, reconhece os problemas centrais. Espera-se que a investigação patrocinada por projetos apresente as coisas de forma positiva. O objetivo principal das auditorias é fornecer uma perspetiva objetiva de terceiros. O exagero não é para ser confiado e as auditorias não são garantias ou seguros. Assim é a vida.

O objetivo desta análise é reforçar que o verdadeiro problema aqui não são os erros básicos de programação do tipo que os auditores estão bem situados para identificar e que o processo de auditoria está bem concebido para resolver. Os auditores são bastante bons a detetá-los. Assim como, aliás, os programadores que constroem estas coisas em primeiro lugar. Empiricamente, este tipo de feedback chega às pessoas certas e os problemas específicos são corrigidos.

Não, o verdadeiro problema são produtos que funcionam exatamente como pretendido e onde um "risco" conhecido se materializa para derrubar tudo. O que vai ver agora são auditores a tentar proteger-se contra todos e quaisquer problemas conhecidos-desconhecidos futuros. Como exercício de proteção contra responsabilidade e troça, talvez isto seja algo valioso. Mas, em termos gerais, não ajuda ninguém.

E depois, no final, vamos discutir o que uma série de partes podem fazer que ajudaria e serviria os seus próprios interesses restritos. Se a sua prescrição para melhorar as auditorias envolve altruísmo, então, bem, não é muito útil.

Jovay

A Jovay é uma L2 associada à Ant Financial ou Alibaba ou algo nessa área geral. Mas não importa realmente o que a Jovay faz. É algo construído em software por uma organização grande e bem financiada. Esta auditoria lista oito problemas:

1. Um erro legítimo de programação que foi posteriormente corrigido.
2. Que o protocolo não é trustless. Isto é um problema de certa forma, mas também é uma parte central do design.
3. O ataque de "recarga falsa" que se aplica a uma ampla faixa do ecossistema e não é específico do projeto.
4. Os servidores RPC usam HTTP em vez de HTTPS. Estas interfaces não processam informações secretas. Isto aplica-se a milhares de milhões de sites perfeitamente seguros somente de leitura.
5. A computação quântica representa um risco para o Ethereum. OK. Muito relevante esse.
6. Os contratos inteligentes EVM podem ser vulneráveis. A sério. Diz "Os contratos inteligentes Evm são suscetíveis a vários vetores de ataque devido à implementação de código imutável e interações complexas, potencialmente levando ao roubo de fundos,.." Ok. Novamente a respeitar realmente o foco restrito desta auditoria.
7. O design do sequenciador está sujeito a MEV. Como todo o resto do ecossistema Ethereum. Também está demasiado escuro à noite.
8. A qualidade do código poderia ser melhorada. Ao contrário da maioria do outro código escrito desde o início da computação.

Apenas um destes é um problema real. Sim, vale a pena notar que o próprio produto não é trustless se a documentação afirmar o contrário que é trustless. Mas este produto está praticamente bem nesse aspeto. Notar que a computação quântica potencialmente representa um risco futuro e que os contratos inteligentes podem ser arriscados... são tentativas de tornar o relatório mais longo ao encontrar problemas inventados ou são uma tentativa de fornecer algum tipo de "não é nossa culpa" se algo for eventualmente hackeado. Provavelmente uma mistura dos dois.

No espírito desses pontos, propomos como nono problema que a rede cairá quando o sol morrer, a menos que nos tornemos uma espécie interestelar e de alguma forma descubramos comunicação mais rápida que a luz. Caso contrário, a relatividade limita a vida útil deste sistema a cerca de 5 mil milhões de anos. Honestamente, isso é mais útil do que afirmar que a qualidade do código poderia ser melhorada porque, mesmo depois do Sol morrer, ainda haverá código mau a executar algures. Mas estamos a brincar.

Hyperliquid

A Hyperliquid publicou alguns relatórios de auditoria. O primeiro relatório de auditoria encontrou seis problemas e o segundo relatório confirmou que foram resolvidos. Mas o âmbito da auditoria excluiu:

1. Outros contratos inteligentes parte do sistema Hyperliquid
2. Componentes off-chain, como validadores
3. Componentes front-end
4. Infraestrutura relacionada com o projeto
5. Custódia de chaves

Essas parecem áreas de problema potenciais! Tudo o que foi auditado foi um único contrato de ponte. Mas o sistema é, bem, muito mais complicado do que isso.

Auditar um pequeno canto do sistema que faz apenas algumas coisas estritamente definidas é bastante inútil. A forma como a Hyperliquid está concebida, o contrato auditado é o ponto externo de entrada e saída para todos. Por isso, seria um problema sério se esse contrato estivesse repleto de erros. Mas confirmar que o contrato funciona proporciona pouco ou nenhum conforto.

Ondo

Esta auditoria destaca "RISCO DE CENTRALIZAÇÃO PARA ENTIDADES E FUNÇÕES DE CONFIANÇA", que a equipa reconheceu. Está em maiúsculas assim no relatório. Certo.

Esta auditoria observa que o sistema pode colapsar se uma stablecoin envolvida perder o peg de forma muito acentuada. Eles formulam isso como o sistema "permitirá cunhagem excessiva de tokens OUSG durante o evento de depeg do USDC". No final, a "solução" que implementaram foi uma referência a um oráculo Chainlink e um interruptor de desligamento caso o preço seja reportado como demasiado baixo. Portanto, em vez de implodir com o valor a cair, o protocolo parará com o valor a cair. Certo. Este não é um problema solucionável, pois não há mecanismo para evitar um resultado de perda de valor se o USDC explodir. E, de acordo com esse facto, a solução não resolve realmente nada.

Essas auditorias são relativamente recentes. Mas para dar algum contexto, esta auditoria de outubro de 2022 identifica muitos problemas reais. Quase 200 deles. A maioria foi corrigida, alguns eram semelhantes aos acima e apenas reconhecidos. O ponto é que a auditoria costumava fazer algo concreto e substancial: procurar erros de programação que não poderiam ter sido intenção do programador. Os programadores costumavam corrigir esses erros porque eram, sabe, erros genuínos e não apenas decisões de design questionáveis incorporadas no produto.

E depois, em 2024, vemos auditorias que encontram relativamente poucos problemas técnicos e declaram como fora do âmbito ataques relacionados com finanças. A única forma sensata de interpretar esta mudança ao longo do tempo é que os programadores, e programadores como auditores, reconheceram que o código funcional não era o único risco. Claro que os bugs de programação eram explorados de vez em quando. Mas em meados de 2024, todos podiam ver que mecanismos económicos defeituosos também eram um risco enorme. Eram o maior risco.

Projetos que funcionaram exatamente como pretendido – não como sonhado, como pretendido na realidade – explodem de vez em quando porque os sonhos de estabilidade dos designers quebram quando confrontados com o mundo real.

Pode ver esta evolução nas auditorias deste projeto.

Mutuum Finance

Agora temos o reductio ad absurdum das auditorias. Esta identifica um único problema:

O problema é a falta de transparência em torno da distribuição inicial de tokens e como isso pode estar relacionado com problemas de centralização. Foi "mitigado" porque:

Depois há muitos detalhes de multisig. E finalmente a resposta do auditor:

Portanto, o risco com o projeto é que uma pequena equipa controla tudo e a forma como esse controlo será, ou talvez não será, dispersado é completamente não transparente. E a solução proposta pela equipa de escrever uma publicação no blogue para esclarecer a sua intenção não resolve isto, em qualquer sentido estrito.

Para constar, a equipa publicou uma lista detalhada de quais tokens irão para onde e quando. E reconhecem que isto está incompleto com comentários como "Estamos a considerar um modelo de distribuição bloco a bloco ou semanal". Também reconhecem que tudo será gerido através de multisigs manuais. Portanto, estão a ser honestos. Apenas a honestidade equivale a "sim, ainda podemos fazer o que quisermos e vocês têm de confiar em nós".

Qual é o propósito desta auditoria? Se o código não tivesse bugs identificáveis, o auditor poderia simplesmente escrever isso. Às vezes, uma ida ao médico ou mecânico produz um atestado de saúde limpo. Por isso ficamos a pensar se apenas uma quantidade trivial de código foi auditada? Ou talvez o próprio projeto seja apenas uma quantidade trivial de código? O auditor sentiu necessidade de colocar algo no relatório porque caso contrário era tudo demasiado vazio? Por que alguém se deu ao trabalho com isto?

Novamente, não estamos realmente a culpar os auditores aqui. Na medida em que alguém está a fazer algo errado aqui, é quase certamente um problema de incentivos com quem encomendou a auditoria. E o facto de estarem a gastar dinheiro dos investidores para produzir um documento maioritariamente inútil para fins de marketing. Isso não é responsabilidade do auditor!

Melhorias

É inequivocamente bom que mais bugs sejam detetados, menos código defeituoso seja lançado em produção e mais correções propostas sejam implementadas. E não somos suficientemente imaturos para sugerir que o problema é que os utilizadores e investidores se preocupam com as coisas erradas, como, por exemplo, atribuir valor e confiança a auditorias que não significam muito. As pessoas preocupam-se com aquilo com que se preocupam e tentar mudar isso é uma tarefa de tolos.

Mas há algumas melhorias reais que podemos sugerir. A Ethena liderou o caminho ao explicar antecipadamente alguns dos muitos modos de falha do seu produto. A equipa foi consistente com a mensagem de que o USDe não era isento de riscos. E delinearam formas como poderia ter problemas. O produto sobreviveu, com alguns solavancos, e é bastante grande hoje. Isto dá-nos um ponto de ação para investidores: insistir que os projetos sejam honestos sobre quaisquer "ataques relacionados com finanças" que possam existir.

A Ethena mostra que ser honesto não condena o projeto! Pode argumentar-se que, ao ser mais honesto, o projeto atraiu mais interesse. A honestidade também tem o bónus adicional de fornecer mais cobertura legal se algo correr mal. Os projetos já devem querer fazer isto.

Os auditores também podem reorganizar a forma como fazem análises para tornar o seu trabalho mais útil. Ou pelo menos menos inútil e potencialmente enganoso. Não coloquem problemas de incentivos económicos ou preocupações gerais como segurança quântica na mesma secção que os bugs. Atualmente, estes são normalmente rotulados de forma a diferenciá-los ligeiramente dos erros de código. Ou são listados como "informativos" em oposição a "críticos".

Mas isto não capta o ponto. A segurança quântica pode muito bem ser um risco "crítico" para um sistema – mas é de um caráter inteiramente diferente de uma verificação de assinatura incorreta ou um sinal de menos errante! Coloque essas coisas em secções separadas. Da mesma forma, "este esquema de stablecoin é instável em condições razoavelmente prováveis" não é nada como um bug lógico no código. Esclarecer esta confusão deve melhorar a aparência dos documentos de auditoria e polir a reputação do auditor.

Finalmente, as exchanges podem ajudar nisso. As grandes exchanges recebem muitas críticas por listarem projetos terríveis, ou memecoins arriscadas com oscilações selvagens que custam dinheiro às pessoas, ou toda a outra variedade de decisões comerciais estranhas que infligem perdas. E se as exchanges insistissem em auditorias razoáveis que cobrem a estabilidade económica honestamente e não confundem riscos como "os contratos inteligentes podem ser vulneráveis" com verificações lógicas reais?

Uma forma de interpretar um auditor a encher os seus resultados com este tipo de enchimento é que ninguém levará a sério um resultado de auditoria vazio. É justo que tal documento levantaria questões. Mas se uma grande exchange listasse um token com, digamos, dois resultados de auditoria "vazios" correspondentes que não incluíssem problemas específicos do projeto e assumisse a posição de que isso era algo bom... isso poderia ajudar a fazer avançar a bola um pouco. Também estamos num ponto do ciclo em que ser uma exchange mais "honesta" e "razoável" deve conseguir mais clientes do que a falta de marketing ridículo de ir até à lua custa.

Da mesma forma, não deve haver estigma associado a auditar um projeto e dizer que parece bem. Este está nos auditores. Talvez um grupo de auditores pudesse emitir algumas declarações conjuntas nesta área. Sim, podemos entender que os auditores queiram incluir ressalvas para problemas potenciais que foram excluídos do âmbito quando o compromisso começou. Também é justo. Mas encher resultados com problemas potenciais gerais sem sentido não é a resposta. Nem é dizer que a equipa mitigou o risco de centralização ao fazer uma publicação no blogue sobre a distribuição de tokens que pretendem resolver manualmente, em breve, num calendário que ainda está por determinar.

As auditorias podem ser úteis. As auditorias podem ajudar. E a verdade é que as auditorias web3 detetaram problemas reais e, durante um período significativo, estiveram repletas de conteúdo útil e interessante. Mas os engenheiros melhoraram ao longo do tempo porque são, sabe, engenheiros e é isso que fazem. Os auditores precisam de acompanhar o ritmo e, para usar uma palavra, inovar um pouco. E muitas partes maiores do ecossistema, como as exchanges, também podem ajudar a fazer avançar isto.