Onde o zero knowledge é realmente usado: zkLogin, coprocessors e verificações de identidade

2026-08-24

Sistemas zero knowledge ficam mais claros quando cada prova corresponde a uma afirmação específica. Uma prova pode ocultar um campo de credencial, certificar um cálculo feito off-chain ou mostrar que uma regra de identidade foi satisfeita sem publicar o documento original. Ela não torna todos os componentes trustless e não transforma um login em uma identidade universal. Este artigo acompanha a fronteira entre prova ZK, zkLogin, coprocessor ZK e verificação de identidade.

O que uma prova zero knowledge realmente oculta

Uma prova zero knowledge permite que um prover convença um verifier de que uma afirmação é verdadeira enquanto mantém dados witness selecionados em segredo. A afirmação pode dizer que um token assinado contém certa relação, que um programa produziu um resultado ou que uma credencial satisfaz uma regra. A prova não é a afirmação: ela é evidência da relação entre entradas públicas e privadas definida por um circuito ou programa.

A privacidade, portanto, é seletiva. O verifier pode ver um resultado booleano, um commitment público, um identificador de rede, um identificador de programa ou um horário sem ver a entrada privada. Uma prova de idade mínima pode ocultar a data de nascimento, mas não prova que o emissor da credencial é confiável ou que a política usada está correta.

A pergunta prática não é apenas se o produto usa ZK. É preciso perguntar o que é público, o que é privado, quem produz o witness, quais chaves ou parâmetros de setup são confiáveis e quem verifica o resultado. Um sistema pode ter uma prova sólida e ainda depender de provedor OAuth, salt service, indexer, emissor de credenciais ou aplicação com uma regra fraca.

Como o zkLogin liga um login web a um endereço

Para entender zk login explained, comece pelo vínculo de identidade, não pela palavra wallet. O zkLogin da Sui usa OpenID Connect para obter um JSON Web Token assinado. A aplicação também cria um par de chaves efêmeras. O nonce do token combina a chave pública efêmera, aleatoriedade e uma epoch de expiração, vinculando a sessão de transação ao fluxo de login.

A documentação da Sui separa salt service e proving service. O salt, o issuer, a audiência da aplicação e o subject claim participam da derivação do seed do endereço. Se o salt continuar privado, o identificador OAuth pode ser separado do endereço on-chain. O proving service recebe o token e as entradas necessárias e produz uma prova Groth16 que verifica a assinatura do provedor, o nonce, o claim e a derivação do endereço.

O endereço e a chave de sessão têm durações diferentes. O endereço pode permanecer estável quando issuer, audiência, subject e salt não mudam, enquanto a chave efêmera expira na epoch prevista. Um novo login pode gerar uma nova chave e uma nova prova para o mesmo endereço. Validadores verificam a prova e a assinatura efêmera antes de executar a transação. É um fluxo específico do protocolo, não uma promessa de que todo social login cria identidade autocustodiada.

Os limites de confiança aparecem nos detalhes. O provedor OAuth autentica a conta e assina o token. A aplicação controla o frontend e a chave efêmera. O salt service e o proving service podem ver dados sensíveis conforme seu desenho. A Sui observa que esses serviços podem relacionar identidade e salt na própria visão, mesmo que o JWT não seja publicado on-chain. O resultado depende dessas hipóteses e da proteção do salt e da chave de sessão.

O que um ZK coprocessor calcula

A expressão zk coprocessor explained deve ser entendida como uma questão de arquitetura. Um coprocessor move uma tarefa pesada em dados ou computação para fora da cadeia da aplicação e devolve um resultado com prova de que usou entradas autenticadas e a computação declarada. Em um modelo ZK puro, um contrato verifier verifica a prova sem repetir todo o cálculo.

Fluxo de uma prova ZK entre uma entrada privada e um resultado verificável da aplicação

A documentação da Brevis apresenta três etapas: acesso a dados, computação da aplicação e uso do resultado. A aplicação solicita dados históricos, um prover off-chain executa a lógica e o resultado com a prova é verificado on-chain. O padrão pode apoiar limiar de atividade, regra de pertencimento, cálculo de recompensa ou sinal de risco. A prova certifica a relação codificada, não a adequação da fonte de dados por si só.

Isso é diferente de pedir uma resposta simples a um indexer. Uma resposta sem prova exige confiança na parte que escolheu os dados e fez o cálculo. Um ZK coprocessor pode reduzir essa confiança vinculando o resultado a dados de cadeia autenticados e a um circuito. Em troca, o circuito, commitments, sistema de prova, verifier e processo de atualização precisam ser avaliados.

Um coprocessor não é uma função única e imutável. A Brevis diferencia pure ZK de modelos coChain ou optimistic, com hipóteses diferentes de latência, custo e challenge. A RISC Zero descreve verifiable computation de modo mais geral: a saída do programa recebe um receipt que o verifier pode conferir sem executar tudo novamente nem ver entradas privadas. Cada implantação ainda precisa definir statement, autenticação de entradas e política de falhas.

Onde termina a prova de uma verificação de identidade

Uma verificação de identidade pode ser uma afirmação sobre uma credencial, não uma prova mágica sobre uma pessoa. O verifier pode perguntar se um issuer assinou a credencial, se ela está válida, se o subject supera um limite de idade ou se o identificador está em uma lista de revogação. Um circuito ZK pode ocultar campos desnecessários e revelar somente o resultado mínimo exigido pela aplicação.

A expressão zero knowledge identity verification deve ser separada nos papéis de issuer, holder e verifier. O modelo W3C Verifiable Credentials descreve claims emitidos por um issuer, mantidos por um subject ou holder e apresentados ao verifier com mecanismos de autenticidade e integridade. Os W3C DIDs descrevem identificadores e métodos de verificação, mas o formato não garante sozinho que uma pessoa, organização ou documento real seja verdadeiro.

