zkTLS destina-se a quem precisa de levar valores de páginas Web ou API autenticadas para um contrato ou contraparte — não é um novo transporte que substitui o HTTPS. Em comparação com capturas de ecrã ou autorrelatos, transforma “a sessão acedeu ao site de destino” e “o campo cumpre um predicado” em evidências verificáveis. Os feeds contínuos de mercado público recorrem mais frequentemente a oráculos de blockchain; a comparação com feeds encontra-se abaixo.
As secções seguintes abordam a definição, os passos desde a sessão até à prova, as diferenças entre MPC/Proxy/TEE, casos de utilização, o contraste com oráculos e os riscos, juntamente com descrições públicas de mecanismos, como a explicação de zkTLS da Oasis e a página de padrões zk-TLS da EthSystems.
Pontos principais
- O zkTLS transforma uma sessão HTTPS numa afirmação verificável: associa o domínio/certificado e, opcionalmente, divulga apenas o resultado de um predicado.
- O nome é frequentemente enganador: nem todos os designs usam conhecimento zero no momento do handshake; MPC, Proxy e TEE são as três abordagens mais comuns.
- Como o TLS termina numa chave de sessão simétrica partilhada, um cliente isolado pode forjar uma demonstração de transcrição — daí a necessidade de notários, proxies ou TEE.
- A proveniência não é sinónimo de veracidade: se a origem devolver um campo incorreto, uma prova pode continuar formalmente válida.
- Os verificadores devem confirmar a associação ao domínio/certificado, o predicado e a assinatura de atestação ou raiz de confiança no percurso da prova.
O que é o zkTLS e que problema resolve?
O zkTLS resolve uma lacuna do TLS comum: o Transport Layer Security suporta ligações HTTPS para navegadores, ao cifrar e autenticar o canal entre cliente e servidor, mas, depois de a sessão terminar, é difícil convencer terceiros de que o servidor devolveu realmente esse conteúdo sem fornecer material de desencriptação passível de abuso ou recorrer a capturas de ecrã. Por isso, os contratos têm dificuldade em consumir campos pós-início de sessão.
Um handshake TLS padrão deriva uma chave de sessão simétrica: tanto o navegador como o servidor podem cifrar e desencriptar. Se um utilizador apresentar isoladamente texto cifrado juntamente com essa chave, as outras partes não conseguem excluir a possibilidade de o utilizador ter cifrado texto simples falso e depois o ter desencriptado a pedido — pelo que um cliente isolado não pode ser uma testemunha fiável. Esta limitação motiva a utilização de notários, proxies ou TEE.
O que o zkTLS fornece é evidência de proveniência e integridade, não uma decisão final sobre a veracidade comercial. Provar que um campo de saldo provém da sessão TLS de um site não invalida uma introdução de dados incorreta ou uma página adulterada — um tema adjacente às narrativas de feeds de conhecimento zero em zkOracle e zkCoprocessor, mas num domínio de problema diferente.
Como funciona o zkTLS? Da sessão HTTPS à afirmação verificável
Em termos gerais, o zkTLS passa de uma sessão HTTPS normal para uma prova verificável: o utilizador abre uma sessão com a origem; um percurso MPC de notário, Proxy ou TEE deixa evidências verificáveis; em seguida, é produzida e verificada uma prova de divulgação seletiva.
- Abrir a sessão — Iniciar TLS para o domínio de destino; o certificado e a associação ao domínio tornam-se parte da declaração posterior.
- Co-testemunhar ou delegar — Um notário participa no handshake/desencriptação (MPC), um proxy atesta a direção do texto cifrado (Proxy), ou um TEE executa o pedido, impedindo que um cliente isolado possa facilmente forjar texto cifrado enviado pelo servidor; alguns designs tratam este processo como um protocolo multipartidário, e não como um fluxo de cliente isolado.
- Obter o campo de destino — Na sessão, solicitar a página da conta ou a API e receber a resposta cifrada.
- Criar a afirmação — Produzir uma prova (ou assinaturas de percurso) sobre compromissos de transcrição, identidade do servidor e um predicado, como saldo > limiar; os percursos baseados em circuitos transformam restrições de transcrição em resultados de prova.
- Submeter 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 limiar sem revelar o montante exato, ou extrair um campo ocultando o restante. Segundo a nota da Reclaim sobre o “zk” em zkTLS, o conhecimento zero para privacidade é frequentemente uma melhoria; o requisito mais básico é convencer terceiros de que a resposta veio realmente da origem.
Figura 1. O zkTLS passa de uma sessão HTTPS do cliente por um percurso de atestação 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 elementos: associação do domínio e certificado à origem declarada; um predicado alinhado com as regras de negócio; assinatura do percurso da prova ou raiz de confiança numa lista de permissões; e se alterações na estrutura da origem poderiam interromper o analisador. Omitir qualquer elemento transforma “verificável” em “parece uma prova”, embora o objetivo seja produzir dados verificáveis para contratos inteligentes ou contrapartes.
Porque se chama zkTLS? Em que diferem MPC, Proxy e TEE?
“zkTLS” é um termo abrangente popular que sugere que as provas de conhecimento zero têm de ser executadas durante o handshake — mas nem sempre é esse o caso. O rótulo é frequentemente usado de forma ampla para um protocolo híbrido, embora nem todas as implementações correspondam realmente a essa descrição. Muitos designs estão mais próximos de provas Web ou atestações TLS: o foco é a verificabilidade, não a utilização obrigatória de conhecimento zero no handshake.
| Percurso |
Mecanismo principal |
Notas sobre confiança e custo |
| MPC / 2PC (notário ao estilo TLSNotary) |
A chave de sessão é detida conjuntamente, para que nem o utilizador nem o notário possam, isoladamente, forjar a transcrição |
Depende da honestidade e disponibilidade do notário; maior latência |
| Proxy |
Um proxy HTTPS atesta se o texto cifrado veio do navegador ou do servidor; o utilizador prova por conhecimento zero a desencriptação sem revelar a chave |
Menor sobrecarga; pressupõe que o proxy não colabora em declarações falsas sobre a direção |
| TEE |
Os pedidos são executados em ambientes de execução fidedignos que atestam a integridade da resposta |
Menor sobrecarga; depende do fabricante do chip, das raízes de atestação TEE e do isolamento de hardware resistente a adulterações |
As três abordagens respondem à mesma questão: como convencer terceiros de que o texto cifrado veio do servidor sem entregar a chave simétrica para utilização abusiva. Os proxies podem observar a direção da transferência de dados sem ver o texto simples. Os designs MPC/2PC (ao estilo TLSNotary) utilizam chaves conjuntas para impedir a falsificação unilateral; os designs Proxy combinam atestações de direção com uma prova de desencriptação do lado do utilizador; os designs TEE alojam a sessão num ambiente isolado por hardware. O conhecimento zero para privacidade pode ser acrescentado para ocultação de campos, mas os TEE e a maioria dos handshakes MPC não usam conhecimento zero na camada de handshake.
A escolha de uma abordagem é uma decisão de modelo de ameaças e custo: se um único notário, proxy ou TEE é aceitável; se as sessões têm de manter baixa latência; se a origem só suporta determinadas versões de TLS. Os percursos MPC também asseguram que nenhum nó individual detém alguma vez a chave completa. Interpretar “zk” como um rótulo para dados Web verificáveis — não como uma taxonomia criptográfica rigorosa.
Para que pode ser usado o zkTLS?
Um caso de utilização clássico é provar que uma conta off-chain cumpre um limiar 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 montante exato, campos de emprego ou reputação de um portal com sessão iniciada e confirmação de atividade off-chain para regras de missões. O padrão comum consiste em dados alojados atrás de HTTPS sem uma API pública assinada pronta a usar.
Os casos de utilização de identidade e atributos incluem verificação de identidade e credenciais verificadas, bem como escalões etários, níveis de adesã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; deve distinguir-se a forma como um protocolo encapsula provas daquilo que o padrão zkTLS garante.
Outra categoria são os feeds de dados que preservam a privacidade: as aplicações necessitam de campos de sites em aplicações on-chain sem expor o texto simples completo extraído a todos os observadores. Neste caso, o zkTLS fornece uma prova de campo com proveniência; ainda assim, deve ser distinguido dos feeds contínuos de preços e da agregação de múltiplas fontes utilizada nas finanças descentralizadas e em fluxos mais amplos de Web para blockchain.
Em que difere o zkTLS dos oráculos tradicionais?
Os oráculos tradicionais concentram-se em escrever factos off-chain, como preços e resultados de eventos, em blockchains, frequentemente através de conjuntos de nós ou feeds de múltiplas fontes. Esta diferença faz parte do problema dos oráculos: introduzir dados off-chain ou da Web fidedignos nos contratos. O zkTLS concentra-se em provar que campos de uma sessão HTTPS provêm de uma origem específica, opcionalmente com divulgação seletiva. Os feeds otimizam a disponibilidade e a resistência à manipulação; o zkTLS otimiza a transformação de uma sessão Web numa afirmação verificável.
Ao comparar a arquitetura de feeds, pressupostos de confiança e modos de falha, consultar zkTLS vs. oráculos tradicionais. Regra resumida: os feeds contínuos de mercados públicos continuam a adequar-se a redes de oráculos maduras; os campos privados pós-início de sessão que requerem divulgação mínima adequam-se melhor ao zkTLS, embora alguns sistemas também tratem a portabilidade de dados como um objetivo de design separado — os dois podem ser combinados, mas nenhum substitui o outro.
Quais são as vantagens e os riscos de utilizar ou depender do zkTLS para dados sensíveis?
As vantagens incluem exportar campos verificáveis sempre que o utilizador ainda consegue concluir HTTPS com a origem — sem esperar por uma API de feed dedicada; a divulgação seletiva permite que os contratos verifiquem um facto sem expor o registo privado completo; e as afirmações podem ser verificadas programaticamente por contratos.
Os riscos são igualmente concretos. A honestidade e disponibilidade de notários, proxies ou TEE constituem raízes de confiança: conluio, recusa ou indisponibilidade resultam em aceitações incorretas ou falhas. Os designs baseados em TEE também acarretam riscos de segurança ligados ao fabricante do hardware ou à raiz de atestação. A honestidade da origem está fora do âmbito do protocolo: páginas incorretas podem ainda produzir provas formalmente válidas. Alterações no percurso dos campos interrompem os predicados; algumas pilhas de notários abrangem apenas determinadas versões de TLS.
As partes dependentes devem também ponderar o custo de prova, a latência da sessão e o risco de retenção das transcrições de sessão. O zkTLS melhora a proveniência verificável; não transforma páginas Web arbitrárias em fontes de verdade sem auditoria.
Resumo
O zkTLS melhora as sessões HTTPS quotidianas, transformando-as em afirmações verificáveis e com divulgação mínima, para que os contratos possam verificar de que servidor associado a um domínio veio um campo — em vez de confiarem em capturas de ecrã. “zk” não garante conhecimento zero no momento do handshake; MPC, Proxy e TEE alcançam integridade com diferentes pressupostos de confiança.
Antes da implementação, deve aceitar-se que um cliente isolado com a chave simétrica pode encenar uma sessão falsa; as listas de verificação dos verificadores têm de abranger domínio/certificado, predicado e raízes de confiança; a proveniência não é a veracidade do conteúdo; e os oráculos tradicionais e o zkTLS separam feeds contínuos de provas de campos de páginas privadas. Escolher a abordagem de acordo com o modelo de ameaças e incluir nesse modelo os riscos da origem e da atestação.
Perguntas frequentes
O que é o zkTLS?
O zkTLS é uma família de designs baseada em TLS/HTTPS padrão que produz afirmações que terceiros podem verificar: que dados específicos vieram de um servidor associado a um domínio e certificado, divulgando opcionalmente apenas o resultado de um predicado. Faz a ponte entre campos privados da Web2 e a verificação por contratos sem substituir o HTTPS.
O cliente e a origem abrem uma sessão; um notário MPC, Proxy ou TEE co-testemunha ou delega, para que um cliente isolado não possa forjar texto cifrado do servidor; é criada uma prova de divulgação seletiva; o verificador confirma a associação ao domínio, o predicado e as raízes de confiança antes de aceitar ou rejeitar.
O zkTLS tem de usar provas de conhecimento zero no handshake TLS?
Não. Muitos sistemas identificados como zkTLS usam MPC, Proxy ou TEE para integridade; as provas de conhecimento zero surgem frequentemente mais tarde para divulgação seletiva ou provas de desencriptação ao estilo Proxy. O handshake em si pode nunca executar um circuito de conhecimento zero — “zk” é um rótulo comum.
Em que difere o zkTLS dos oráculos tradicionais?
Os oráculos tradicionais fornecem continuamente factos off-chain a contratos com objetivos de múltiplas fontes e disponibilidade; o zkTLS prova a proveniência, e opcionalmente predicados, para campos HTTPS ao nível da sessão. Os feeds públicos e os campos de páginas privadas com início de sessão são problemas diferentes; consultar o tema de comparação — os dois podem ser combinados.
Quais são os principais riscos ao depender do zkTLS?
Os principais riscos incluem notários, proxies ou TEE comprometidos ou indisponíveis; origens que fornecem dados incorretos enquanto as provas permanecem formalmente válidas; alterações na estrutura das páginas que interrompem os analisadores; e limitações de versões TLS. Omitir verificações de associação ao domínio e de raízes de confiança aumenta o risco de aceitações incorretas.
