Provar uma afirmação sem revelar o segredo
O conceito fica mais acessível quando o leitor já sabe ler um smart contract sem ser desenvolvedor. O provador possui uma informação, chamada testemunho, e produz um objeto criptográfico. A partir dos dados públicos, o verificador confere esse objeto sem descobrir o testemunho.
A apresentação das zero-knowledge proofs pela Ethereum.org destaca três propriedades. Primeiro, a completude significa que uma afirmação válida pode convencer um verificador honesto. Depois, a solidez impede que uma afirmação falsa seja aceita, salvo por uma probabilidade desprezível. Já a propriedade de conhecimento zero limita o que o verificador aprende além da validade.
Um exemplo didático é provar que se conhece uma senha sem transmiti-la. Em uma aplicação real, o circuito codifica uma relação matemática: o hash da entrada secreta deve corresponder a um valor público.
A prova não garante que o programa esteja respondendo à pergunta correta. Se o circuito tiver um erro, ele poderá provar fielmente um cálculo incorreto. Por isso, auditar a lógica continua sendo essencial.
Prova interativa e prova não interativa
As primeiras construções exigiam várias trocas entre o provador e o verificador. Cada desafio reduzia a probabilidade de sucesso de um fraudador. Esse modelo de interação se adapta mal a um blockchain, no qual muitos participantes precisam verificar o mesmo resultado.
Uma prova não interativa é criada de uma só vez e pode ser verificada por vários participantes. Os sistemas modernos usam parâmetros públicos, funções de hash ou outras hipóteses para substituir as trocas.
A palavra “argumento” geralmente indica uma segurança computacional: um adversário com recursos realistas não consegue forjar a prova. Uma prova, no sentido matemático, pode buscar uma segurança mais forte, mas a terminologia varia conforme o protocolo.
O usuário não precisa dominar todas as equações. Ainda assim, deve conhecer as hipóteses, o tamanho da prova, o tempo de geração, o custo de verificação e a eventual existência de um trusted setup.
ZK-SNARKs: provas compactas e verificação rápida
SNARK significa succinct non-interactive argument of knowledge. A prova costuma ser pequena e sua verificação, rápida. Essas características são adequadas aos blockchains, nos quais cada byte e cada operação têm um custo.
Algumas famílias de SNARK exigem um trusted setup. Uma cerimônia produz parâmetros públicos a partir de um segredo que deve ser destruído em seguida. Se pelo menos um participante agir honestamente em uma cerimônia multiparticipante bem projetada, o segredo completo não deverá ser reconstruído.
Outros SNARKs usam um setup universal ou transparente, dependendo da construção. Portanto, é preciso evitar a afirmação de que “todos os SNARKs têm trusted setup”. Consulte a documentação do sistema específico.
Um tamanho reduzido não significa geração gratuita. Criar uma prova para um cálculo grande exige tempo, memória e, às vezes, hardware especializado. O custo é deslocado do verificador para o provador.
ZK-STARKs: transparência e provas maiores
STARK significa scalable transparent argument of knowledge. O termo “transparente” indica a ausência de um trusted setup secreto nas construções habituais. A segurança se baseia, entre outros elementos, em funções de hash e parâmetros públicos verificáveis.
Os STARKs podem escalar melhor em cálculos grandes, mas suas provas costumam ocupar mais espaço. A Ethereum.org destaca que esse tamanho aumenta a carga de verificação on-chain em comparação com alguns SNARKs.
A escolha depende, portanto, do contexto. Uma aplicação pode priorizar uma prova compacta, uma cerimônia controlada ou transparência máxima. Nenhuma família domina todos os critérios.
Os desenvolvedores também avaliam a maturidade das bibliotecas, as linguagens de circuitos, as auditorias e a disponibilidade de provadores. Uma boa primitiva mal integrada pode criar uma vulnerabilidade prática.
ZK-rollups e escalabilidade
Um ZK-rollup agrupa transações fora da camada principal e publica os dados ou compromissos necessários junto com uma prova de validade. O contrato na Ethereum verifica a prova em vez de reexecutar cada operação.
Essa arquitetura reduz o custo por transação e aumenta a capacidade de processamento. A camada principal fornece a liquidação e a verificação. O guia da Ethereum sobre ZK-rollups explica que o verificador confirma o cálculo off-chain por meio de uma prova.
O prefixo ZK nem sempre significa que as transações do rollup são privadas. Muitos rollups usam uma prova de validade enquanto publicam dados acessíveis. A privacidade exige circuitos e um gerenciamento de dados projetados especificamente para esse objetivo.
Os saques dependem do mecanismo de prova, do contrato e da disponibilidade dos dados. Uma bridge para o rollup acrescenta outros riscos. Consulte o guia sobre bridges cripto entre blockchains antes de transferir recursos.
Privacidade, validade e disponibilidade dos dados
A validade prova que uma mudança de estado segue as regras. Uma propriedade de privacidade oculta determinadas entradas. Por fim, a disponibilidade garante que os dados necessários para reconstruir ou contestar o estado continuem acessíveis. Essas propriedades não surgem automaticamente juntas.
Um sistema pode provar que um cálculo é válido e, ao mesmo tempo, depender de um operador para publicar os dados. Se esse operador desaparecer, os usuários poderão ter dificuldade para reconstruir seu saldo ou realizar uma saída.
Algumas soluções publicam os dados na Ethereum; outras usam um comitê ou uma camada dedicada. Às vezes, o custo diminui ao preço de uma hipótese adicional de confiança.
Antes de usar uma rede, pergunte onde os dados ficam armazenados, quem pode retê-los e qual procedimento permite uma saída forçada. A palavra “proof” não responde a essas questões operacionais.
Usos além dos rollups
Uma prova pode confirmar que uma pessoa supera uma idade mínima sem publicar sua data de nascimento. Também pode demonstrar a participação em uma lista sem revelar qual entrada corresponde ao usuário.
No setor financeiro, um participante pode provar que um cálculo segue uma regra ou que um conjunto de ativos supera determinado limite. A prova, no entanto, não garante que os ativos off-chain realmente existam; um oráculo ou auditor precisa conectar o dado ao mundo externo.
Sistemas de votação também buscam verificar elegibilidade e unicidade sem expor o voto. O desenho precisa impedir votos duplicados, proteger a privacidade e permitir uma auditoria.
Jogos, identidades e programas de compliance também exploram essas ferramentas. Cada uso exige um circuito, uma fonte de dados e uma política de revogação adequados.
As limitações esquecidas pelo marketing
Uma zero-knowledge proof não corrige um dado de entrada falso. Se uma autoridade atribuir uma identidade incorreta, o sistema poderá provar corretamente a posse desse atributo errado.
O código do circuito pode conter um bug. Restrições omitidas representam uma categoria clássica: o provador encontra uma entrada que satisfaz o circuito sem atender à intenção do desenvolvedor.
O desempenho é outra limitação. Gerar uma prova em um celular pode exigir recursos demais. Nesse caso, uma aplicação terceiriza a geração, o que pode expor dados se eles não estiverem protegidos.
Parâmetros, bibliotecas e cerimônias exigem governança. Uma vulnerabilidade criptográfica ou uma atualização pode exigir uma migração. A longevidade do sistema é importante para recursos mantidos por vários anos.
Como verificar as promessas de um projeto ZK
Primeiro, pergunte qual propriedade está sendo provada. Uma frase como “protegido por ZK” não especifica o circuito nem os dados públicos. Procure o contrato de verificação, a documentação técnica e as auditorias.
Identifique a família de provas e o setup. Se houver uma cerimônia, quem participou e como as contribuições são verificadas? Consulte as versões exatas das bibliotecas.
Analise a disponibilidade dos dados, os sequenciadores e a saída de emergência. Um rollup pode ter uma prova robusta e ainda depender de um operador central para ordenar as transações.
Verifique também as permissões e lembre-se de que auditorias não são suficientes diante de novos ataques. A criptografia do rollup não protege contra uma autorização ilimitada concedida a uma aplicação maliciosa.
SNARK ou STARK: como comparar
Compare o tamanho da prova, o tempo de geração, o custo de verificação, o setup e as hipóteses. Inclua nessa análise a maturidade das ferramentas e a capacidade da equipe de auditar o circuito.
Em um blockchain, o custo de publicação pode favorecer uma prova curta. Um cálculo massivo off-chain pode priorizar a escalabilidade do provador. Em um sistema de identidade, a proteção dos dados durante a geração se torna central.
A resistência a futuros computadores quânticos às vezes aparece nessa comparação. Os STARKs geralmente se baseiam em hashes considerados mais favoráveis a esse cenário, mas nenhuma migração criptográfica se resume a um slogan.
Um projeto também pode combinar várias provas, agregar SNARKs ou usar uma prova recursiva. O nome comercial não basta para deduzir a arquitetura.
Checklist antes de usar uma aplicação ZK
Confirme a rede, o contrato e a bridge oficial. Faça primeiro um pequeno depósito e depois um saque. Registre os prazos, as taxas e o procedimento de saída em caso de falha.
Leia o que a aplicação realmente oculta. Uma transação pode esconder o valor e revelar os participantes, ou o contrário. Metadados da rede e o endereço de origem dos recursos também podem reduzir a privacidade.
Consulte as auditorias do circuito, do verificador e dos contratos periféricos. Verifique as chaves administrativas e as possibilidades de atualização. Um timelock dá tempo, mas apenas se o usuário acompanhar os comunicados.
As zero-knowledge proofs oferecem um avanço importante: permitem verificar mais informações revelando menos dados ou reexecutando menos operações. Elas não eliminam bugs, governança nem a necessidade de disponibilidade dos dados. Uma avaliação profissional sempre distingue a propriedade criptográfica do conjunto operacional que a envolve.