Considere uma checagem de idade. A prova pode mostrar que uma data de nascimento assinada é anterior ao limite sem revelar a data. Ela não decide se o issuer verificou o documento com qualidade, se a credencial pertence ao holder atual, se o limite é válido em determinada jurisdição ou se houve revogação. Essas são perguntas de emissor, vínculo, política e ciclo de vida.

A mesma fronteira vale para sanções, residência, acreditação e unicidade de conta. Um circuito pode codificar o predicado “issuer aprovado e claim em conformidade”, mas não corrige registro fraco, credencial roubada, wallet comprometida, fonte errada ou feed de revogação incompleto. True significa que o predicado codificado passou nas entradas fornecidas, não que todos os fatos reais por trás delas sejam verdadeiros.

Privacidade é escolha de design, não saída da prova

ZK pode reduzir divulgação, mas a privacidade depende do fluxo completo. O verifier ainda pode observar endereço público, horário, rede, audiência da aplicação, frequência das provas ou o fato de uma política ter sido tentada. Apresentações repetidas podem ser correlacionadas se identificadores ou commitments públicos forem reutilizados. Metadados podem revelar mais do que o witness ocultado pelo circuito.

O zkLogin mostra isso por meio do salt e dos claims OpenID. O salt ajuda a separar o identificador OAuth do endereço on-chain, mas sua perda pode impedir a recuperação do endereço e sua exposição pode tornar o subject correlacionável. Provedor OAuth, frontend, salt service, proving service e validadores veem partes diferentes do fluxo. Uma análise de privacidade precisa mapear essas visões.

Para coprocessors, a privacidade também depende de onde os dados brutos e o witness são processados. Um verifier on-chain pode conferir o resultado sem ver entradas privadas, mas o prover off-chain ou o provedor de dados pode ter visto essas entradas. Se for necessário ocultá-las também do prover, um verifier ZK público pode não bastar; talvez sejam necessários private proving, execução segura ou computação cifrada.

O princípio de divulgação mínima é útil: prove apenas o predicado necessário, use audiência ou domain separator específico, faça rotação do material de sessão conforme o protocolo e registre retenção e riscos de correlação. Esses controles não eliminam confiança, mas tornam os caminhos restantes revisáveis.

O que o modelo de confiança precisa nomear

Comece pelo statement e pelas entradas públicas. Registre exatamente o que o verifier aceita, quais dados são comprometidos, como o estado da cadeia ou a credencial é autenticado e qual versão de software ou circuito produziu a prova. Se um contrato consome o resultado, identifique o código do verifier, a autoridade de upgrade, o caminho de emergência e o tratamento de dados antigos.

Depois nomeie os atores. Para zkLogin: provedor OpenID, aplicação, detentor da chave efêmera, salt service, proving service e validadores Sui. Para um coprocessor: fonte de dados, indexer ou light client, prover, verifier e mecanismo de challenge ou staking. Para uma checagem de identidade: issuer, holder, wallet ou camada de apresentação, verifier e serviço de revogação. Um ator ausente no diagrama é um sinal de risco.

Separe correção de disponibilidade e recuperação. Uma prova válida pode chegar tarde. Um provedor pode trocar chaves, um salt service pode ficar indisponível e uma credencial pode expirar. Reorganização da cadeia ou regra de finality pode mudar as entradas. Um caminho optimistic pode depender de um challenge honesto dentro de uma janela. Isso é propriedade operacional, não algo que a prova matemática conserta sozinha.

Por fim, verifique hipóteses de setup e upgrade. A Sui documenta uma cerimônia de common reference string Groth16 para zkLogin. Outros sistemas usam prova transparente, receipt de zkVM, trusted setup, comitê ou staking. Pergunte quem pode alterar circuito, verifier, cadastro de issuers, lista de provedores, fonte de dados ou política. Uma prova correta segundo a política de ontem pode ser inadequada hoje.

Como ler uma afirmação de identidade ZK

Quando a documentação diz que uma função é privada, transforme isso em perguntas: privada para quem, visível para quem, por quanto tempo e com que possibilidade de correlação. Quando diz trustless, pergunte qual ator foi removido e quem continua confiável para entradas, chaves, disponibilidade, recuperação e governança. Quando diz verificável, pergunte qual relação de cálculo ou credencial é coberta.

Faça cinco verificações. Primeiro, examine statement e witness. Depois, siga a ligação entre token do provedor ou credencial e endereço da aplicação ou apresentação. Identifique o cálculo off-chain e sua fonte autenticada. Liste as hipóteses de issuer, política, revogação e holder. Por fim, teste vazamentos por metadados, reutilização e visibilidade dos serviços.

Essa leitura separa três ideias. zkLogin pode ligar uma chave de transação efêmera a claims de um fluxo OpenID enquanto oculta alguns campos da cadeia. Um ZK coprocessor pode tornar verificável um cálculo off-chain em relação a dados declarados. Uma verificação de identidade pode provar que um predicado de credencial foi satisfeito. Nenhuma dessas afirmações prova sozinha honestidade do usuário, confiabilidade do issuer ou atualidade dos dados.

É aí que zero knowledge é realmente usado: em uma relação delimitada entre entradas, cálculo e verificação. O resultado útil não é uma promessa de identidade invisível, mas uma afirmação menor e auditável, com hipóteses explícitas de privacidade e confiança. Registre essas hipóteses junto com a versão do protocolo, a data das fontes e a política para que mudanças futuras sejam percebidas.

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.