Análise de Bug de Solidez do Zcash Orchard | BlockSec Semanal

Durante a semana passada (2026/06/01 - 2026/06/07), múltiplos incidentes de ataque foram observados em ecossistemas blockchain. O relatório desta semana foca na divulgação pública de uma vulnerabilidade crítica de solidez no pool blindado Orchard do Zcash, que poderia ter permitido a falsificação indetectável de ZEC. Nenhuma exploração on-chain foi confirmada, mas a divulgação desencadeou uma atualização de rede emergencial e o ZEC perdeu mais de 40% de seu valor.

Data	Incidente	Tipo	Perda Estimada
2026/06/04	Zcash Orchard	Bug de Solidez em ZK	Nenhuma exploração confirmada

Destaque da Semana: Bug de Solidez no Orchard do Zcash

Este incidente foi selecionado como destaque da semana por ser uma das vulnerabilidades de ZK mais graves encontradas em produção. Uma restrição de circuito ausente passou despercebida por mais de quatro anos, apesar de múltiplas auditorias, e foi finalmente descoberta por meio de uma revisão de segurança assistida por IA. A classe de vulnerabilidade (relações subrestringidas em circuitos ZK) pode existir em qualquer protocolo construído sobre circuitos ZK.

Em 4 de junho de 2026, o Zcash divulgou publicamente um bug crítico de solidez em seu circuito do pool blindado Orchard [1]. Uma restrição ausente no circuito de prova de conhecimento zero quebrou a vinculação criptográfica que impede o gasto duplo, potencialmente permitindo que a mesma nota blindada fosse gasta múltiplas vezes sem detecção. A vulnerabilidade existia desde a ativação do Orchard em maio de 2022 e foi descoberta em 29 de maio de 2026 pelo pesquisador de segurança Taylor Hornby por meio de uma auditoria assistida por IA. Uma atualização de rede emergencial (NU6.2) corrigiu o circuito em 3 de junho de 2026. Nenhuma evidência de exploração foi encontrada.

Contexto

O Zcash é um blockchain de Camada 1 focado em privacidade cujo token nativo é o ZEC. Ao contrário do Bitcoin, onde todos os detalhes das transações são publicamente visíveis, o Zcash suporta transações blindadas por meio de provas de conhecimento zero, ocultando endereços de remetentes, endereços de destinatários e valores de transações. O Zcash possui múltiplos pools blindados, cada um correspondendo a uma geração diferente de seu protocolo de privacidade. O Orchard é a geração mais recente, ativada em maio de 2022 com a atualização de rede NU5, e utiliza o sistema de prova de conhecimento zero halo2 [2] para verificar transações. Quando um usuário realiza uma transação blindada, ele age como o provador: constrói uma prova de conhecimento zero usando o circuito Orchard que demonstra que a transação é válida — ele possui a nota, o anulador é derivado corretamente e os valores se equilibram — sem revelar nenhum detalhe privado. Os nós da rede atuam como verificadores, checando a prova sem ver os dados subjacentes. O circuito Orchard define as restrições que toda prova válida deve satisfazer. A vulnerabilidade está nesta implementação do circuito e envolve quatro conceitos fundamentais no Zcash: chaves, endereços, notas e anuladores.

Chaves. A hierarquia de chaves do Zcash é mais complexa do que a da maioria dos blockchains. Uma única chave de gasto (o segredo da carteira) deriva várias subchaves: ask (chave secreta de autorização de gasto), nk (chave de derivação de anulador) e rivk (um randomizador). A partir dessas, o sistema computa ak (chave pública de autorização) e ivk (chave de visualização de entrada, via ivk = Commit(ak, nk, rivk)). A chave ivk é usada para identificar e receber fundos recebidos.

Endereços. Para criar um endereço Orchard, o usuário escolhe um diversificador d (um valor de 11 bytes), que determina um ponto base diversificado g_d = DiversifyHash(d). O endereço é o par (d, pk_d), onde a chave de transmissão diversificada pk_d é calculada como uma multiplicação escalar em curva elíptica: pk_d = [ivk] g_d. Isso significa que o endereço está criptograficamente vinculado à chave de visualização do usuário.

