zkTLS vs. oráculos tradicionais: quais dados da web são mais adequados para a blockchain?

Esta comparação é destinada a leitores de produto e risco que escolhem entre campos de páginas privadas e feeds públicos. O mecanismo em si é explicado em zkTLS; o termo abrangente para pontes de dados off-chain é abordado em oráculos de blockchain. As seções abaixo comparam fonte, privacidade, confiança e latência, além de abordar o limite entre capturas de tela/PDFs e proveniência criptográfica.

A seguir estão as dimensões e uma lista de “Escolha se”, incluindo onde capturas de tela ou PDFs terminam e a proveniência criptográfica começa. Os wrappers em formato de protocolo incluem o oráculo zkTLS zkPass; as narrativas de feeds de conhecimento zero aparecem ao lado de zkOracle e zkCoprocessor.

Principais conclusões

• O zkTLS é otimizado para comprovar de qual servidor vinculado a um domínio veio um campo de sessão HTTPS; os oráculos tradicionais são otimizados para registrar continuamente fatos públicos on-chain com resistência a manipulações.
• Páginas privadas pós-login sem APIs públicas assinadas são adequadas para zkTLS; preços de mercado contínuos e agregação de múltiplas fontes são adequados para redes de oráculos maduras.
• A divulgação seletiva é uma vantagem comum do zkTLS; feeds tradicionais geralmente publicam valores agregados para todos os observadores on-chain.
• Capturas de tela e uploads de PDF podem apoiar operações, mas não possuem proveniência de sessão verificável; alegações criptográficas comprovam proveniência e integridade, não a veracidade da origem.
• Escolha com uma lista de “Escolha se” e inclua o risco de cartório/conjunto de nós e os erros de origem no modelo de ameaças.

A tabela resume a escolha em dimensões fáceis de analisar: fonte e acesso definem quem pode ver os dados; privacidade e raízes de confiança definem o custo de falsas aceitações; latência e tipo de dados definem qual caminho é mais econômico de desenvolver. As capturas de tela têm sua própria linha porque as operações frequentemente tratam imagens como “prova”, mas essa não é a mesma classe de evidência que a proveniência criptográfica.

Figura 1. Comparação lado a lado entre zkTLS e oráculos tradicionais quanto ao acesso à fonte, privacidade, pressupostos de confiança e latência.

O que é zkTLS?

zkTLS, como uma família de técnicas, transforma campos dentro de uma sessão TLS/HTTPS em alegações que terceiros podem verificar: vincula domínio e certificado e, opcionalmente, divulga apenas o resultado de um predicado, por exemplo, que um saldo excede um limite, sem revelar todo o texto em claro.

O zkTLS não substitui o HTTPS e não decide automaticamente se os fatos comerciais da origem estão corretos; ele fornece evidências de proveniência e integridade, sendo a segurança da camada de transporte o protocolo HTTPS que permite a troca segura de dados entre um cliente e um servidor. As equipes usam MPC, um caminho Proxy ou um TEE como caminhos comuns de integridade; “zk” costuma ser um rótulo abrangente, e o handshake TLS pode nunca executar um circuito de conhecimento zero, mesmo que uma prova de conhecimento zero seja uma camada opcional dentro da família mais ampla de protocolos.

Na prática, o cliente abre uma sessão TLS com o servidor de origem. Como a chave de sessão é compartilhada entre cliente e servidor, um cliente isolado pode criptografar bytes arbitrários e posteriormente “descriptografá-los”, portanto outras partes não podem tratar uma transcrição bruta como saída honesta do servidor. Por isso, os projetos de zkTLS adicionam uma testemunha: um cartório MPC que executa conjuntamente o protocolo com o cliente, um Proxy que atesta a direção do texto cifrado ou um TEE que mantém a chave dentro de um ambiente de computação isolado. A prova resultante permite que verificadores usem a alegação sem conhecer toda a página ou a chave de sessão.

O que é um oráculo tradicional?

