Provas de Conhecimento Zero (ZKP): Zcash e Altcoins e a Privacidade Total

Provas de conhecimento zero (ZKPs) tornaram-se um dos primitivos criptográficos mais transformadores em sistemas modernos de blockchain. Diferentemente de artigos de alto nível que diluem a essência técnica, este texto detalha os mecanismos reais, a matemática real e as restrições reais por trás dos sistemas de privacidade baseados em ZK usados em altcoins como Zcash, Aleo e Firo—sem abstrações ou conteúdo de marketing.

1. O que uma Prova de Conhecimento Zero Realmente é (Matematicamente)

Uma ZKP é um protocolo interativo ou não-interativo que permite a um provador P convencer um verificador V de que uma afirmação é verdadeira sem revelar qualquer informação além da veracidade da afirmação.

Formalmente, uma ZKP deve satisfazer:

1. Completude: Se a afirmação for verdadeira, um verificador honesto aceita.
2. Solidez: Um provador malicioso não pode convencer o verificador de uma afirmação falsa.
3. Conhecimento zero: O verificador não aprende nada além da validade.
   O conhecimento zero é definido usando um simulador S:
   Se S pode gerar uma transcrição indistinguível sem conhecer a testemunha, o protocolo é de conhecimento zero.

Para uso em blockchain, a afirmação geralmente se parece com:

“Eu conheço um segredo (testemunha) que gera este valor público via hash.”
ou
“Eu possuo moedas pertencentes a compromissos sem revelar quais.”

2. Esquemas de Compromisso — A Base das Moedas de Privacidade ZK

A maioria das moedas de privacidade usa compromissos para esconder valores de transações e propriedade.

Um compromisso é definido como:
C = Commit(valor, aleatoriedade)

Propriedades:

• Esconder: o valor não pode ser extraído de C.
• Vincular: o provador não pode alterar o valor posteriormente.

Esquemas comuns:

• Compromissos Pedersen:
  C = v·G + r·H em grupos de curva elíptica (usado em Firo Lelantus / MimbleWimble).
• Compromissos baseados em SHA-256: usados em alguns circuitos zk-SNARK para eficiência.

Compromissos Pedersen permitem:

• Homomorfismo aditivo: C1 + C2 = Commit(v1 + v2, r1 + r2).
  → É assim que transações confidenciais preservam o fornecimento total.

3. zk-SNARKs e zk-STARKs — Por que Moedas de Privacidade Usam um ou Outro

3.1 zk-SNARKs (Argumento de Conhecimento Não-Interativo e Conciso)

Usados em:

• Zcash (Sapling)
• Horizen
• Firo Lelantus Spark

Propriedades:

• Provas muito pequenas (~192 bytes em Sapling).
• Verificação muito rápida (~10 ms).
• Requerem um setup confiável (problema do “resíduo tóxico”).
• Usam emparelhamentos de curvas elípticas (principalmente BLS12-381).

Detalhe técnico frequentemente omitido:
Zcash originalmente usou BN254 (Jubjub), mas mudou para BLS12-381 devido a fraquezas de segurança em subgrupos e preocupações sobre margens de segurança de 128 bits.

3.2 zk-STARKs (Argumentos Transparentes e Escaláveis de Conhecimento)

Usados em:

• Aleo
• StarkNet (não é uma moeda, mas relevante)

Propriedades:

• Não requer setup confiável.
• Pós-quântica segura (baseada em funções hash, não emparelhamentos).
• Provas são grandes (~100–500 KB).
• Verificação rápida e escalável.

Fato pouco conhecido:
As primeiras provas da testnet Aleo eram tão grandes que a largura de banda da rede se tornou um gargalo; otimizações reduziram o tamanho das provas em ~80% antes do mainnet.

4. Onde o Conhecimento Zero Aparece Dentro de uma Transação de Privacidade

Uma altcoin focada em privacidade normalmente usa ZKPs para um ou mais dos seguintes:

4.1 Ocultando o Remetente

Mecanismos:

• Assinaturas em anel (Monero — não ZK, mas relacionado).
• Provas de pertencimento de conhecimento zero (Zcash, Lelantus).

Exemplo (simplificado):
O provador mostra que conhece a chave secreta de um elemento em um conjunto de compromissos sem revelar qual.

4.2 Ocultando o Destinatário

