zkTLS vs. oráculos tradicionais: que dados Web são mais adequados para a cadeia?

Esta comparação destina-se a leitores de produto e de risco que estão a escolher 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 é oráculos de blockchain. As secções abaixo comparam a origem, a privacidade, a confiança e a latência, incluindo a distinção entre capturas de ecrã/PDF e proveniência criptográfica.

Seguem-se as dimensões e uma lista de verificação “Escolher se”, incluindo o ponto em que as capturas de ecrã ou os PDF deixam de ser suficientes e começa a proveniência criptográfica. Os wrappers com estrutura de protocolo incluem o oráculo zkTLS da zkPass; as descrições de feeds de conhecimento zero surgem juntamente com zkOracle e zkCoprocessor.

Principais conclusões

• O zkTLS otimiza a prova de que um campo de uma sessão HTTPS associado a um domínio foi fornecido pelo servidor desse domínio; os oráculos tradicionais otimizam a escrita contínua de factos públicos on-chain, com resistência à manipulação.
• As páginas privadas após o início de sessão, sem API pública assinada, são adequadas ao zkTLS; os preços de mercado contínuos e a agregação de múltiplas fontes são adequados a redes de oráculos maduras.
• A divulgação seletiva é uma vantagem comum do zkTLS; os feeds tradicionais publicam normalmente valores agregados para todos os observadores on-chain.
• As capturas de ecrã e os carregamentos de PDF podem apoiar operações, mas não têm proveniência de sessão verificável; as afirmações criptográficas provam a proveniência e a integridade — não a veracidade da origem.
• Faça a escolha com uma lista “Escolher se” e inclua os riscos do notário/conjunto de nós, bem como os erros da origem, no modelo de ameaças.

A tabela resume a escolha em dimensões fáceis de consultar: a origem e o acesso determinam quem pode ver os dados; a privacidade e as raízes de confiança determinam o custo de aceitar dados falsos; a latência e o tipo de dados determinam qual das vias é mais económica de desenvolver. As capturas de ecrã têm uma linha própria porque, nas operações, as imagens são frequentemente tratadas como “prova”, embora não pertençam à mesma classe de evidência que a proveniência criptográfica.

Figura 1. Comparação lado a lado do zkTLS e dos oráculos tradicionais relativamente ao acesso à origem, à privacidade, às pressuposições de confiança e à latência.

O que é o zkTLS?

O zkTLS, enquanto família de técnicas, transforma campos de uma sessão TLS/HTTPS em afirmações que terceiros podem verificar: associa o domínio e o certificado e, opcionalmente, divulga apenas o resultado de um predicado — por exemplo, que um saldo excede determinado limiar — sem transmitir o texto integral.

O zkTLS não substitui o HTTPS nem determina automaticamente se os factos comerciais da origem estão corretos; 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 equipas utilizam MPC, um percurso através de um Proxy ou um TEE como vias comuns de integridade; “zk” é frequentemente 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 da família de protocolos mais ampla.

Na prática, o cliente abre uma sessão TLS com o servidor de origem. Como a chave de sessão é partilhada entre o cliente e o servidor, um cliente isolado pode encriptar bytes arbitrários e posteriormente “desencriptá-los”, pelo que as outras partes não podem tratar uma transcrição bruta como uma saída honesta do servidor. É por isso que os designs de zkTLS acrescentam uma testemunha: um notá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 selado. A prova resultante permite aos verificadores utilizar a afirmação sem conhecerem a página completa ou a chave de sessão.

O que é um oráculo tradicional?

Os oráculos tradicionais escrevem factos off-chain no estado on-chain para que um contrato inteligente possa aceder a dados externos provenientes de fontes off-chain ou do mundo real. Os resultados típicos são feeds de preços, taxas, resultados desportivos ou resultados de eventos públicos, e estas redes são mais fortes com dados públicos ou disponíveis publicamente do que com registos privados de utilizadores. O foco do design é normalmente a agregação de múltiplas fontes, a disponibilidade dos nós e a resistência à manipulação — e não provar qual foi o campo HTML apresentado na sessão com início de sessão de um utilizador.