Os oráculos tradicionais gravam fatos off-chain no estado on-chain para que um contrato inteligente possa acessar dados externos de fontes off-chain ou do mundo real. As saídas típicas são feeds de preços, taxas, resultados esportivos ou resultados de eventos públicos, e essas redes são mais fortes com dados públicos ou disponíveis publicamente, em vez de registros privados de usuários. O foco do projeto costuma ser agregação de múltiplas fontes, disponibilidade dos nós e resistência a manipulações, não comprovar qual campo HTML apareceu na sessão autenticada de um usuário.

Os contratos leem atualizações de feeds, não transcrições de navegadores. Dados contínuos de mercados públicos se adequam naturalmente a esse caminho; campos de páginas de login privadas frequentemente não têm uma API pública assinada, e as redes de feeds não reproduzem por padrão a sessão HTTPS de cada usuário. Por isso, aplicações descentralizadas costumam usar oráculos para dados externos compartilhados, e não para evidências de sessões pessoais. As partes de um oráculo geralmente operam servidores que consultam endpoints públicos; elas não ficam dentro do canal TLS do cliente de um usuário e, portanto, não podem usar casualmente uma página bancária privada como um protocolo zkTLS de cliente com testemunha pode.

Como as fontes de dados e os caminhos de acesso diferem?

A divisão central é a seguinte: o zkTLS acompanha sessões que o usuário já pode abrir com uma origem; os oráculos tradicionais acompanham fontes públicas que nós operadores podem buscar.

Em um caminho zkTLS, o cliente conclui o HTTPS com o servidor do domínio de destino, e a prova pode ser gerada a partir de qualquer site HTTPS sem exigir acesso prévio à API. Alguns projetos usam um modelo Proxy, no qual um intermediário testemunha ou encaminha a troca entre cliente e servidor em vez de usar processamento de sessão no estilo MPC. Outras abordagens baseadas em MPC executam conjuntamente o handshake TLS, a etapa do protocolo que configura a chave segura da sessão, para que nenhuma parte isoladamente falsifique o texto cifrado do servidor. Um cartório, Proxy ou TEE deixa evidências verificáveis; em seguida, uma prova de alegação é criada. Em um caminho de oráculo tradicional, os nós buscam plataformas, índices ou APIs públicas, agregam os dados em um feed, e os contratos leem esse feed. Isso torna o zkTLS útil para verificar dados da Web2 em sistemas existentes quando não há um feed público simples. Caso contrário, a validação tradicional de dados ou outro processo de confirmação exigiria que uma parte separada buscasse diretamente a mesma fonte. Sem uma sessão de usuário, o zkTLS não pode substituir um feed público; sem fontes públicas que possam ser buscadas, os nós não podem consumir com segurança campos privados pós-login. Abordagens compatíveis com o servidor também dependem de os servidores de origem permitirem a exportação, de modo que os operadores possam limitar o que é compartilhado. Portanto, os produtos que usam Provas Web tratam o cliente, o servidor e as partes testemunhas como um único caminho de protocolo. Explicações públicas sobre o mecanismo, como o explicativo de zkTLS da Oasis e a página de padrões zk-TLS da EthSystems, descrevem o mesmo caminho de sessão para prova.

Como a privacidade, os dados privados e a divulgação seletiva diferem?

Uma capacidade comum do zkTLS é a divulgação seletiva: comprovar que um limite foi atingido sem publicar o valor exato, ou extrair um campo ocultando o restante. Ele também pode comprovar alegações sobre esses dados sem revelar todo o conteúdo. Isso torna o zkTLS útil quando dados privados ou sensíveis precisam ser comprovados sem expor o registro completo. Quando um feed de oráculo tradicional está on-chain, o valor agregado geralmente fica visível para todos os observadores, portanto os objetivos de privacidade frequentemente entram em conflito com um feed totalmente legível.

Se um produto precisa de controles de elegibilidade sem extratos completos, o zkTLS se adequa ao objetivo. Isso é especialmente relevante ao comprovar dados pessoais ou sensíveis, como identidade legal ou registros financeiros, com divulgação seletiva. Se um produto precisa que todos façam a liquidação com base no mesmo preço público, os feeds tradicionais se adequam ao objetivo. Os dois também podem ser combinados: preços públicos via oráculos e atributos privados de usuários via alegações zkTLS, o que ajuda a levar dados privados da internet on-chain sem ampla divulgação; alguns sistemas descrevem isso como um modelo que permite verificar dados privados da internet on-chain a partir de sites HTTPS sem expor o registro completo.