Usando endereço furtivo ou endereço diversificado.
Zcash usa endereço de pagamento e chaves de visualização de entrada para permitir transparência seletiva.

4.3 Ocultando o Valor

Compromissos Pedersen + ZKP que:

• Somam corretamente os compromissos,
• Valores são não-negativos (provas de intervalo),
• Nenhuma inflação é introduzida.

Provas de intervalo antigas (Transações Confidenciais, propostas Bitcoin):
~2–3 KB por saída.

Bulletproofs:
~700 bytes por saída (usado no Monero).

zk-SNARKs:
Zcash oculta valores com provas tão pequenas quanto 192 bytes no total.

5. Um Exemplo Concreto de Transação: Zcash Sapling

Uma transação protegida Sapling do Zcash prova:

1. Que o gastador possui uma nota (moeda oculta).
2. Que a nota não foi gasta anteriormente (ZKP de nullifier).
3. Que o valor total de saída é igual ao valor total de entrada (ZKP de balanço).
4. Que as notas de saída são compromissos corretamente formados.

O que é realmente provado?

O provador constrói um circuito cobrindo:

• Hashes (BLAKE2s) dos compromissos das notas
• Hashes Pedersen
• Autenticação do caminho da árvore de Merkle
• Cálculo do nullifier
• Equações de conservação de valor

A complexidade total do circuito é ~2 milhões de restrições.
A geração da prova utiliza Groth16, requerendo:

• Cálculos FFT
• Multiplicações multiescalares
• Emparelhamentos EC

Em um laptop, gerar uma prova leva ~1–2 segundos (otimizado com curvas Pallas/Vesta em Orchard).

Fato raramente mencionado:
O circuito Sapling usa decomposição de bits para restrições de intervalo, aumentando muito a contagem de restrições; Orchard substituiu isso pela aritmetização PLONKish do Halo 2, reduzindo a complexidade drasticamente.

6. Lelantus Spark (Firo) — Um Sistema ZK Subestimado

O sistema “Spark” do Firo é um dos mais avançados tecnicamente, mas menos conhecido publicamente.

Principais inovações:

• Puramente ZK (sem assinaturas em anel).
• Usa One-of-Many Proofs:
  O provador demonstra que possui uma nota entre N, com tamanho da prova logarítmico em N.
• Sem setup confiável.
• Valores são ocultos via compromissos Pedersen.
• Endereços Spark são não vinculáveis mesmo para nós que realizam análise da blockchain.

O Spark também inclui:

• Reemissão de Endereços:
  Proprietários podem atualizar endereços mantendo controle, reduzindo vazamento de metadados.
• Vinculação Universal:
  Evita inflação maliciosa usando vários vínculos criptográficos para o mesmo compromisso.

Fato pouco conhecido:
O design do Spark reduz a superfície de ataque causada por “provas de gasto parcial”, que anteriormente tornavam alguns protocolos de privacidade vinculáveis sob certas heurísticas.

7. Aleo — Execução ZK, Não Apenas Transações ZK

Aleo não é apenas uma moeda privada — é uma blockchain L1 com contratos inteligentes totalmente privados.

Como funciona:

• Programas são escritos em Leo, uma DSL estilo Rust que compila para R1CS.
• A execução ocorre off-chain.
• Uma prova zk-STARK é gerada representando todo o rastreio da execução.
• Miners/validadores verificam a prova e atualizam o estado.

Isso é efetivamente:

Uma máquina virtual global, verificável e criptografada.

Fato pouco conhecido:
Aleo usa um sistema híbrido de provas:

• STARKs para transparência
• Recursão SNARK (estilo Kimchi/Halo) para redução do tamanho da prova

Esta abordagem híbrida é rara e tecnicamente complexa.

8. Por Que ZKPs São Difíceis de Implementar em Escala de Altcoin

8.1 Custo de Prova

Gerar uma prova zk-SNARK requer:

• Milhões de restrições aritméticas
• FFTs sobre campos finitos grandes
• Multiplicações EC multiescalares

Mesmo com otimizações:

• A geração da prova pode ser limitada pela CPU.
• O uso de memória é alto (várias centenas de MB em sistemas antigos).

8.2 Problemas com Setup Confiável

Moedas usando Groth16 precisam de setup confiável.
Se o “resíduo tóxico” não for destruído, um atacante pode:
→ criar moedas falsas ilimitadas
sem detecção.

