Ir para o conteúdo
Financial Context Wiki

Prova de conhecimento zero

Guia preciso sobre provas de conhecimento zero: completude, solidez, simulação, testemunhas, premissas de configuração, usos em blockchain e riscos de verificação.

Atualizado

Somente para fins educacionais; não constitui aconselhamento de investimento ou segurança. Uma prova válida garante apenas a afirmação codificada sob as premissas do sistema de prova.

Resposta direta

Uma prova de conhecimento zero (ZKP) permite que um provador convença um verificador de que uma afirmação é verdadeira sem revelar a testemunha secreta usada para comprová-la. A garantia formal não diz que a transcrição não contém literalmente nenhuma informação. Ela diz que tudo o que um verificador permitido aprende pode ser simulado sem a testemunha, além do que decorre da afirmação pública.

Um sistema de prova tem três propriedades separadas: completude, para que um provador honesto com testemunha válida seja aceito; solidez, para que uma afirmação falsa seja aceita apenas com probabilidade desprezível; e conhecimento zero, para que a testemunha permaneça oculta no modelo de ameaça definido. Muitos sistemas práticos são argumentos computacionais: a solidez vale contra adversários computacionalmente limitados e depende de premissas criptográficas declaradas.

Conhecimento zero também difere de concisão e validade. Uma prova pode ser ZK e cara de verificar, concisa mas expor dados públicos, ou provar corretamente uma relação codificada que não corresponde à regra pretendida pelo aplicativo.

1
Executar

O provador executa um lote ou cálculo e registra a transição de estado resultante.

Como funciona

Comece com uma afirmação pública x, uma testemunha privada w e uma relação precisa R. O provador gera a prova e o verificador a avalia com parâmetros públicos ou uma chave de verificação. A solidez pretendida pode ser resumida assim:

Verify(vk, x, proof) = 1 => exists w: R(x, w) = 1

A equação afirma apenas que existe uma testemunha adequada à relação codificada. Não a revela, não autentica entradas offchain e não mostra que R contém todas as regras de negócio pretendidas.

  • Interativa e não interativa. Protocolos ZK iniciais trocam desafios e respostas. Sistemas não interativos reúnem a evidência em uma prova e geralmente dependem de material de configuração, modelo de oráculo aleatório ou ambos.
  • Modelo de configuração. Groth16 produz provas muito pequenas, mas usa configuração estruturada específica do circuito. Sistemas do tipo PLONK podem usar uma string de referência estruturada universal e atualizável. STARK evita configuração estruturada confiável, mas em geral gera provas maiores e depende de hashes e testes de baixo grau.
  • Aritmetização e compromissos. Implementações convertem o programa em restrições algébricas, comprometem valores derivados da testemunha e usam verificações aleatórias para testar o cálculo sem refazê-lo ou ver a testemunha.
  • Prova de conhecimento. Alguns sistemas também afirmam que um provador aceito conhece uma testemunha, formalizado por um extrator. É uma propriedade separada e não decorre do rótulo “conhecimento zero”.

Exemplo

Suponha que x contenha um compromisso e um limite de 100 units, e w contenha o saldo comprometido e o fator de ocultação. A relação verifica a abertura correta do compromisso e saldo de pelo menos 100 units. Uma ZKP válida comprova isso sem revelar o saldo exato.

O resultado não prova sozinho que o provador possui a conta, que os fundos estão livres ou que o mesmo compromisso não foi reutilizado. Essas alegações exigem restrições e entradas públicas adicionais.

Em uma criptomoeda protegida, um circuito pode impor autorização, conservação de valor e não duplicação ocultando alguns dados. Em um validity rollup, uma prova certifica uma transição de estado em lote; os dados ainda podem ser públicos, portanto “ZK Rollup” não significa automaticamente transações privadas.

Riscos

  • Um circuito incompleto ou incorreto pode provar perfeitamente a regra errada.
  • Falta de separação de domínio, identificadores de rede, raízes ou compromissos pode vincular a prova ao contexto errado.
  • Configuração comprometida ou resíduo tóxico retido pode quebrar a solidez de sistemas com configuração confiável.
  • Falhas no provador, verificador, transcrição, curva, hash, compilador ou contrato podem invalidar a garantia teórica.
  • Entradas públicas, horário, grafos de transação, taxas e metadados podem vazar informações fora da afirmação ZK.
  • Canais laterais na geração da testemunha, navegador, hardware ou serviço remoto podem expor segredos antes da prova.
  • Verificação não fornece disponibilidade de dados, atividade do sequenciador, finalidade, resistência à censura ou upgrades seguros.
  • Premissas e margens concretas variam; tamanho ou velocidade de verificação não classificam sozinhos a segurança.

Equívocos comuns

  • “Conhecimento zero significa que nenhum dado é revelado.” A afirmação pública e saídas expostas continuam visíveis; metadados podem vazar fora do modelo.
  • “Uma prova válida significa que o aplicativo está correto.” A relação codificada foi aceita; erros de circuito, integração e política continuam possíveis.
  • “Todos os sistemas ZK têm as mesmas premissas de confiança.” Cerimônias, curvas, hashes, modelos de transcrição e controles de upgrade diferem muito.
  • “ZK é criptografia.” A criptografia oculta dados para um autorizado decifrar; uma ZKP comprova uma alegação sem enviar a testemunha para decifração.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...