A divulgação seletiva geralmente fica sobre a prova de transcrição TLS. O cliente ainda se comunica com o servidor de origem; as partes testemunhas ajudam a vincular a resposta; depois, um circuito ou protocolo de redação produz uma prova menor que outras partes podem usar. Em um projeto MPC, a chave de sessão pode ser dividida para que nenhuma parte isolada possa abusar dela. Em um projeto Proxy, o Proxy atesta o texto cifrado enquanto o cliente mantém a chave de descriptografia e comprova conhecimento do texto em claro dentro de uma computação. De qualquer forma, o objetivo é usar campos privados sem enviá-los a cada servidor verificador.

Como os pressupostos de confiança, a integridade dos dados e os modos de falha diferem?

A confiança no zkTLS baseia-se na vinculação de domínio/certificado e em se o caminho de cartório, Proxy ou TEE é honesto e está disponível. Se o servidor de origem retornar um campo incorreto, uma prova formalmente válida ainda poderá ser aceita, pois proveniência não é o mesmo que veracidade do conteúdo. Quando a divulgação de conhecimento zero é implementada corretamente, o verificador não toma conhecimento das informações pessoais do provador. Os revisores ainda devem perguntar quais partes detêm material de chave, quais partes executam o protocolo MPC ou Proxy e qual certificado de servidor fixa o endpoint TLS.

A confiança nos oráculos tradicionais baseia-se na composição do conjunto de nós, nas regras de múltiplas fontes e nos incentivos econômicos. As falhas geralmente se apresentam como manipulação de fontes, conluio entre nós ou feeds desatualizados/tendenciosos. Registros privados também introduzem riscos adicionais de segurança e preocupações com vazamento de dados caso um verificador ou operador precise inspecioná-los diretamente. As listas de verificação diferem: o zkTLS enfatiza vinculação, predicado, autenticidade dos dados, integridade dos dados e verificações de raiz de confiança; os oráculos enfatizam atualização, limites de desvio e fontes de agregação. Ignorar as verificações de qualquer lado transforma “parece utilizável” em uma falsa sensação de verificação. Uma falsificação no lado do cliente continua sendo um modo de falha importante se não houver testemunha; uma testemunha corrompida é um modo de falha importante se as partes do protocolo agirem em conluio.

Como equilibrar latência, custo e tipos de dados?

Três regras práticas: dados contínuos de mercados públicos favorecem oráculos tradicionais; provas pontuais ou de baixa frequência sobre dados específicos do usuário ou dados financeiros favorecem zkTLS; capturas de tela e PDFs são adequados para registros operacionais, não para proveniência criptográfica.

O zkTLS incorre em custos por sessão e de comprovação, geralmente com latência maior que a de um caminho de feed ativo, e é adequado para limites de saldo, níveis de associação e campos de emprego ou reputação. Isso inclui comprovar que uma conta bancária ou o saldo de uma conta bancária supera um limite exigido sem expor as credenciais subjacentes ou o extrato completo. Um caminho TLS com MPC pode exigir intensa comunicação; um caminho Proxy pode usar computação menos interativa, mas ainda precisa de um servidor testemunha ativo; caminhos TEE transferem o tratamento de chaves para hardware isolado. Os oráculos tradicionais mantêm atualizações contínuas e são adequados para preços, taxas e eventos públicos, projetados para dados de mercado de baixa latência que muitos aplicativos clientes usam a cada bloco.

Capturas de tela, PDFs ou uploads manuais podem mostrar “algo que parece uma página”, mas um terceiro não pode verificar criptograficamente que uma sessão TLS atingiu o servidor do domínio de destino ou que os campos não foram editados pelo cliente. Alegações no estilo zkTLS podem garantir a autenticidade dos dados e preservar a proveniência dos dados para esse tipo de entrada privada, mas ainda não comprovam que os fatos comerciais da origem são verdadeiros. Mesmo assim, páginas de origem incorretas, falhas de DOM e indisponibilidade do cartório ainda prejudicam a correção ou a disponibilidade. Tratar capturas de tela como o único controle significa confiar no remetente e no revisor; tratar provas como “verdade” ignora que erros de origem podem continuar formalmente válidos. As equipes que usam tanto capturas de tela quanto provas criptográficas devem identificar qual classe de evidência cada controle aceita.

