O que é zkTLS: um guia para iniciantes

zkTLS é destinado a leitores que precisam levar valores de páginas da web ou APIs autenticadas a um contrato ou contraparte, não é um novo transporte que substitui o HTTPS. Em comparação com capturas de tela ou autodeclarações, ele transforma “a sessão acessou o site-alvo” e “o campo atende a um predicado” em evidências verificáveis. Os feeds contínuos de mercados públicos dependem mais frequentemente de oráculos de blockchain; a comparação com feeds aparece abaixo.

As seções a seguir abordam a definição, as etapas da sessão à prova, as diferenças entre MPC, Proxy e TEE, os casos de uso, o contraste com oráculos e os riscos, além de descrições públicas de mecanismos, como o explicador de zkTLS da Oasis e a página do padrão zk-TLS da EthSystems.

Principais pontos

• O zkTLS transforma uma sessão HTTPS em uma declaração verificável: vincula o domínio/certificado e, opcionalmente, divulga apenas o resultado de um predicado.
• O nome costuma ser enganoso: nem todo projeto usa provas de conhecimento zero no momento do handshake; MPC, Proxy e TEE são os três caminhos mais comuns.
• Como o TLS termina em uma chave de sessão simétrica compartilhada, um cliente isolado pode forjar uma demonstração de transcrição, daí a necessidade de notários, proxies ou TEEs.
• Procedência não é veracidade: se a origem retornar um campo incorreto, uma prova ainda poderá ser formalmente válida.
• Os verificadores devem checar a vinculação ao domínio/certificado, o predicado e a assinatura de atestado ou a raiz de confiança no caminho da prova.

O que é zkTLS e qual problema ele resolve?

O zkTLS aborda uma lacuna do TLS comum: o Transport Layer Security sustenta conexões HTTPS para navegadores, criptografando e autenticando o canal entre cliente e servidor. Porém, após o encerramento da sessão, é difícil convencer um terceiro de que o servidor realmente retornou aquele conteúdo sem entregar material de descriptografia que poderia ser usado indevidamente ou depender de capturas de tela. Por isso, contratos têm dificuldade para consumir campos obtidos após login.

Um handshake TLS padrão deriva uma chave de sessão simétrica: tanto o navegador quanto o servidor podem criptografar e descriptografar. Se uma pessoa usuária apresentar sozinha o texto cifrado junto com essa chave, outras partes não poderão descartar a possibilidade de ela ter criptografado um texto simples falso e depois o descriptografado sob demanda. Portanto, um cliente isolado não pode ser uma testemunha confiável. Essa limitação motiva o uso de notários, proxies ou TEEs.

O que o zkTLS fornece são evidências de procedência e integridade, não uma decisão final sobre a veracidade comercial. Provar que um campo de saldo veio da sessão TLS de um site não refuta uma inserção de dados incorreta ou uma página adulterada. Isso é próximo das narrativas sobre feeds de conhecimento zero em zkOracle e zkCoprocessor, mas pertence a um domínio de problema diferente.

Como o zkTLS funciona? Da sessão HTTPS à declaração verificável

Em alto nível, o zkTLS passa de uma sessão HTTPS normal para uma prova verificável: a pessoa usuária abre uma sessão com a origem; um caminho de notário MPC, Proxy ou TEE deixa evidências verificáveis; depois, é produzida e verificada uma prova de divulgação seletiva.

1. Abra a sessão — Inicie o TLS para o domínio-alvo; o certificado e a vinculação ao domínio passam a fazer parte da declaração posterior.
2. Ateste em conjunto ou delegue — Um notário participa do handshake/descriptografia (MPC), um proxy atesta a direção do texto cifrado (Proxy), ou um TEE executa a solicitação, para que um cliente isolado não consiga forjar facilmente texto cifrado enviado pelo servidor; alguns projetos tratam isso como um protocolo multiparticipante, e não como um fluxo de cliente isolado.
3. Busque o campo-alvo — Dentro da sessão, solicite a página da conta ou a API e receba a resposta criptografada.
4. Crie a declaração — Produza uma prova, ou assinaturas de caminho, sobre compromissos da transcrição, identidade do servidor e um predicado como saldo > limite; caminhos baseados em circuitos transformam restrições da transcrição em resultados de prova.
5. Envie para verificação — Um contrato ou contraparte verifica a prova e as raízes de confiança e, em seguida, aceita ou rejeita.

