Uma IA encontrou no Zcash um bug oculto por 4 anos

Uma inteligência artificial encontrou em dois dias uma falha criptográfica que quatro anos de revisão humana não detectaram no circuito de privacidade da Zcash. Em 29 de maio de 2026, o engenheiro de segurança Taylor Hornby, contratado pela Shielded Labs, descobriu uma vulnerabilidade de soundness (solidez: a garantia de que uma prova criptográfica só é aceita se a afirmação que ela demonstra for realmente verdadeira) no circuito Orchard, o coração do pool blindado da Zcash. A falha permitia cunhar ZEC falso de forma ilimitada e indetectável dentro do pool privado, sem deixar rastros na cadeia. Hornby creditou ao Claude Opus 4.8, o modelo da Anthropic publicado no dia anterior, como a ferramenta que lhe permitiu escrever o exploit funcional. O bug estava lá desde maio de 2022. Este artigo não é apenas mais um relato de hack: é a explicação de por que um circuito de conhecimento zero (zero-knowledge) pode esconder uma falha que não quebra nada visível — não há queda, não há transação suspeita, não há forma de saber a posteriori se foi explorado — e por que isso é especialmente devastador para uma moeda cujo único produto é a privacidade. Vamos reconstruir a cronologia exata, explicar o que uma prova ZK garante e o que não garante, e analisar a pergunta que nenhum patch pode fechar: o supply (circulante total) de ZEC está intacto?

O que falhou exatamente no circuito Orchard?

Orchard é o pool blindado de última geração da Zcash, ativado na atualização de rede NU5 em maio de 2022. Quando alguém mantém ZEC «na sombra» — no pool privado, sem que os endereços nem os valores sejam visíveis —, esses fundos vivem dentro do Orchard. Para que esse ocultamento seja seguro, cada transação privada é acompanhada de uma prova de conhecimento zero: uma demonstração matemática de que a operação é válida (o emissor tem os fundos, não se cria dinheiro do nada, as contas batem) sem revelar nenhum dado concreto. A rede não vê os valores; apenas verifica a prova e, se passar, aceita a transação.

O problema estava em como essa prova é construída. De acordo com o aviso técnico da Shielded Labs, o circuito Orchard continha um elemento sub-restringido (under-constrained): uma operação interna de multiplicação sobre uma curva elíptica que aceitava entradas falsas como válidas. Dito de outro modo, era possível introduzir valores arbitrários e falsos nessa multiplicação e, ainda assim, fazer com que a verificação os desse como bons.

A correção final foi minúscula — uma restrição que faltava na lógica do circuito —, e essa desproporção é justamente o que é inquietante: um detalhe ínfimo separava um sistema de privacidade considerado robusto de uma máquina de falsificar dinheiro. A falha não estava no software do nó, nem nas carteiras, nem na criptografia subjacente da Zcash. Estava na implementação do circuito, na biblioteca de componentes que traduz as regras contábeis da Zcash em restrições matemáticas verificáveis.

O que significa uma falha ser de «soundness» e não um hack comum?

Convém distinguir duas propriedades que toda prova de conhecimento zero deve cumprir, pois a diferença é o centro desta história.

Pense no controle de acesso de um edifício com uma catraca (o cilindro giratório que só deixa passar um por um com um cartão válido). A primeira propriedade que se espera é que quem tem um cartão válido sempre possa entrar: a isso, em criptografia ZK, chama-se completeness (completude). A segunda, mais importante, é que quem não tem um cartão válido nunca possa entrar, nem mesmo fabricando uma falsificação boa o suficiente para enganar o leitor: a essa garantia chama-se soundness (solidez).

Uma falha de soundness é precisamente isso: a catraca deixa passar alguém com um cartão falso. A prova matemática aceita como verdadeira uma afirmação que é mentira. No caso do Orchard, a afirmação falsa era «tenho este ZEC e não o estou criando do nada». Com o circuito quebrado, um atacante podia construir uma prova que dizia «estes fundos são legítimos» quando, na verdade, acabara de inventá-los, e a rede a aceitava sem objeção.

A consequência prática é o que separa este caso de um hack convencional. Em um exploit normal — uma drenagem de um contrato, uma ponte comprometida — há um rastro: transações que movem fundos para um endereço, um pico anômalo, um saldo que se esvazia. Aqui não. Como a falsificação ocorre dentro do pool blindado, onde por design não se veem valores nem endereços, o ZEC falso é indistinguível do legítimo. Não há crash, não há alerta, não há transação marcada como suspeita. O sistema funciona exatamente tão bem fabricando dinheiro falso quanto movendo dinheiro real, porque o seu trabalho é não contar nada sobre o que acontece lá dentro.

Por que uma IA o encontrou e quatro anos de revisão humana não?