Você deve escolher zkTLS ou um oráculo tradicional?

Prefira zkTLS se: os dados estiverem em uma página HTTPS pós-login ou API privada que um cliente possa abrir com um servidor de origem; for necessária divulgação mínima no nível de predicado; não houver um feed público pronto de múltiplas fontes; a latência de comprovação por solicitação e uma raiz de confiança de cartório, Proxy ou TEE forem aceitáveis; esse costuma ser o melhor caminho para verificação de identidade ou outras provas sobre registros privados de usuários em que a divulgação completa é inaceitável. Escolha MPC quando a computação conjunta entre partes for mais importante que a conveniência do navegador; escolha Proxy quando quiser usar recursos Proxy existentes do cliente; escolha TEE quando a custódia isolada de chaves for o principal controle.

Prefira um oráculo tradicional se: forem necessários preços contínuos de mercados públicos ou resultados de eventos; os contratos precisarem liquidar com base em um feed legível pela rede; agregação madura de múltiplas fontes e monitoramento de desvios já existirem; a privacidade não for a principal restrição do campo, e esses feeds geralmente orientarem decisões de contratos inteligentes com base em sistemas externos compartilhados, em vez de registros pessoais. As redes de oráculos são criadas para que muitos contratos clientes possam usar o mesmo feed público sem que cada usuário abra uma sessão TLS privada.

Combine ambos se: os preços públicos passarem por um oráculo e os atributos privados do usuário passarem por zkTLS. Essa combinação é comum quando os aplicativos precisam de feeds públicos e alegações privadas para fluxos de trabalho de ativos do mundo real ou lógica comercial sensível. De qualquer forma, inclua “proveniência ≠ verdade” nas regras: erros de servidor de origem, conluio entre nós, corrupção do cartório, tratamento fraco de chaves e reformulações de páginas são riscos de primeira classe, não observações secundárias. A escolha do protocolo deve identificar quais partes precisam permanecer honestas para que a prova continue significativa.

Resumo

zkTLS e oráculos tradicionais respondem a perguntas on-chain diferentes: os oráculos tradicionais atendem principalmente a dados externos compartilhados, enquanto o zkTLS ajuda a tornar registros privados da web verificáveis com preservação de privacidade. Historicamente, essa lacuna significou que feeds públicos eram mais fáceis de usar, deixando os dados privados relativamente subutilizados. Após comparar acesso à fonte, privacidade, raízes de confiança e latência, campos de páginas de login privadas e feeds públicos raramente substituem um ao outro.

Em resumo: use um oráculo tradicional quando muitos contratos precisarem do mesmo feed público; use zkTLS quando um cliente precisar comprovar uma resposta TLS privada de um servidor de origem com uma prova de divulgação seletiva. MPC, Proxy e TEE continuam sendo os principais estilos de testemunha para esse caminho de protocolo, e cada um altera quais partes detêm o material de chave e quanto de computação interativa o cliente deve executar. Capturas de tela e PDFs não podem preencher uma lacuna de proveniência criptográfica; uma prova TLS não pode garantir automaticamente que o conteúdo da origem está correto. Escolher com uma lista de “Escolha se” e incluir os modos de falha de cartório/nó e de origem no modelo de ameaças é melhor do que discutir rótulos.

Perguntas frequentes

Qual é a diferença entre zkTLS e oráculos tradicionais?

Os oráculos tradicionais fornecem principalmente dados públicos a um contrato inteligente, enquanto os produtos usam zkTLS quando a autenticidade dos dados deve ser demonstrada para uma sessão HTTPS detida pelo usuário; isso também afeta se o verificador vê o registro subjacente ou apenas uma prova sobre ele. O zkTLS comprova que os campos em uma sessão TLS vieram de um servidor vinculado a um domínio e certificado, e alguns projetos usam MPC, ou computação segura multipartidária, durante o handshake TLS entre as partes cliente e cartório, enquanto outros dependem de testemunhas baseadas em Proxy ou TEE; os oráculos tradicionais gravam continuamente fatos públicos off-chain, como preços, em contratos por meio de conjuntos de nós e agregação de múltiplas fontes. Um é otimizado para a proveniência da sessão; o outro é otimizado para disponibilidade do feed e resistência a manipulações. Em projetos baseados em Proxy ou testemunha, o próprio servidor de origem geralmente não precisa mudar, e o cliente ainda detém ou compartilha a chave de sessão conforme as regras do protocolo.