Os contratos leem atualizações do feed, não transcrições do navegador. Os dados de mercado públicos e contínuos adaptam-se naturalmente a esta via; os campos de páginas privadas após o início de sessão não têm frequentemente uma API pública assinada e as redes de feeds não reproduzem, por predefinição, a sessão HTTPS de cada utilizador. É por isso que as aplicações descentralizadas utilizam frequentemente oráculos para dados externos partilhados, e não para evidências de sessões pessoais. As partes de um oráculo operam normalmente servidores que obtêm dados de endpoints públicos; não estão dentro do canal TLS do cliente de um utilizador, pelo que não podem utilizar diretamente uma página bancária privada da mesma forma que um protocolo de cliente e testemunha zkTLS.

Em que diferem as fontes de dados e as vias de acesso?

A distinção fundamental é a seguinte: o zkTLS acompanha sessões que o utilizador já pode abrir com uma origem; os oráculos tradicionais acompanham fontes públicas que os nós operadores podem consultar.

Numa via zkTLS, o cliente conclui o HTTPS com o servidor do domínio pretendido e a prova pode ser gerada a partir de qualquer site HTTPS sem exigir acesso prévio a uma API. Alguns designs utilizam um modelo de Proxy, no qual um intermediário testemunha ou encaminha a troca entre o cliente e o servidor, em vez de utilizar um processamento de sessão ao estilo MPC. Outras abordagens baseadas em MPC executam conjuntamente o handshake TLS — o passo do protocolo que configura a chave de sessão segura — para que nenhuma das partes possa forjar, isoladamente, o texto cifrado do servidor. Um notário, Proxy ou TEE deixa evidências verificáveis; depois, é criada uma prova da afirmação. Numa via de oráculo tradicional, os nós obtêm dados de plataformas, índices ou APIs públicas, agregam-nos num feed e os contratos leem esse feed. Isto torna o zkTLS útil para verificar dados Web2 provenientes de sistemas existentes quando não existe um feed público de fácil acesso. Caso contrário, a validação tradicional dos dados ou outro processo de confirmação exigiria que uma parte separada obtivesse diretamente os mesmos dados da fonte. Sem uma sessão do utilizador, o zkTLS não pode substituir um feed público; sem fontes públicas consultáveis, os nós não podem consumir com segurança campos privados após o início de sessão. As abordagens com suporte do servidor dependem igualmente de os servidores de origem permitirem a exportação, pelo que os operadores podem limitar o que é partilhado. Os produtos que utilizam Web Proofs tratam, por isso, o cliente, o servidor e as partes testemunhas como uma única via de protocolo. As descrições públicas do mecanismo, como o explicador zkTLS da Oasis e a página sobre o padrão zk-TLS da EthSystems, representam a mesma via entre a sessão e a prova.

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

Uma capacidade comum do zkTLS é a divulgação seletiva: provar que um limiar foi atingido sem publicar o montante exato ou extrair um campo enquanto oculta o restante. Também pode provar afirmações sobre esses dados sem revelar o conteúdo completo. Isto torna o zkTLS útil quando é necessário provar dados privados ou sensíveis sem expor o registo completo. Assim que um feed de um oráculo tradicional está on-chain, o valor agregado fica normalmente visível para todos os observadores — os objetivos de privacidade entram frequentemente em conflito com um feed totalmente legível.

Se um produto precisar de controlos de elegibilidade sem declarações completas, o zkTLS adequa-se ao objetivo. Isto é especialmente relevante ao provar dados pessoais ou sensíveis, como a identidade legal ou registos financeiros, através de divulgação seletiva. Se um produto precisar de que todos cheguem a um consenso sobre o mesmo preço público, os feeds tradicionais adequam-se ao objetivo. Os dois sistemas também podem ser combinados: preços públicos através de oráculos e atributos privados de utilizadores através de afirmações zkTLS, o que ajuda a colocar dados privados da Internet on-chain sem divulgação abrangente; alguns sistemas descrevem isto como um modelo que permite verificar dados privados da Internet on-chain a partir de sites HTTPS sem expor o registo completo.