Notas. Uma Nota é um registro de ativo que representa fundos recebidos. Para privacidade, o que é armazenado on-chain não é a Nota em si, mas um comprometimento de Nota cm (um comprometimento criptográfico com o conteúdo da Nota, incluindo pk_d, valor e outros dados). A Nota está bloqueada ao endereço do destinatário.

Anuladores. Ao gastar uma Nota, o gastador revela um anulador nf, calculado a partir dos dados da Nota e da chave de anulador nk: nf = Extract_P([(F_nk(ρ) + ψ) mod p]G + cm). A propriedade de segurança crítica é que cada Nota deve produzir exatamente um anulador. Uma vez que um anulador aparece on-chain, a Nota correspondente é considerada permanentemente gasta. Se a mesma Nota pudesse produzir anuladores diferentes, ela poderia ser gasta múltiplas vezes sem que ninguém percebesse.

A cadeia de vinculação. Esses conceitos são conectados por uma cadeia de vinculação criptográfica:

Os nós destacados em vermelho (pk_d, nk) são os pontos onde a vulnerabilidade quebra a cadeia de vinculação: o circuito deve impor pk_d = [ivk] g_d, que vincula o gastador ao ivk correto e, portanto, ao nk correto para aquela Nota. Se essa vinculação for quebrada, o gastador pode forjar um ivk falso e, portanto, usar um nk diferente para cada gasto. Valores de nk diferentes produzem anuladores diferentes para a mesma nota, permitindo o gasto duplo.

Como o circuito impõe essa vinculação. A relação pk_d = [ivk] g_d é uma multiplicação escalar em curva elíptica (Q = [k]P), implementada usando o algoritmo de duplicar-e-somar. Em um circuito de conhecimento zero, o verificador não executa o algoritmo diretamente; em vez disso, o circuito restringe cada etapa intermediária. Um circuito de multiplicação escalar correto deve impor, entre outras coisas, que o ponto base do loop interno seja igual ao ponto base de entrada pretendido (P_loop = P_input). Sem essa restrição, o circuito pode provar que uma multiplicação escalar válida foi realizada, mas com o ponto base errado, tornando toda a cadeia de vinculação sem sentido.

Análise da Vulnerabilidade

O gadget ECC vulnerável foi usado na relação de multiplicação escalar que impõe pk_d = [ivk] g_d, onde Q = pk_d, k = ivk e P = g_d. O código vulnerável está localizado na implementação de multiplicação escalar de base variável do repositório halo2 (incomplete.rs L309-L310):

// incomplete.rs (fonte completa vinculada acima)
298  for (row, k) in bits.iter().enumerate() {
299      // z_{i} = 2 * z_{i+1} + k_i
         ...
305      z = region.assign_advice(|| "z", self.z, row + offset, || z_val)?;
306      zs.push(Z(z.clone()));
307
308      // Atribuir `x_p`, `y_p`
309      region.assign_advice(|| "x_p", self.double_and_add.x_p, row + offset, || x_p)?;  // BUG
310      region.assign_advice(|| "y_p", self.y_p, row + offset, || y_p)?;                  // BUG
311
312      // Se o bit estiver definido, usar `y`; se não estiver, usar `-y`
313      let y_p = y_p
314          .zip(k.as_ref())
315          .map(|(y_p, k)| if !k { -y_p } else { y_p });
316
317      // Calcular e atribuir lambda1
318      let lambda1 = y_a.zip(y_p).zip(x_a.value()).zip(x_p)
             .map(|(((y_a, y_p), x_a), x_p)| (y_a - y_p) * (x_a - x_p).invert());
         ...
     }