Taylor Hornby não é um novato: é um engenheiro de segurança com trajetória, contratado pela Shielded Labs em abril de 2026 para auditar o protocolo. Em 28 de maio, a Anthropic publicou o Claude Opus 4.8. No dia seguinte, Hornby o colocou para trabalhar sobre o circuito Orchard com um conjunto de prompts e ferramentas sob medida — um conjunto de instruções e utilitários encadeados para direcionar o modelo —, focando-o em uma revisão direcionada da lógica do circuito. Em menos de 48 horas, o sistema apontou a inconsistência na multiplicação sobre curva elíptica. Hornby escreveu então um exploit completo que, em um ambiente de testes local, gerou ZEC falso ilimitado e indetectável, confirmando que a falha era real e explorável.

Por que não foi visto antes? Um circuito ZK não é um código legível como um programa normal. É um sistema de restrições algébricas: milhares de equações que, em conjunto, devem fechar a porta para qualquer estado inválido. Verificar que não falta nenhuma restrição é radicalmente mais difícil do que comprovar que as que existem funcionam. O código «faz a coisa certa» em todos os casos de teste; a falha está no caso que ninguém escreveu, na restrição que ninguém adicionou. É um erro por omissão, não por comissão, e os erros por omissão são quase invisíveis à leitura humana, aos testes e às auditorias clássicas, que tendem a comprovar que o que está escrito funciona, não que tudo o que deveria estar escrito está lá.

É aí que um modelo de linguagem com capacidade suficiente de raciocínio sobre matemática e código traz algo que o olho humano não escala: a paciência para percorrer exaustivamente o espaço do que deveria estar restringido e não está. Não é mágica nem substitui o engenheiro — foi Hornby quem direcionou a busca e escreveu o exploit —, mas marca um precedente: a primeira vulnerabilidade criptográfica crítica desta classe, em produção durante anos, atribuída publicamente ao uso de uma IA de fronteira.

Como foi a resposta de emergência de 50 horas?

O que se seguiu à divulgação privada foi uma operação de cirurgia em dois tempos, executada em pouco mais de dois dias, e desenhada com um cuidado incomum para não denunciar a falha enquanto era corrigida.

O problema de corrigir abertamente um bug desta gravidade é de transparência: o código da Zcash é público. Se os desenvolvedores tivessem subido diretamente a correção do circuito, qualquer pessoa com acesso ao commit poderia ter lido o ajuste, deduzido a vulnerabilidade que ele tapava e explorado-a nas redes que ainda não tivessem sido atualizadas. Um patch, para um atacante atento, é um mapa da falha.

A solução foi desacoplar contenção e correção em dois movimentos:

1. Contenção (soft fork). Em 2 de junho por volta das 02:00 UTC, no bloco 3.363.426, foi ativado um soft fork de emergência (Zebra 4.5.3) que simplesmente rejeitava toda transação que tocasse no Orchard. O pool blindado ficou congelado: ninguém podia explorar o que não podia mais ser usado, e o patch não revelava o que estava sendo corrigido porque, tecnicamente, não corrigia nada — apenas fechava a porta.
2. Correção (hard fork). Um dia depois, em 3 de junho por volta das 04:05 UTC, no bloco 3.364.600, o hard fork NU6.2 (Zebra 5.0.0) reativou o Orchard já com o circuito corrigido.

O hard fork era inevitável por uma razão técnica: corrigir um bug em um circuito de conhecimento zero obriga a atualizar a chave de verificação fixada (o parâmetro criptográfico contra o qual a rede valida cada prova). Esse parâmetro está embutido nas regras de consenso, e alterá-lo não pode ser feito com um patch de software do nó — requer que toda a rede salte para um novo conjunto de regras ao mesmo tempo. Daí a atualização de rede.

O que uma prova ZK garante e o que nunca garante?

O incidente expõe um mal-entendido generalizado sobre as provas de conhecimento zero: que uma prova «matematicamente verificada» equivale a uma verdade absoluta. Não é assim. Uma prova ZK só garante tanto quanto as restrições que o circuito impõe. Se o circuito estiver bem construído, a prova é tão confiável quanto a matemática subjacente. Se faltar uma restrição, a prova certifica com total convicção uma mentira, e o faz com a mesma firmeza com que certificaria uma verdade. A criptografia não se quebra; o que se quebra é o modelo do que está sendo demonstrado.

A tabela seguinte separa o que o sistema continuava garantindo do que deixou de garantir enquanto a falha esteve ativa.

A coluna da direita é o verdadeiro alcance do dano. E a última linha é a que define a pergunta aberta de todo o caso.

Por que ninguém pode saber se o supply de ZEC está intacto?

A Zcash dispõe de um mecanismo chamado turnstile (catraca), desenhado precisamente para vigiar a contabilidade entre pools. Cada vez que o valor cruza a fronteira entre o supply transparente (visível) e o blindado (oculto), o turnstile verifica se não está saindo mais do que entrou no agregado. É uma rede de segurança que detecta uma inflação grosseira: se alguém tentasse tirar do pool privado mais ZEC do que matematicamente deveria existir, o turnstile o pegaria na fronteira.