O Zcash utilizou de fato uma cerimônia multipartidária; o resíduo tóxico final foi (supostamente) destruído com extração física de entropia e rigorosa OPSEC…
Mas um único participante desonesto seria suficiente para comprometer o sistema.

8.3 Bugs em Circuitos Podem Derrubar uma Moeda

Se o circuito de um sistema de privacidade tiver um bug não detectado que permita inflação, os nós não conseguem detectar moedas falsas.
Isso ocorreu no início do Zcash (corrigido antes da exploração).

Um erro sutil em uma restrição aritmética pode quebrar todo um ecossistema.

9. O Futuro das Moedas ZK

Tendências tecnicamente prováveis:

• Provas recursivas permitindo verificação de transações em lote.
• Sistemas híbridos STARK–SNARK, como no Aleo, para reduzir o tamanho da prova.
• Aceleração por hardware via GPUs e ASICs para geração de provas.
• Privacidade programável, permitindo divulgação seletiva.
• Circuitos ZK compatíveis com mobile (circuitos atuais são muito pesados).

Alguns experimentos de pesquisa:

• Mempools criptografados ZK
• Motores de matching P2P baseados em ZK
• DEXs baseados em ZK sem revelar livros de ordens

Estes já estão sendo prototipados em projetos como Penumbra e Mina.

10. Ataques do Mundo Real e Fraquezas em Moedas de Privacidade Baseadas em ZK

Embora os sistemas ZK visem garantir privacidade e correção, a história mostra que a complexidade criptográfica frequentemente cria novas superfícies de ataque.

Abaixo estão os problemas mais importantes, reais, documentados e frequentemente pouco discutidos.

10.1 Vulnerabilidade de Falsificação do Zcash (2018)

Uma vulnerabilidade grave foi descoberta no circuito Sapling do Zcash:

• Um parâmetro dentro do circuito zk-SNARK estava incorretamente restrito.
• Isso permitia que um atacante criasse moedas protegidas falsas.
• Essas moedas seriam indetectáveis, pois todos os valores protegidos são ocultos.

Fatos-chave:

• Descoberto pelo criptógrafo Ariel Gabizon.
• Corrigido em Sapling antes de exploração pública.
• O Zcash nunca divulgou quantas (se alguma) moedas falsas foram criadas no pool Sprout, porque é matematicamente impossível verificar.

Este incidente é o exemplo real mais forte de:

Falhas em sistemas ZK = inflação catastrófica e indetectável.

Também motivou mudanças no protocolo em direção a:

• Novos circuitos (Sapling, Orchard)
• Sistemas de restrições mais modulares
• Mais revisão por pares antes do deploy

10.2 Ataque Acadêmico ao MimbleWimble (2019)

MimbleWimble (usado pelo Grin/Beam) não utiliza zk-SNARKs, mas usa compromissos Pedersen + cut-through + sem endereços.

Um pesquisador (Ivan Bogatyy) demonstrou:

• Monitorando a rede em tempo real com ~200 nós,
• Ele conseguiu vincular 96% das transações Grin a remetentes e destinatários.

Isso não foi uma falha na matemática ZK em si, mas uma falha em:

• Modelo de agregação de transações
• Falta de entradas “falsas” (decoys)
• Exposição de metadados em nível de rede

Lição importante:

A privacidade não está apenas nas provas — vazamentos de topologia de rede podem desanonimizar mesmo matemática ZK perfeita.

10.3 Vazamentos de Tempo em Implementações de Prover

Algumas implementações de ZKP (particularmente circuitos SNARK antigos) vazam padrões de tempo:

Exemplo:

• Ao provar uma transação com muitas entradas, CPUs ou GPUs produzem mudanças de tempo detectáveis.
• Um observador com acesso a nível de nó pode estimar o número de notas sendo gastas, reduzindo conjuntos de privacidade.

Isso foi parcialmente observado em clientes Zcash antigos antes da otimização.

Razão:
Provers SNARK frequentemente usam FFTs e multiplicações multiescalares onde a estrutura dependente da entrada afeta o tempo de execução.

10.4 Riscos Multi-Curva em Sistemas Híbridos

Projetos como Aleo usam:

• STARKs → depois comprimem com recursão SNARK (Kimchi/Halo/compromissos polinomiais KZG).

Um risco raramente discutido:
Se qualquer curva ou esquema de compromisso polinomial na pilha de recursão falhar,
todo o sistema se torna vulnerável.