Em um circuito de conhecimento zero, o provador preenche cada valor de célula; o próprio circuito não pode copiar ou transferir valores entre células — ele só pode definir restrições que o verificador checa. As duas linhas marcadas com BUG usam assign_advice() para escrever as coordenadas do ponto base x_p e y_p (as entradas privadas do circuito conhecidas como valores testemunha) nas colunas de conselho do circuito (a região de entrada privada do provador). Esta função preenche um valor sem criar uma restrição que o vincule ao ponto base externo. Uma restrição separada garante que os valores base sejam iguais em todas as iterações do loop — o provador não pode usar um ponto base diferente em cada iteração. No entanto, o provador pode substituir um único ponto base arbitrário em todas as iterações, e nada no circuito o rejeitará, pois nenhuma restrição ancora os valores base do loop ao g_d real passado de fora.

A função correta é copy_advice(), que preenche o valor e adiciona uma restrição de igualdade (uma restrição de cópia) impondo que ele corresponda ao ponto base real g_d. Como g_d varia por endereço (derivado do diversificador de cada endereço), o circuito não pode codificá-lo diretamente — ele deve restringir o ponto base do loop para corresponder ao g_d calculado anteriormente.

Como resultado, o circuito não impôs de fato pk_d = [ivk] g_d. Um provador malicioso poderia fornecer um ponto base arbitrário dentro do loop (em vez do g_d correto), e o circuito ainda aceitaria a prova: o cálculo interno permanecia algebricamente autocoerente, mas não estava mais ancorado ao ponto base diversificado especificado pelo protocolo. Esse grau de liberdade extra permite ao provador escolher um nk diferente a cada vez, calcular o ivk = Commit(ak, nk, rivk) correspondente e usar a multiplicação escalar irrestrita para fazer o ivk forjado passar. Como o anulador depende de nk, cada gasto produz um anulador distinto:

mesma nota N + nk_1 → nf_1
mesma nota N + nk_2 → nf_2
onde: nf_1 ≠ nf_2

O consenso verifica apenas se um anulador já apareceu on-chain. Como cada gasto produz um anulador único de aparência válida, o gasto duplo é invisível para a rede.

A correção [3] adiciona uma chamada copy_advice() na primeira iteração do loop (row == 0), criando uma restrição de cópia que ancora o ponto base do loop ao base real passado de fora. As iterações restantes continuam usando assign_advice(), mas a restrição de consistência entre iterações já existente propaga a âncora para todas elas.

Impacto e Resposta

Cenário de exploração. Um provador malicioso poderia explorar a vulnerabilidade para gastar a mesma nota Orchard múltiplas vezes, gerando a cada vez um anulador diferente. Como a prova de conhecimento zero oculta as entradas privadas do circuito, os anuladores fraudulentos são indistinguíveis dos legítimos. O ataque não deixa nenhuma evidência criptográfica definitiva on-chain, tornando impossível determinar conclusivamente se foi alguma vez explorado.

A vulnerabilidade existiu desde a ativação do Orchard em maio de 2022 (atualização NU5), totalizando uma janela de exposição de mais de quatro anos. A contabilidade de torniquete do Zcash limita quanto valor falsificado pode sair do pool Orchard para pools transparentes ou Sapling, limitando o impacto realizado sobre o fornecimento mais amplo. No entanto, notas falsificadas poderiam existir sem ser detectadas dentro do pool blindado, e suas propriedades de privacidade tornam impossível provar criptograficamente se a vulnerabilidade foi alguma vez explorada.

Nota: o torniquete só é acionado quando o total de saídas excede o total de entradas de um pool. Um atacante poderia retirar valor falsificado em pequenas quantias ao longo do tempo sem atingir esse limite. A discrepância só se tornaria aparente se usuários legítimos coletivamente tentassem retirar mais do que o pool realmente possui.

Descoberta e resposta. A vulnerabilidade foi descoberta em 29 de maio de 2026 pelo pesquisador de segurança Taylor Hornby (contratado pela Shielded Labs), usando um framework de auditoria assistida por IA com o modelo Opus 4.8 da Anthropic lançado no dia anterior. Auditorias anteriores do mesmo circuito com modelos mais antigos não haviam encontrado o bug. Hornby relatou o problema ao ZODL no mesmo dia. Um soft fork emergencial em 2 de junho (UTC) desabilitou temporariamente as transações Orchard, e a atualização de rede NU6.2 em 3 de junho (UTC, bloco 3.364.600) introduziu um circuito corrigido, restaurando a funcionalidade do Orchard [1]. Após a divulgação pública em 4 de junho, o ZEC perdeu mais de 40% de seu valor, com liquidações superiores a $100 milhões [4].