A divulgação seletiva é normalmente implementada sobre a prova da transcrição TLS. O cliente continua a comunicar com o servidor de origem; as partes testemunhas ajudam a associar a resposta; depois, um circuito ou protocolo de redação produz uma prova mais pequena que as outras partes podem utilizar. Num design MPC, a chave de sessão pode ser dividida para que nenhuma parte isolada possa utilizá-la indevidamente. Num design de Proxy, o Proxy atesta o texto cifrado, enquanto o cliente mantém a chave de desencriptação e prova o conhecimento do texto original dentro de uma computação. Em ambos os casos, o objetivo é utilizar campos privados sem os enviar para todos os servidores verificadores.

Em que diferem as pressuposições de confiança, a integridade dos dados e os modos de falha?

A confiança no zkTLS assenta na associação ao domínio/certificado e na honestidade e disponibilidade da via do notário, Proxy ou TEE. Se o servidor de origem devolver um campo incorreto, uma prova formalmente válida pode ainda assim ser aceite — a proveniência não equivale à veracidade do conteúdo. Quando a divulgação de conhecimento zero é implementada corretamente, o verificador não tem acesso às informações pessoais do provador. Os revisores devem ainda perguntar quais as partes que detêm material de chave, quais as partes que executam o protocolo MPC ou de Proxy e qual o certificado do servidor que fixa o endpoint TLS.

A confiança nos oráculos tradicionais assenta na composição do conjunto de nós, nas regras para múltiplas fontes e nos incentivos económicos. As falhas assumem mais frequentemente a forma de manipulação da fonte, conluio entre nós ou feeds obsoletos/tendenciosos. Os registos privados também introduzem riscos de segurança adicionais e preocupações relativas à fuga de dados se um verificador ou operador tiver de os inspecionar diretamente. As listas de verificação são diferentes: o zkTLS dá ênfase à associação, ao predicado, à autenticidade dos dados, à integridade dos dados e às verificações da raiz de confiança; os oráculos dão ênfase à atualidade, aos limiares de desvio e às fontes de agregação. Ignorar as verificações de qualquer um dos lados transforma a ideia de “parece utilizável” numa falsa sensação de verificação. Uma falsificação no lado do cliente continua a ser um modo de falha importante quando não existe uma testemunha; uma testemunha corrompida é um modo de falha importante quando as partes do protocolo conspiram.

Como devem ser equilibrados a latência, o custo e os tipos de dados?

Existem três regras práticas: os dados de mercado públicos e contínuos preferem oráculos tradicionais; as provas únicas ou de baixa frequência sobre dados específicos de um utilizador ou dados financeiros preferem zkTLS; as capturas de ecrã e os PDF são adequados a registos operacionais, não à proveniência criptográfica.

O zkTLS implica custos por sessão e de geração da prova, normalmente com maior latência do que uma via de feed em tempo real, e é adequado a limiares de saldo, níveis de adesão e campos de emprego ou reputação. Isto inclui provar que uma conta bancária ou o saldo de uma conta bancária ultrapassa um limiar exigido sem expor as credenciais subjacentes ou o extrato completo. Uma via TLS baseada em MPC pode exigir muitas comunicações; uma via de Proxy pode utilizar menos computação interativa, mas continua a precisar de um servidor testemunha disponível; as vias TEE transferem o tratamento das chaves para hardware selado. Os oráculos tradicionais mantêm atualizações contínuas e são adequados a preços, taxas e eventos públicos — concebidos para dados de mercado de baixa latência que muitas aplicações cliente utilizam em cada bloco.

As capturas de ecrã, os PDF ou os carregamentos manuais podem mostrar “algo que se parece com uma página”, mas um terceiro não consegue verificar criptograficamente se uma sessão TLS chegou ao servidor do domínio pretendido ou se os campos não foram editados pelo cliente. As afirmações ao estilo zkTLS podem garantir a autenticidade dos dados e preservar a proveniência dos dados para este tipo de entrada privada, mas continuam a não provar que os factos comerciais da origem são verdadeiros. Mesmo nesse caso, páginas de origem incorretas, falhas do DOM e indisponibilidade do notário continuam a comprometer a correção ou a disponibilidade. Tratar as capturas de ecrã como o único critério de aceitação significa confiar no carregador e no revisor; tratar as provas como “verdade” ignora que os erros da origem podem continuar formalmente válidos. As equipas que utilizam tanto capturas de ecrã como provas criptográficas devem indicar qual a classe de evidência aceite por cada critério.