A divulgação seletiva é uma segunda camada comum: provar que um saldo excede um limite sem informar o valor exato, ou extrair um campo ocultando o restante. Conforme a nota da Reclaim sobre o “zk” em zkTLS, a privacidade por conhecimento zero costuma ser um aprimoramento; o requisito mais básico é convencer um terceiro de que a resposta realmente veio da origem.

Figura 1. O zkTLS passa de uma sessão HTTPS do cliente por um caminho de atestado MPC/Proxy/TEE até uma prova de divulgação seletiva verificada por um verificador ou contrato inteligente.

Uma lista de verificação para o verificador deve abranger pelo menos quatro itens: vinculação de domínio e certificado à origem declarada; um predicado alinhado às regras de negócio; assinatura ou raiz de confiança do caminho de prova em uma lista de permissões; e se mudanças na estrutura da origem interromperiam o analisador. Ignorar qualquer item transforma “verificável” em “parece uma prova”, embora o objetivo seja produzir dados verificáveis para contratos inteligentes ou contrapartes.

Por que é chamado de zkTLS? Como MPC, Proxy e TEE diferem?

“zkTLS” é um termo abrangente popular que sugere que provas de conhecimento zero precisam ser executadas no momento do handshake, mas isso nem sempre é verdade. O rótulo costuma ser usado amplamente para um protocolo híbrido, embora nem toda implementação realmente se encaixe nessa descrição. Muitos projetos se aproximam mais de provas web ou atestados TLS: o foco é a verificabilidade, não a obrigatoriedade de conhecimento zero dentro do handshake.

Os três caminhos respondem à mesma pergunta: como convencer um terceiro de que o texto cifrado veio do servidor sem entregar a chave simétrica para uso indevido. Proxies podem observar a direção da transferência de dados sem visualizar o texto simples. Projetos MPC/2PC, no estilo TLSNotary, usam chaves conjuntas para bloquear falsificação unilateral; projetos Proxy combinam atestados de direção com uma prova de descriptografia do lado da pessoa usuária; projetos TEE hospedam a sessão em isolamento de hardware. A privacidade por conhecimento zero pode ser adicionada para ocultação de campos, mas TEEs e a maioria dos handshakes MPC não usam conhecimento zero na camada de handshake.

A escolha de um caminho é uma decisão de modelo de ameaças e custo: se um único notário, proxy ou TEE é aceitável; se as sessões precisam manter baixa latência; se a origem fala apenas determinadas versões de TLS. Caminhos MPC também garantem que nenhum nó isolado detenha a chave completa. Interprete “zk” como um rótulo para dados web verificáveis, não como uma taxonomia criptográfica rigorosa.

Para que o zkTLS pode ser usado?

Um caso de uso clássico é provar que uma conta off-chain atende a um limite sem publicar o extrato completo: limites de saldo para elegibilidade de crédito, verificações de saldo bancário em fluxos financeiros sem revelar o valor exato, campos de emprego ou reputação de um portal com login e confirmação de atividade off-chain para regras de missões. O padrão compartilhado é que os dados ficam atrás de HTTPS, sem uma API pública assinada pronta para uso.

Casos de uso de identidade e atributos incluem verificação de identidade e credenciais verificadas, além de faixas etárias, níveis de associação ou classificações resumidas: o verificador vê o resultado de um predicado, não uma página completa de dados privados. Produtos estruturados como protocolos, como o oráculo zkTLS da zkPass, apresentam dados privados tornados verificáveis on-chain; diferencie como um protocolo encapsula provas do que o padrão zkTLS garante.

Outra categoria são os feeds de dados com preservação de privacidade: aplicações precisam de campos de sites em aplicações on-chain sem expor o texto simples completo da coleta a todos os observadores. Nesse caso, o zkTLS fornece uma prova de campo com procedência; ainda assim, ele deve ser distinguido de feeds contínuos de preços e da agregação de múltiplas fontes usada em finanças descentralizadas e em fluxos mais amplos entre web e blockchain.

Como o zkTLS difere dos oráculos tradicionais?

Os oráculos tradicionais se concentram em registrar fatos off-chain, como preços e resultados de eventos, em blockchains, muitas vezes por meio de conjuntos de nós ou feeds de múltiplas fontes. Essa diferença faz parte do problema dos oráculos: inserir dados off-chain ou da web confiáveis em contratos. O zkTLS se concentra em provar que campos de uma sessão HTTPS vieram de uma origem específica, opcionalmente com divulgação seletiva. Os feeds otimizam disponibilidade e resistência à manipulação; o zkTLS otimiza a transformação de uma sessão web em uma declaração verificável.