Essa “fragilidade multi-curva” quase nunca é mencionada em materiais de marketing.

11. Projetando um Circuito ZK para Moeda de Privacidade (Esquema Geral)

Aqui está uma análise técnica real de como desenvolvedores constroem de fato um protocolo de privacidade ZK.

Passo 1: Selecionar modelo aritmético

• R1CS (Zcash Sapling)
• PLONKish (Halo 2, Orchard)
• AIR/FRI (STARKs)

Cada um tem trade-offs:

• R1CS → fácil de raciocinar, restrições pesadas.
• PLONK → flexível, suporta gates customizados.
• STARK → sem setup confiável, mas provas maiores.

Passo 2: Escolher campo finito

Exemplos:

• Campo escalar BLS12-381 (255-bit) para SNARKs.
• Campo Goldilocks (amigável a 64-bit) para STARKs (usado em Polygon Miden, RISC Zero).

A escolha do campo afeta diretamente:

• Tamanho do circuito
• Aceleração por hardware
• Velocidade de geração de provas

Passo 3: Construir compromissos criptográficos

Uma altcoin típica usará:

• Compromissos Pedersen para valores
• Compromissos baseados em SHA para caminhos Merkle
• Hash Poseidon/Rescue dentro de circuitos (amigável a FFT)

Detalhe pouco conhecido:
O Zcash abandonou SHA-256 dentro de circuitos porque SHA-256 é extremamente caro em contagem de restrições — mais de 25.000 restrições por hash.
Poseidon reduz isso para ~150 restrições.

Passo 4: Implementar prova de propriedade (autorização de gasto)

Normalmente envolve:

• Verificação de derivações de chaves
• Verificação de conhecimento da chave privada
• Prevenção de ataques de repetição

Zcash usa RedJubjub, um esquema de assinatura compatível com SNARKs (estilo EdDSA, mas otimizado para SNARKs).

Passo 5: Implementar lógica de nullifier

Nullifier = etiqueta única determinística para uma nota gasta.

O circuito ZK deve garantir:

• Cada nota gera exatamente um nullifier.
• Nullifier não pode revelar a identidade da nota.
• Nullifier não deve permitir múltiplos gastos.

Esta parte é extremamente propensa a erros — e foi a causa do maior bug do Zcash.

Passo 6: Construir equação de saldo

Provar:
soma_compromissos_entradas = soma_compromissos_saídas

Além de provas de intervalo:

• Valores ≥ 0
• Valores < 2⁶⁴

Em sistemas modernos, restrições de intervalo usam:

• Argumentos de lookup PLONK
• Bulletproofs dentro de circuitos
• Gates customizados

Passo 7: Agregação final & geração de prova

Exemplo SNARK:

• Compilar circuito → polinômio QAP
• Fazer FFT para avaliações de polinômios
• Executar multiplicações multiescalares
• Gerar prova
• Nós on-chain/verificadores verificam em milissegundos

Exemplo STARK:

• Construir rastreio de execução
• Aplicar compromissos FRI
• Gerar prova grande, mas transparente
• Verificar usando operações de hash

12. Aceleração de Hardware ZK (Um Divisor de Águas)

A maioria dos usuários não percebe que a geração de provas ZKP está se tornando lentamente uma corrida de hardware:

Provação via GPU

• Operações FFT e MSM se adaptam extremamente bem às GPUs.
• No testnet da Aleo, >50% da capacidade de geração de provas foi realizada em GPUs de consumo (série RTX).

Provação via ASIC

Diversas empresas (Ingonyama, Cysic) estão projetando ASICs orientados a ZKP para:

• Unidades MSM
• Avaliações polinomiais
• Cálculos de caminhos Merkle

Detalhe estatisticamente relevante:

• Um prover ASIC especializado pode gerar provas SNARK 20–50× mais rápido que uma CPU.

Isso significa que o futuro das moedas de privacidade pode depender fortemente de ecossistemas de hardware especializados, semelhante à mineração de Bitcoin.

13. O Problema da Auditoria Transparente em Moedas ZK

Moedas de privacidade enfrentam um paradoxo:

1. Usuários querem privacidade.
2. Desenvolvedores precisam garantir que não haja inflação ou vulnerabilidades ocultas.
3. ZK oculta tudo.

Várias técnicas tentam resolver isso:

13.1 Chaves de Visualização (Zcash, Aztec)

