Provas de conhecimento zero: SNARKs, STARKs e o que elas de fato provam

2026-08-24

Uma prova de conhecimento zero é um método criptográfico para estabelecer que uma afirmação cuidadosamente especificada é válida sem revelar a informação privada que torna essa afirmação válida. O nome pode levar a interpretação excessivamente ampla. Ele não significa que um sistema não revele nada. Em geral, uma prova expõe que uma afirmação definida satisfez regras de verificação definidas, e uma aplicação ainda pode expor entradas públicas, horários, logs, identificadores ou outros metadados fora da própria prova.

Portanto, a pergunta útil é específica: qual afirmação está sendo provada, o que é privado, o que é público e o que uma verificação bem-sucedida estabelece? Este artigo introduz esses termos antes de explicar SNARK e STARK como famílias amplas de sistemas de prova de conhecimento zero. É uma explicação educacional, não uma recomendação para usar, selecionar ou confiar em um sistema de prova específico.

Diagrama conceitual de um provador produzindo uma prova verificada por um verificador

Afirmações, testemunhas e relações definidas

Todo sistema de prova começa com uma relação que ele consegue avaliar. A parte pública costuma ser chamada de afirmação. Uma afirmação pode dizer que um valor satisfaz condições publicadas ou que uma computação produziu uma saída segundo conjunto declarado de regras. A informação que demonstra por que a afirmação é verdadeira é normalmente chamada de testemunha. Uma testemunha pode ser valor secreto, conjunto de entradas ou outra informação privada definida pelo sistema de prova.

A fronteira entre afirmação e testemunha é importante. Um verificador só consegue verificar a relação que foi codificada. Se uma afirmação diz que uma entrada atende a condição determinada, a aceitação estabelece essa condição sob as regras do sistema. Ela não estabelece automaticamente de onde veio a entrada, se todos os fatos reais relevantes foram incluídos ou o que uma pessoa pretende fazer após a verificação. Essas questões exigem suas próprias evidências, definições e governança.

Muitos sistemas descrevem a relação por meio de um circuito semelhante a programa. Aqui, circuito é uma abstração de operações restritas que o sistema de prova consegue conferir; não é simplesmente um programa comum de aplicação. A forma de escrever uma relação, os campos que usa e as restrições que aplica variam entre construções. Consequentemente, uma prova trata de relação precisa, não de alegação vaga sobre a realidade.

Esse vocabulário também explica por que uma afirmação bem formada é essencial. Se uma relação omite condição importante, uma prova ainda pode ser válida para a relação incompleta. A criptografia pode proteger a integridade da relação definida; ela não decide quais exigências do mundo real deveriam ter sido colocadas nela.

O que o conhecimento zero oculta e o que não oculta

A propriedade de conhecimento zero diz respeito ao que um verificador aprende ao receber ou interagir com uma prova. Informalmente, o verificador deve se convencer de que uma afirmação é válida sem aprender a testemunha além do que a própria afirmação revela. Trabalhos clássicos sobre sistemas de prova interativos formalizaram essa intuição comparando a visão real de um verificador com uma visão simulada que não usa a testemunha.

Essa propriedade pertence a um protocolo, e não automaticamente a todas as camadas de uma aplicação ao redor. Um sistema pode publicar deliberadamente uma afirmação ou entrada pública. Pode manter logs, expor identificador ou comunicar-se por uma rede que carrega metadados. Uma prova pode limitar a divulgação sobre uma testemunha enquanto outras partes do sistema criam riscos de privacidade diferentes. Uma análise de privacidade deve considerar todo o fluxo de informação, e não apenas a presença de uma prova de conhecimento zero.

Conhecimento zero também não torna o verificador passivo. Ele recebe material de prova suficiente para executar as verificações prescritas. O protocolo é projetado para que esse material sustente a aceitação da afirmação sem fornecer a testemunha secreta em forma utilizável, sujeitos aos pressupostos da construção e ao escopo declarado. O que é revelado de propósito deve continuar claro para qualquer pessoa que interprete o resultado.