Aqui está a nuance que quase toda a cobertura simplificou. O turnstile vigia o trânsito entre pools, não o que acontece dentro de um deles. Enquanto o ZEC falsificado permanecesse no interior do Orchard, sem cruzar para o exterior, seria invisível para a catraca. E se um atacante o tivesse retirado pouco a pouco, misturado com fundos legítimos e abaixo de qualquer limite chamativo, não há forma criptográfica de distinguir essa saída de uma retirada normal.

Por isso convivem duas afirmações que parecem contraditórias e não são. Por um lado, o turnstile confirma que não foi detectada criação de valor não autorizada em nível agregado, e não há evidência de exploração na mainnet. Por outro, a Shielded Labs reconhece de forma explícita que, devido às propriedades de privacidade do Orchard, não existe nenhuma maneira definitiva — usando apenas criptografia — de determinar se a exploração ocorreu. Ambas as coisas são verdadeiras ao mesmo tempo: não há prova de que foi explorado, e também não pode haver prova de que não foi explorado. A privacidade que protege o usuário é a mesma que impede a auditoria da falsificação.

Para uma moeda de privacidade, isso é existencial de uma forma que não seria para o Bitcoin ou Ethereum, onde qualquer um pode somar o supply olhando a cadeia. Todo o produto da Zcash é a confiança de que o que não se vê, bate. Quando essa confiança não pode mais ser verificada criptograficamente, ela resta como um ato de fé.

Como o mercado reagiu e o que a Shielded Labs propõe agora?

A reação do mercado foi imediata. Após a divulgação pública de 5 de junho, o ZEC despencou: a CoinDesk reportou uma queda em torno de 38% em 24 horas, com uma mínima próxima de 442 $. Medido na janela de 48 horas, outras fontes situaram a correção próxima de 50%. O intervalo exato depende do período de tempo e da exchange, mas a ordem de magnitude — uma perda de entre um terço e metade do valor em dois dias — é consistente em toda a cobertura.

A verdadeira incógnita não é o preço, mas o plano de fundo. Como não se pode demonstrar criptograficamente que o supply está limpo, a Shielded Labs propôs uma atualização de rede mais ambiciosa do que o simples patch: criar um novo pool blindado e forçar uma contabilidade de turnstile sobre todos os fundos que migrarem do antigo Orchard. Na prática, equivaleria a obrigar que cada ZEC blindado «passe pela alfândega» ao mover-se para o novo pool, onde sua existência possa ser contrastada com o supply auditável. É a única via para reconstruir, de forma verificável, uma verdade contábil que a falha deixou em suspenso. É também uma operação delicada que reabre debates de governança sobre quem decide e como se executa uma mudança desta magnitude em uma rede descentralizada.

O padrão lembra outros incidentes recentes onde o problema não foi a criptografia em si, mas a lacuna entre o que o código deveria garantir e o que realmente garantia em produção. Analisamos isso no caso do patch fantasma da Gnosis Pay, onde um ajuste existia no repositório, mas nunca chegou ao contrato implantado. A lição compartilhada é incômoda: «auditado» e «verificado» não significam «correto».

Que lições ficam para a privacidade ZK e para o papel da IA na segurança?

A primeira lição é sóbria: as provas de conhecimento zero são tão fortes quanto a correção de seus circuitos, e verificar essa correção é um dos problemas abertos mais difíceis da criptografia aplicada. Cada protocolo que empilha privacidade ou escalabilidade sobre circuitos ZK — e são cada vez mais, desde stablecoins privadas até rollups — herda esta superfície de risco. A privacidade on-chain não é um interruptor que se liga; é uma propriedade que depende de que milhares de restrições algébricas estejam todas presentes e bem colocadas.

A segunda lição aponta para o futuro imediato. O fato de uma IA de fronteira detectar em 48 horas o que anos de revisão não viram corta em duas direções. Por um lado, é uma ferramenta defensiva poderosíssima: as equipes que integrarem modelos capazes de raciocinar sobre circuitos em suas auditorias encontrarão falhas antes. Por outro, o mesmo poder está disponível para o atacante, e nem todos os que encontrarem um bug de soundness o divulgarão de forma responsável como fez Hornby. A janela entre «um novo modelo pode encontrar isso» e «alguém o encontra com más intenções» encurta a cada geração.

Para o ecossistema de privacidade — desde moedas como Zcash até as novas stablecoins de privacidade sobre redes ZK e os roteiros de privacidade institucional no Ethereum (2025-2029) —, o episódio estabelece um padrão: auditar circuitos ZK com assistência de IA deixará de ser opcional. O caso foi encerrado sem perdas verificadas e com uma resposta técnica exemplar em velocidade, mas deixa uma pergunta que nenhum hard fork resolve: em um sistema desenhado para não contar nada, como se demonstra que nada foi quebrado?

Fontes e links: Zcash Community Forum — The Orchard Counterfeiting Vulnerability · Zcash Foundation — Zebra 4.5.3 e 5.0.0 · CoinDesk · Decrypt · BitMEX Blog