Permitem que auditores inspecionem contas específicas sem revelar outras.

13.2 Auditorias de Suprimento

• O Zcash pode auditar o suprimento do pool transparente.
• O suprimento do pool protegido não pode ser auditado diretamente.
• Desenvolvedores dependem da correção do circuito para garantir que não haja inflação.

É por isso que bugs em protocolos ZK são ameaças existenciais.

14. Fatos Criptográficos Pouco Conhecidos, mas Importantes

14.1 Os Artigos Originais de ZKP Usavam Protocolos Interativos

SNARKs modernos são não-interativos (via heurística Fiat–Shamir).
Mas os primeiros ZKPs exigiam várias rodadas de comunicação.

14.2 Fiat–Shamir Não é Provavelmente Seguro

Se a função hash usada no Fiat–Shamir estiver quebrada ou for maleável,
a soundness pode colapsar.

Isso afeta todas as moedas de privacidade baseadas em SNARK.

14.3 STARKs São Baseados Puramente em Funções Hash

Significado:

• Acredita-se que sejam seguras contra computadores quânticos.
• Sua segurança depende apenas da resistência a colisões do hash (ex.: Rescue, Poseidon).

14.4 Provas Recursivas Reduzem a Carga da Blockchain

Halo 2 (usado no Zcash Orchard) permite:

• Provas que verificam outras provas
• Recursão infinita
• Sem setup confiável

Isso elimina muitas limitações anteriores dos sistemas SNARK.

15. Tabela Comparativa: Sistemas ZK em Principais Altcoins de Privacidade

Monero é incluído apenas para comparação — ele não usa provas de conhecimento zero, o que surpreende muitos iniciantes.

16. As Verdadeiras Trocas ao Usar ZKPs em Moedas de Privacidade

Vantagens

• Privacidade máxima com garantias matemáticas.
• Capacidade de ocultar remetente, destinatário e valor simultaneamente.
• Provas verificáveis por qualquer pessoa.

Desvantagens

• Alto custo computacional.
• Riscos de bugs nos circuitos (inflação).
• Transações maiores (exceto Groth16).
• Mais difícil de integrar em wallets leves.
• Criptografia mais complexa → menos especialistas entendem → auditorias mais lentas.

Uma questão raramente mencionada:

Sistemas ZK aumentam os vazamentos de determinismo de wallets:
padrões de prova podem revelar hardware da wallet, tipo de CPU/GPU ou até mesmo sistema operacional, oferecendo metadados para agências de vigilância de blockchain.

17. Para Onde a Privacidade Baseada em ZK Evoluirá nos Próximos 5 Anos

Direções mais prováveis:

17.1 Camadas Universais de Privacidade

Em vez de construir privacidade diretamente no L1:

• Redes como Aztec, Penumbra e RAILGUN buscam fornecer privacidade para blockchains existentes.
• Isso evita fragmentação entre altcoins.

17.2 Co-processadores ZK

Dispositivos auxiliares (side-car) que realizam todos os cálculos SNARK/STARK para wallets ou nodes.

17.3 Privacidade Adaptativa (Selecionável pelo Usuário)

Usuários podem revelar seletivamente:

• Valores
• Remetente
• Destinatário
• Campos de memo

Apenas quando exigido legal ou comercialmente.

17.4 Ecossistemas de smart contracts totalmente privados

Aleo, Aztec 3 e Penumbra estão ativamente pioneirando nessa direção.

17.5 Padrões de tokens compatíveis com SNARK

Ex.: ZK-ERC20 com:

• Saldo criptografado
• Provas de transferência ZK
• Compatibilidade com ferramentas do Ethereum

Isso provavelmente será a primeira adoção ZK realmente mainstream.

18. Considerações Finais

Provas de conhecimento zero redefinem fundamentalmente o que “privacidade” significa em ecossistemas blockchain.
Não são mágica, e vêm com riscos de engenharia, complexidade criptográfica e riscos operacionais.
Mas permitem algo que nenhum outro sistema consegue:

privacidade matematicamente comprovável combinada com correção matematicamente comprovável.

Para altcoins focadas em privacidade, ZKPs são tanto o escudo máximo quanto a responsabilidade máxima se implementados incorretamente.
Entender os mecanismos criptográficos exatos — compromissos, circuitos, aritmetização, sistemas de prova — é crítico para avaliar moedas de privacidade além das narrativas de marketing.