O provador e o verificador

O provador é a parte ou componente que possui a testemunha e gera uma prova. O verificador recebe a afirmação pública, parâmetros públicos aplicáveis e dados da prova, e então executa o procedimento de verificação do sistema. Esses são papéis, não tipos fixos de pessoas. Uma aplicação pode organizá-los como serviços independentes, componentes locais ou participantes de ambiente distribuído.

Geração e verificação de prova servem a finalidades diferentes. O provador demonstra que consegue satisfazer a relação usando a testemunha. O verificador confere se a prova está de acordo com a relação e as regras de verificação. Ele não precisa reproduzir o cálculo privado apenas porque recebeu uma prova. A quantidade exata de trabalho, material de prova, interação e preparação pública difere entre construções.

O contexto também importa. Uma prova válida para uma afirmação não é automaticamente significativa para outra. Versões, entradas públicas, definições de relação e material de verificação podem afetar a interpretação. Um sistema de prova não consegue decidir se resultado técnico é apropriado para decisão jurídica, científica, organizacional ou social. Definir a relação e decidir como interpretar o resultado continuam sendo responsabilidades da aplicação.

Completude, solidez e aceitação

Duas propriedades fundamentais ajudam a explicar a utilidade da verificação. Completude significa, em termos gerais, que um provador honesto com testemunha válida para uma afirmação verdadeira deve conseguir produzir prova que um verificador honesto aceite. Sem completude, participante correto poderia ser rejeitado apesar de a relação ter sido satisfeita.

Solidez trata da direção oposta. Em linhas gerais, ela diz que um provador não deve conseguir fazer um verificador aceitar uma afirmação falsa, exceto com a probabilidade limitada ou sob os pressupostos especificados pelo sistema. Solidez não é uma propriedade universal de checagem de fatos. Aplica-se a uma relação formal, modelo de adversário e definição de segurança. Não prova independentemente que entradas foram coletadas corretamente ou que uma alegação do mundo real que não foi codificada é verdadeira.

Algumas construções também discutem solidez de conhecimento. Em alto nível, o termo vincula uma prova bem-sucedida à ideia de que o provador possui, ou consegue produzir, testemunha do tipo necessário. Sua definição precisa é técnica e específica da construção. Ela não deve ser reformulada como alegação de que o provador conhece todo fato contextual que um leitor possa associar à afirmação pública.

Juntas, completude e solidez dão sentido limitado à aceitação: evidência corretamente formada para relação verdadeira deve ser aceita, enquanto relações falsas não devem ser aceitas apenas porque foram afirmadas. Elas não eliminam a necessidade de formular a relação correta, implementá-la corretamente e avaliar o resultado em contexto.

Geração e verificação de provas em contexto

No nível conceitual, a geração começa com afirmação pública, testemunha privada e uma relação que as vincula. O provador realiza as operações prescritas pelo sistema de prova e produz dados de prova. A verificação começa com a afirmação pública, o material de verificação necessário e esses dados. O verificador então retorna aceitação ou rejeição segundo o protocolo.

Sistemas diferentes fazem escolhas diferentes sobre interação, aleatoriedade, parâmetros públicos, pressupostos criptográficos e forma de representar computações. Alguns incluem uma fase de configuração que cria parâmetros; outros são chamados transparentes por evitarem participante secreto de configuração. Essas escolhas são importantes, mas os rótulos por si só não estabelecem que uma implementação completa tenha as propriedades de segurança pretendidas.

Quatro perguntas permanecem úteis para leitores em todos os sistemas. Qual afirmação exata é pública? Qual é a testemunha? Qual material de verificação é presumido ou confiável? O que a aceitação estabelece e o que deixa sem resposta? Elas são relevantes quando a prova está ligada a registro, credencial, banco de dados ou outro sistema de software.