Quando você deve usar zkTLS em vez de um oráculo tradicional?

Use zkTLS para campos privados pós-login que precisam de divulgação mínima e não têm uma API pública assinada, especialmente quando um produto precisa de compartilhamento verificável de dados de uma fonte privada usando um token de acesso ou credenciais de sessão, para que o cliente possa se autenticar diretamente no servidor de origem em vez de entregar registros brutos a um intermediário. Algumas implementações executam a computação de prova de conhecimento zero localmente, de modo que atributos selecionados possam ser comprovados sem enviar o registro completo. Use oráculos tradicionais para preços contínuos de mercados públicos ou resultados de eventos que precisem de liquidação legível pela rede; isso pode manter registros privados fora de um feed de oráculo público e ainda permitir que contratos usem preços compartilhados. Feeds públicos e atributos privados podem ser combinados em um produto quando diferentes partes precisam de diferentes classes de evidência.

Capturas de tela ou uploads de PDF podem substituir uma prova zkTLS?

Não de forma confiável. Capturas de tela e PDFs de uma página da web podem parecer persuasivos do ponto de vista operacional, mas não possuem proveniência de sessão TLS verificável e não carregam uma prova criptográfica da origem ou integridade da sessão, portanto um terceiro não pode descartar facilmente imagens editadas ou páginas incorretas. Em contraste, uma testemunha Proxy HTTP pode observar ou encaminhar a troca para preservar uma proveniência verificável de uma forma que uma captura de tela ou PDF não pode. Alegações no estilo zkTLS fornecem caminhos de vinculação de domínio e verificação de integridade, mas, se a origem retornar dados incorretos, uma prova ainda poderá ser formalmente válida.

Uma verificação zkTLS aprovada significa que os dados de origem são verdadeiros?

Não. Uma aprovação geralmente significa que a alegação atende à proveniência e integridade conforme os pressupostos de confiança declarados, e a prova pode incluir verificações de integridade, como um código de autenticação de mensagem nos dados de resposta; a prova pode demonstrar proveniência e integridade enquanto as informações sensíveis subjacentes ainda podem refletir um campo incorreto ou uma entrada inadequada no lado da origem, e erros de entrada de dados na origem, páginas adulteradas ou campos de API incorretos ainda podem produzir provas formalmente válidas. Alguns projetos também derivam uma chave de criptografia durante a sessão para que o usuário possa descriptografar a resposta enquanto o verificador ainda não vê o registro subjacente. Proveniência verificável e veracidade do conteúdo são camadas distintas.

Os oráculos tradicionais podem consumir diretamente os campos de uma página pós-login de um usuário?

Geralmente não como uma sessão HTTPS pessoal. Os nós tradicionais normalmente buscam fontes públicas em APIs ou outros endpoints públicos, e não a transcrição de sessão privada pós-login de um usuário ou Provas Web; alguns projetos mais recentes de oráculos privados para privados enviam dados TLS autenticados a servidores de computação cega em vez de publicá-los como um feed padrão. Esse modelo se concentra em fornecer proveniência de dados para entradas privadas, pode manter dados criptografados privados para conformidade regulatória e pode combinar dados de vários clientes para computações conjuntas; plataformas como os Oráculos Privados para Privados da Nillion usam computação cega para privacidade, enquanto o Reclaim Protocol é um exemplo no estilo Proxy distinto dessa abordagem. Isso também pode aumentar a segurança ao mover dados de sessão sensíveis para computação privada em vez de expor o conteúdo bruto da página; quando páginas privadas pós-login não têm uma API aberta assinada, Provas Web no estilo zkTLS ou parcerias dedicadas de dados são mais adequadas do que uma tarefa de feed padrão.