Ao comparar arquitetura de feeds, premissas de confiança e modos de falha, consulte zkTLS vs. oráculos tradicionais. Regra resumida: feeds contínuos de mercados públicos ainda se encaixam melhor em redes de oráculos maduras; campos privados obtidos após login que exigem divulgação mínima se encaixam melhor no zkTLS, enquanto alguns sistemas também tratam a portabilidade de dados como um objetivo de projeto separado. Os dois podem ser combinados, mas nenhum substitui o outro.

Quais são as vantagens e os riscos de usar ou depender de zkTLS para dados sensíveis?

As vantagens incluem exportar campos verificáveis sempre que a pessoa usuária ainda puder concluir o HTTPS com a origem, sem esperar por uma API de feed dedicada; a divulgação seletiva permite que contratos verifiquem um fato sem expor o registro privado completo; e as declarações podem ser verificadas programaticamente por contratos.

Os riscos são igualmente concretos. A honestidade e a disponibilidade de notários, proxies ou TEEs formam raízes de confiança: conluio, recusa ou indisponibilidade podem gerar aceitações incorretas ou falhas. Projetos baseados em TEE também apresentam riscos de segurança vinculados ao fabricante do hardware ou à raiz de atestado. A honestidade da origem está fora do escopo do protocolo: páginas incorretas ainda podem gerar provas formalmente válidas. Alterações no caminho de campos podem invalidar predicados; algumas pilhas de notários abrangem apenas determinadas versões de TLS.

As partes dependentes também devem considerar o custo de comprovação, a latência da sessão e o risco de retenção das transcrições de sessão. O zkTLS melhora a procedência verificável; ele não transforma páginas web arbitrárias em fontes de verdade não auditadas.

Resumo

O zkTLS transforma sessões HTTPS cotidianas em declarações verificáveis e com divulgação mínima, para que contratos possam verificar de qual servidor vinculado a um domínio veio um campo, em vez de confiar em capturas de tela. “zk” não garante conhecimento zero no momento do handshake; MPC, Proxy e TEE alcançam integridade sob diferentes premissas de confiança.

Antes da implementação, aceite que um cliente isolado com a chave simétrica pode encenar uma sessão falsa; as listas de verificação do verificador devem abranger domínio/certificado, predicado e raízes de confiança; procedência não é veracidade do conteúdo; e oráculos tradicionais e zkTLS separam feeds contínuos de provas de campos em páginas privadas. Escolha o caminho conforme o modelo de ameaças e inclua os riscos da origem e do atestado nesse modelo.

Perguntas frequentes

O que é zkTLS?

zkTLS é uma família de projetos baseada em TLS/HTTPS padrão que produz declarações que um terceiro pode verificar: que dados específicos vieram de um servidor vinculado a um domínio e certificado, divulgando opcionalmente apenas o resultado de um predicado. Ele conecta campos privados da Web2 à verificação por contratos sem substituir o HTTPS.

Como o zkTLS transforma uma sessão HTTPS em uma declaração verificável?

O cliente e a origem abrem uma sessão; um notário MPC, Proxy ou TEE atesta em conjunto ou delega a execução para que um cliente isolado não possa forjar o texto cifrado do servidor; uma prova de divulgação seletiva é criada; o verificador checa a vinculação ao domínio, o predicado e as raízes de confiança antes de aceitar ou rejeitar.

O zkTLS precisa usar provas de conhecimento zero no handshake TLS?

Não. Muitos sistemas chamados zkTLS usam MPC, Proxy ou TEE para integridade; as provas de conhecimento zero costumam aparecer posteriormente para divulgação seletiva ou provas de descriptografia no estilo Proxy. O handshake em si pode nunca executar um circuito de conhecimento zero, e “zk” é um rótulo comum.

Como o zkTLS difere dos oráculos tradicionais?

Os oráculos tradicionais alimentam continuamente contratos com fatos off-chain, com objetivos de múltiplas fontes e disponibilidade; o zkTLS prova a procedência, e opcionalmente predicados, de campos HTTPS no nível da sessão. Feeds públicos e campos de páginas privadas com login são problemas diferentes; consulte o tópico de comparação. Os dois podem ser combinados.

Quais são os principais riscos ao depender de zkTLS?

Os principais riscos incluem notários, proxies ou TEEs comprometidos ou indisponíveis; origens que fornecem dados incorretos enquanto as provas permanecem formalmente válidas; alterações na estrutura da página que interrompem analisadores; e limitações de versões de TLS. Ignorar verificações de vinculação ao domínio e de raízes de confiança aumenta o risco de aceitações incorretas.