SNARK e STARK como famílias de sistemas de prova

SNARK costuma ser expandido como Succinct Non-interactive Argument of Knowledge, ou argumento sucinto não interativo de conhecimento. Em termos amplos, construções SNARK procuram permitir que um provador produza prova compacta que um verificador confira sem troca interativa. Argumento tem sentido técnico: a segurança repousa em pressupostos computacionais, e não em garantia matemática incondicional. Construções individuais podem diferir em modelo de configuração, pressupostos, representação da prova e relações que suportam.

Pesquisas como o artigo Pinocchio ilustram uma estrutura conhecida de computação verificável: material público descreve computação, um executor produz prova para uma entrada específica e um verificador confere essa prova. Esse exemplo histórico não deve ser tomado como definição de todos os sistemas posteriores chamados SNARK. O termo abrangente cobre ideias relacionadas, não uma implementação uniforme.

STARK costuma ser expandido como Scalable Transparent Argument of Knowledge, ou argumento transparente e escalável de conhecimento. O termo está associado a construções que enfatizam transparência no modelo de configuração e usam técnicas de prova diferentes das abordagens comuns de SNARK baseadas em emparelhamento. A pesquisa STARK original discute integridade computacional transparente e um contexto de segurança pós-quântica. Essas descrições dizem respeito a uma construção e seus pressupostos; não tornam toda implementação intercambiável nem estabelecem resultado universal.

Assim, a comparação útil é específica. Ela considera pressupostos formais de uma construção, requisitos de configuração, representação da relação, ambiente de verificação, qualidade da implementação e dados públicos. SNARK e STARK são mapas de conceitos, não conclusões automáticas sobre segurança, privacidade ou adequação de um sistema.

Escopo, limitações e confiança ao redor

Uma prova válida estabelece apenas a afirmação representada por sua relação. Ela não mostra de modo independente que dados subjacentes foram coletados de maneira justa, que uma fonte tinha autorização, que um evento fora do sistema ocorreu ou que a afirmação continua atual. Se uma relação recebe entradas incompletas ou enganosas, a verificação pode continuar correta em relação a essas entradas. A prova protege computação definida, não toda interpretação possível de seu resultado.

Conhecimento zero também não elimina todas as considerações de privacidade. Entradas públicas podem revelar informações. Apresentações repetidas podem criar associações. Metadados de rede, dispositivo, conta, interface e aplicação podem existir fora da prova. Um desenho precisa examinar diretamente esses canais em vez de tratar a prova como fronteira completa de privacidade.

A segurança prática depende ainda de pressupostos matemáticos, do tratamento de parâmetros quando aplicável, de software correto e de verificador que avalie a afirmação pretendida. Falhas em qualquer camada podem alterar o resultado. Por isso, rótulos curtos como SNARK ou STARK devem ser ponto de partida para leitura cuidadosa, não julgamento final.

Ao interpretar uma alegação de prova, identifique afirmação, testemunha, entradas públicas, provador, verificador e material de verificação. Depois separe aceitação técnica de confiança mais ampla: um verificador pode estabelecer que um resultado atende às regras do protocolo e ainda precisar avaliar fontes, definições, contexto e suas próprias políticas. Essa distinção disciplinada captura o que provas de conhecimento zero realmente provam e onde permanecem seus limites.

Leituras relacionadas

Outros artigos da Bitbase sobre este tema:

- Prova de personalidade e resistência a Sybil

- Transações privadas, shielded addresses e view keys

- Como a elegibilidade para um airdrop é decidida: snapshots, pontos e filtros Sybil

Aviso: Este artigo é conteúdo educacional da Bitbase Academy, fornecido apenas para fins informativos. Não constitui aconselhamento de investimento, negociação, tributário ou financeiro. Criptoativos são voláteis; avalie seu próprio risco. Escrito em agosto de 2026; consulte as informações oficiais mais recentes.