Deve escolher zkTLS ou um oráculo tradicional?

Preferir zkTLS se: os dados estiverem atrás de uma página HTTPS com início de sessão ou de uma API privada à qual um cliente possa aceder através de um servidor de origem; for necessária uma divulgação mínima ao nível do predicado; não existir um feed público de múltiplas fontes pronto a utilizar; a latência da geração da prova por pedido e uma raiz de confiança baseada num notário, Proxy ou TEE forem aceitáveis; esta for frequentemente a melhor via para a verificação de identidade ou outras provas sobre registos privados de utilizadores quando a divulgação completa não for aceitável. Escolher MPC quando a computação conjunta entre partes for mais importante do que a conveniência do navegador; escolher Proxy quando se pretender utilizar as funcionalidades de Proxy existentes no cliente; escolher TEE quando a custódia selada das chaves for o principal controlo.

Preferir um oráculo tradicional se: forem necessários preços de mercado públicos contínuos ou resultados de eventos; os contratos tiverem de chegar a um consenso com base num feed legível pela rede; já existir uma agregação madura de múltiplas fontes e monitorização de desvios; a privacidade não for a principal limitação do campo e estes feeds forem normalmente utilizados para orientar decisões de contratos inteligentes a partir de sistemas externos partilhados, e não de registos pessoais. As redes de oráculos são concebidas para que muitos contratos de clientes possam utilizar o mesmo feed público sem que cada utilizador abra uma sessão TLS privada.

Combinar ambos se: os preços públicos passarem por um oráculo e os atributos privados dos utilizadores passarem pelo zkTLS. Esta combinação é comum quando as aplicações precisam de feeds públicos e de afirmações privadas para fluxos de trabalho de ativos do mundo real ou lógica empresarial sensível. Em qualquer caso, inclua “proveniência ≠ verdade” nas regras: os erros do servidor de origem, o conluio entre nós, a corrupção do notário, um tratamento deficiente das chaves e as reformulações das páginas são riscos fundamentais, não notas de rodapé. A escolha do protocolo deve indicar quais as partes que têm de permanecer honestas para que a prova continue a ser relevante.

Resumo

O zkTLS e os oráculos tradicionais respondem a perguntas on-chain diferentes: os oráculos tradicionais servem principalmente dados externos partilhados, enquanto o zkTLS ajuda a tornar verificáveis os registos Web privados, preservando a privacidade. Historicamente, esta diferença fez com que os feeds públicos fossem mais fáceis de utilizar, deixando os dados privados relativamente subutilizados. Depois de comparar o acesso às fontes, a privacidade, as raízes de confiança e a latência, verifica-se que os campos de páginas privadas após o início de sessão e os feeds públicos raramente se substituem mutuamente.

Em suma: utilize um oráculo tradicional quando muitos contratos precisarem do mesmo feed público; utilize zkTLS quando um cliente tiver de provar uma resposta TLS privada proveniente de um servidor de origem através de uma prova com divulgação seletiva. MPC, Proxy e TEE continuam a ser os principais tipos de testemunha para essa via de protocolo e cada um altera quais as partes que detêm material de chave e a quantidade de computação interativa que o cliente tem de executar. As capturas de ecrã e os PDF não conseguem colmatar 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 “Escolher se” — e incluir no modelo de ameaças os modos de falha do notário/nó e da origem — é melhor do que discutir rótulos.

Perguntas frequentes

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

Os oráculos tradicionais fornecem principalmente dados públicos a um contrato inteligente, enquanto os produtos utilizam zkTLS quando é necessário demonstrar a autenticidade dos dados de uma sessão HTTPS mantida pelo utilizador; isto também afeta a possibilidade de o verificador ver o registo subjacente ou apenas uma prova sobre o mesmo. O zkTLS prova que os campos de uma sessão TLS foram fornecidos por um servidor associado a um domínio e a um certificado. Alguns designs utilizam MPC (computação multipartidária segura) durante o handshake TLS entre o cliente e as partes notárias, enquanto outros dependem de testemunhas baseadas num Proxy ou TEE; os oráculos tradicionais escrevem continuamente factos públicos off-chain, como preços, nos contratos através de conjuntos de nós e agregação de múltiplas fontes. Um sistema otimiza a proveniência da sessão; o outro otimiza a disponibilidade do feed e a resistência à manipulação. Nos designs baseados em Proxy ou em testemunhas, o próprio servidor de origem normalmente não precisa de ser alterado e o cliente continua a deter ou a partilhar a chave de sessão de acordo com as regras do protocolo.

