Fundação Ethereum recorre a IA e encontra falha que poderia derrubar validadores

Desenvolvedores da Ethereum Foundation colocaram recentemente agentes de IA para analisar o software que sustenta a rede Ethereum, com o objetivo de identificar vulnerabilidades e reforçar a segurança da maior blockchain por valor travado. A iniciativa encontrou problemas, mas o trabalho mais crítico ficou com os especialistas humanos: separar falhas reais de falsos positivos. A equipe de Protocol Security publicou anotações de campo com recomendações para que o ecossistema aplique boas práticas em seus próprios fluxos de trabalho com IA. A Ethereum opera sobre milhares de nós — computadores comuns que executam o software da rede, mantêm uma cópia da cadeia e encaminham mensagens para nós vizinhos. Acima dessa camada estão os validadores, nós que fazem stake de ether e votam na validade dos blocos. Para funcionar, eles dependem da chegada de mensagens. A falha identificada estava no gossipsub. O problema permitia que um sistema remoto provocasse um crash: o software do nó atingia um cálculo impossível, encerrava a execução e, com isso, o validador ficava offline até que um operador reiniciasse o serviço. O bug foi corrigido e divulgado rapidamente como "CVE202634219", com crédito à equipe. O ponto central, segundo a Foundation, foi a dificuldade em distinguir relatórios confiáveis dos que apenas pareciam plausíveis. "A surpresa foi o quanto pouco do trabalho foi encontrar [os bugs] e o quanto foi dizer os bugs reais daqueles que só pareciam reais", escreveu Nikos Baxevanis, autor do texto. Parte do desafio está no tipo de saída. Um fuzzer — ferramenta padrão que bombardeia o software com dados malformados até algo quebrar — retorna um crash e o registro do local em que ocorreu, algo que um engenheiro confirma em minutos. Já um agente tende a entregar uma narrativa completa: descreve como a falha seria alcançada, argumenta por que ela importa, sugere um nível de severidade e fornece código funcional para demonstrar o ataque. Tudo em prosa fluente, com o mesmo tom quando a falha é real ou inventada. A Foundation diz que três categorias de falsos positivos se repetiram. A primeira é um crash que só aparece em build de teste, quando o compilador ativa checagens de segurança inexistentes no software distribuído — na prática, nada quebra para usuários. A segunda é um ataque que só funciona se o valor perigoso for inserido manualmente no programa, porque qualquer caminho acessível a um invasor rejeita esse valor antes. A terceira vem de verificação formal (provas matemáticas sobre o comportamento do código), quando uma prova "passa" por demonstrar algo trivial, sem informar nada útil sobre o software. Em todos os casos, é um teste que não testa nada — e o agente escreve essa versão vazia com a mesma velocidade e convicção de um achado legítimo. Outra preocupação apontada é que os agentes tendem a raciocinar bem sobre um instante isolado, mas têm mais dificuldade com bugs que surgem numa sequência de etapas individualmente válidas, em que o problema está na ordem. Esse padrão descreve boa parte dos ataques que drenaram protocolos cripto neste ano: ferramentas técnicas corretas por si só, mas usadas em sequência para chegar a um resultado malicioso. Exemplos recentes seguem essa lógica. O exploit da Edel Finance no início do mês contornou um feed de preços correto da Chainlink por meio da camada de wrapping acima dele. No ataque de governança do BONK, comprar tokens, votar e executar uma proposta aprovada foram transações comuns quando vistas separadamente. A resposta proposta pela Foundation é usar o agente para sugerir quais sequências valem ser testadas e, em seguida, executar os testes de qualquer forma.