Conclusão

A vulnerabilidade do Orchard do Zcash foi causada por uma restrição de igualdade ausente no circuito de multiplicação escalar, permitindo que o provador contornasse a vinculação do ponto base e forjasse anuladores para realizar gastos duplos. Ao contrário dos bugs tradicionais de contratos inteligentes que frequentemente podem ser identificados por revisão de código ou testes, um bug de solidez em um circuito ZK exige compreender a lacuna entre o que o circuito realmente prova e o que ele deveria provar — uma sutileza que escapou a mais de quatro anos de auditorias profissionais por criptógrafos especialistas.

A biblioteca halo2 é usada em todo o ecossistema ZKP, e relações semelhantes subrestringidas poderiam existir em outros projetos construídos sobre esses blocos de construção criptográficos. Protocolos que usam provas de conhecimento zero devem implementar verificações de integridade de saldo (como a contabilidade de torniquete) para limitar o impacto potencial de bugs de solidez não descobertos: sem o mecanismo de torniquete do Zcash, o valor falsificado criado dentro do pool blindado poderia ter fluído livremente para o fornecimento mais amplo. A Shielded Labs anunciou planos para verificar formalmente o circuito Orchard matematicamente.

A descoberta é um exemplo típico de um fluxo de trabalho com humano no loop: um pesquisador de segurança experiente construiu o framework de auditoria e direcionou a investigação, enquanto a IA se encarregou da amplitude de verificar restrições individuais do circuito. Nenhum componente isolado foi suficiente: execuções anteriores somente com IA usando modelos mais antigos não encontraram o bug, e anos de revisão humana especializada também não o encontraram. Hornby é ele próprio um especialista em segurança do Zcash — conhecimento de domínio era necessário para projetar o escopo de auditoria adequado para a IA operar. Como pesquisas recentes divulgadas pela BlockSec também demonstraram [5], os modelos de IA estão progredindo rapidamente na análise de segurança, mas a orientação especializada ainda é necessária para apontar a IA para os alvos certos e validar o que ela encontra. A colaboração interativa entre especialistas e IA — em vez de depender apenas da IA — é o modelo de trabalho mais eficaz.

Referências

The Orchard counterfeiting vulnerability and next steps, Zcash Community Forum, 4 de junho de 2026. Link
halo2: Um sistema de prova de conhecimento zero, GitHub. Link
Fix: anchor scalar multiplication base point via copy constraint, halo2 GitHub. Link
Why ZEC fell 40% even after Zcash patched a shielded pool bug, CoinTelegraph, 5 de junho de 2026. Link
Re-Evaluating EVMBench: Are AI Agents Ready for Smart Contract Security?, arXiv, 2026. Link

Sobre a BlockSec

A BlockSec é um provedor completo de segurança blockchain e conformidade cripto. Construímos produtos e serviços que ajudam clientes a realizar auditorias de código (incluindo contratos inteligentes, blockchain e carteiras), interceptar ataques em tempo real, analisar incidentes, rastrear fundos ilícitos e cumprir obrigações de AML/CFT, ao longo de todo o ciclo de vida de protocolos e plataformas.

A BlockSec publicou múltiplos artigos de segurança blockchain em conferências prestigiosas, relatou vários ataques de dia zero em aplicações DeFi, bloqueou múltiplos hacks para resgatar mais de 20 milhões de dólares e protegeu bilhões em criptomoedas.

Site oficial: https://blocksec.com/
Conta oficial no Twitter: https://twitter.com/BlockSecTeam
🔗 Serviço de Auditoria BlockSec : Envie uma solicitação
🔗 Phalcon Security APP: Agende uma demonstração
🔗 Phalcon Compliance