Quando deve utilizar zkTLS em vez de um oráculo tradicional?

Utilize zkTLS para campos privados após o início de sessão que exijam uma divulgação mínima e não disponham de uma API pública assinada, especialmente quando um produto precisar de partilhar dados verificáveis provenientes de uma fonte privada através de um token de acesso ou de credenciais de sessão, permitindo ao cliente autenticar-se diretamente no servidor de origem em vez de entregar registos brutos a um intermediário. Algumas implementações executam localmente a computação da prova de conhecimento zero para que atributos selecionados possam ser provados sem carregar o registo completo. Utilize oráculos tradicionais para preços de mercado públicos contínuos ou resultados de eventos que exijam uma liquidação legível pela rede; isto pode manter os registos privados fora de um feed de oráculo público, permitindo simultaneamente que os contratos utilizem preços partilhados. Os feeds públicos e os atributos privados podem ser combinados num produto quando diferentes partes precisarem de diferentes classes de evidência.

As capturas de ecrã ou os carregamentos de PDF podem substituir uma prova zkTLS?

Não de forma fiável. As capturas de ecrã e os PDF de uma página Web podem parecer convincentes do ponto de vista operacional, mas não têm proveniência de sessão TLS verificável nem transportam uma prova criptográfica da origem ou integridade da sessão. Por isso, um terceiro não consegue excluir facilmente a possibilidade de imagens editadas ou de páginas erradas. Em contrapartida, uma testemunha Proxy HTTP pode observar ou encaminhar a troca para preservar uma proveniência verificável de uma forma que uma captura de ecrã ou um PDF não consegue. As afirmações ao estilo zkTLS fornecem caminhos de verificação da associação ao domínio e da integridade — mas, se a origem devolver dados incorretos, uma prova pode ainda assim ser formalmente válida.

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

Não. Uma aprovação normalmente significa que a afirmação é válida relativamente à proveniência e à integridade, de acordo com as pressuposições de confiança indicadas, e a prova pode incluir verificações de integridade, como um código de autenticação de mensagem nos dados da resposta; a prova pode demonstrar a proveniência e a integridade, enquanto as informações sensíveis subjacentes podem ainda refletir um campo incorreto ou uma entrada errada no lado da origem. Erros de introdução de dados na origem, páginas adulteradas ou campos de API incorretos podem continuar a produzir provas formalmente válidas. Alguns designs também derivam uma chave de encriptação durante a sessão, para que o utilizador possa desencriptar a resposta enquanto o verificador continua sem conseguir ver o registo subjacente. A proveniência verificável e a veracidade do conteúdo são camadas distintas.

Os oráculos tradicionais podem consumir diretamente os campos de uma página Web após o início de sessão de um utilizador?

Normalmente, não como parte de uma sessão HTTPS pessoal. Os nós tradicionais obtêm normalmente dados de fontes públicas através de APIs ou de outros endpoints públicos, e não da transcrição da sessão privada após o início de sessão de um utilizador ou de Web Proofs; alguns designs de oráculos privados para privados mais recentes enviam dados TLS autenticados para servidores de computação cega, em vez de os publicarem como um feed padrão. Este modelo centra-se no fornecimento de proveniência de dados para entradas privadas, pode manter os dados encriptados privados para efeitos de conformidade regulamentar e pode combinar dados de vários clientes para computações conjuntas; plataformas como os Private-to-Private Oracles da Nillion utilizam computação cega, enquanto o Reclaim Protocol é um exemplo ao estilo Proxy, distinto dessa abordagem. Isto também pode reforçar a segurança ao transferir dados de sessões sensíveis para uma computação privada, em vez de expor o conteúdo bruto das páginas; quando as páginas privadas após o início de sessão não têm uma API aberta assinada, as Web Proofs ao estilo zkTLS ou parcerias de dados dedicadas são mais adequadas do que um trabalho de feed predefinido.