zkTLS et oracles traditionnels : quelles données web s’intègrent le mieux on-chain ?

Cette comparaison s’adresse aux lecteurs qui évaluent les produits et les risques et qui doivent choisir entre des champs de pages privées et des flux publics. Le mécanisme lui-même est expliqué dans zkTLS ; le terme générique désignant les passerelles de données off-chain est celui d’oracles blockchain. Les sections ci-dessous comparent la source, la confidentialité, la confiance et la latence, tout en intégrant la distinction entre captures d’écran/PDF et provenance cryptographique.

Les dimensions et une liste de critères « Choisir si » suivent, notamment pour préciser où s’arrêtent les captures d’écran ou les PDF et où commence la provenance cryptographique. Les implémentations structurées autour d’un protocole incluent l’oracle zkTLS de zkPass ; les approches fondées sur des flux zero-knowledge sont présentées aux côtés de zkOracle et zkCoprocessor.

Points clés à retenir

• zkTLS vise à prouver de quel serveur associé à un domaine provient un champ d’une session HTTPS ; les oracles traditionnels visent à inscrire en continu des faits publics on-chain tout en résistant aux manipulations.
• Les pages privées accessibles après connexion, sans API publique signée, sont adaptées à zkTLS ; les cours de marché continus et l’agrégation de plusieurs sources sont adaptés aux réseaux d’oracles matures.
• La divulgation sélective constitue un avantage courant de zkTLS ; les flux traditionnels publient généralement des valeurs agrégées à l’ensemble des observateurs on-chain.
• Les captures d’écran et les téléversements de PDF peuvent servir aux opérations, mais ils ne fournissent pas de provenance de session vérifiable ; les assertions cryptographiques prouvent la provenance et l’intégrité, mais pas la véracité des informations à l’origine.
• Faites votre choix à l’aide d’une liste « Choisir si » et intégrez les risques liés au notaire/à l’ensemble de nœuds ainsi que les erreurs de la source au modèle de menace.

Le tableau résume le choix selon des dimensions faciles à parcourir : la source et l’accès déterminent qui peut voir les données ; la confidentialité et les racines de confiance déterminent le coût des acceptations erronées ; la latence et le type de données déterminent la voie la moins coûteuse à mettre en œuvre. Les captures d’écran disposent de leur propre ligne, car les équipes opérationnelles les considèrent souvent comme des « preuves », alors qu’elles ne relèvent pas de la même catégorie d’éléments probants que la provenance cryptographique.

Figure 1. Comparaison côte à côte de zkTLS et des oracles traditionnels selon la source, l’accès, la confidentialité, les hypothèses de confiance et la latence.

Qu’est-ce que zkTLS ?

zkTLS, en tant que famille de techniques, transforme des champs d’une session TLS/HTTPS en assertions qu’un tiers peut vérifier : le domaine et le certificat sont associés, et seul le résultat d’un prédicat peut éventuellement être divulgué — par exemple, prouver qu’un solde dépasse un seuil sans communiquer l’intégralité du texte en clair.

zkTLS ne remplace pas HTTPS et ne détermine pas automatiquement si les informations métier de l’origine sont exactes ; il fournit des éléments probants de provenance et d’intégrité, TLS étant le protocole de la couche de transport qui permet l’échange sécurisé de données entre un client et un serveur. Les équipes utilisent généralement MPC, une voie passant par un Proxy ou un TEE comme mécanismes d’intégrité ; « zk » est souvent un terme générique, et l’établissement de la liaison TLS peut ne jamais exécuter de circuit zero-knowledge, même si une preuve zero-knowledge constitue une couche facultative au sein de la famille de protocoles plus large.

En pratique, le client ouvre une session TLS avec le serveur d’origine. Comme la clé de session est partagée entre le client et le serveur, un client isolé peut chiffrer des octets arbitraires et les « déchiffrer » ultérieurement ; les autres parties ne peuvent donc pas considérer une transcription brute comme une sortie honnête du serveur. C’est pourquoi les architectures zkTLS ajoutent un témoin : un notaire MPC qui exécute conjointement le protocole avec le client, un Proxy qui atteste de la direction du texte chiffré, ou un TEE qui conserve la clé dans un environnement de calcul scellé. La preuve obtenue permet aux vérificateurs d’utiliser l’assertion sans connaître l’intégralité de la page ni la clé de session.

Qu’est-ce qu’un oracle traditionnel ?

Les oracles traditionnels inscrivent des faits off-chain dans l’état on-chain afin qu’un smart contract puisse accéder à des données externes provenant de sources off-chain ou du monde réel. Les résultats courants sont les flux de cours, les taux, les résultats sportifs ou les résultats d’événements publics. Ces réseaux sont particulièrement adaptés aux données publiques ou accessibles au public, plutôt qu’aux données privées des utilisateurs. Leur conception met généralement l’accent sur l’agrégation de plusieurs sources, la disponibilité des nœuds et la résistance aux manipulations, et non sur la preuve du champ HTML apparu dans la session d’un utilisateur connecté.

Les contrats lisent les mises à jour d’un flux, et non les transcriptions d’un navigateur. Les données continues des marchés publics s’intègrent naturellement à cette voie ; les champs de pages privées accessibles après connexion ne disposent souvent pas d’API publique signée, et les réseaux d’oracles ne rejouent pas par défaut la session HTTPS de chaque utilisateur. C’est pourquoi les applications décentralisées utilisent souvent les oracles pour des données externes partagées, et non pour des éléments probants issus d’une session personnelle. Les acteurs des oracles exploitent généralement des serveurs qui récupèrent des points de terminaison publics ; ils ne se trouvent pas dans le canal TLS du client d’un utilisateur et ne peuvent donc pas utiliser directement une page bancaire privée comme pourrait le faire un protocole zkTLS associant un client et un témoin.

En quoi les sources de données et les voies d’accès diffèrent-elles ?

La distinction fondamentale est la suivante : zkTLS suit les sessions que l’utilisateur peut déjà ouvrir auprès d’une origine ; les oracles traditionnels suivent les sources publiques que les nœuds opérateurs peuvent récupérer.

Dans une voie zkTLS, le client établit une connexion HTTPS avec le serveur du domaine cible, et la preuve peut être générée à partir de n’importe quel site HTTPS sans nécessiter d’accès préalable à une API. Certaines architectures utilisent un modèle Proxy, dans lequel un intermédiaire témoigne de l’échange client–serveur ou le relaie, au lieu de recourir au traitement de session de type MPC. D’autres approches fondées sur MPC exécutent conjointement l’établissement de la liaison TLS — l’étape du protocole qui configure la clé de session sécurisée — afin qu’aucune partie ne puisse à elle seule forger le texte chiffré du serveur. Un notaire, un Proxy ou un TEE laisse des éléments vérifiables ; une preuve d’assertion est ensuite construite. Dans une voie reposant sur un oracle traditionnel, les nœuds récupèrent les données des plateformes, des index ou des API publiques, les agrègent dans un flux, puis les contrats lisent ce flux. Cela rend zkTLS utile pour vérifier des données Web2 issues de systèmes existants lorsqu’il n’existe pas de flux public facilement accessible. Dans le cas contraire, la validation traditionnelle des données ou un autre processus de confirmation nécessiterait qu’une partie distincte récupère directement la même source. Sans session utilisateur, zkTLS ne peut pas remplacer un flux public ; sans sources publiques accessibles, les nœuds ne peuvent pas utiliser de manière sûre des champs privés accessibles après connexion. Les approches prises en charge par le serveur dépendent également de la possibilité, pour les serveurs d’origine, d’autoriser l’exportation des données ; les opérateurs peuvent donc limiter les éléments partagés. Les produits qui utilisent les Web Proofs considèrent ainsi le client, le serveur et les parties témoins comme une seule voie de protocole. Des présentations publiques du mécanisme, telles que l’explication de zkTLS par Oasis et la page consacrée au modèle zk-TLS d’EthSystems, décrivent la même voie allant de la session à la preuve.

En quoi la confidentialité, les données privées et la divulgation sélective diffèrent-elles ?

La divulgation sélective constitue une capacité courante de zkTLS : prouver qu’un seuil est atteint sans publier le montant exact, ou extraire un champ tout en masquant le reste. Il est également possible de prouver des assertions relatives à ces données sans en révéler l’intégralité. zkTLS est donc utile lorsqu’il faut prouver des données privées ou sensibles sans exposer l’ensemble du dossier. Une fois qu’un flux d’oracle traditionnel est inscrit on-chain, sa valeur agrégée est généralement visible par tous les observateurs ; les objectifs de confidentialité sont souvent incompatibles avec un flux entièrement lisible.

Si un produit a besoin de contrôles d’éligibilité sans divulguer les informations complètes, zkTLS correspond à cette finalité. Cela est particulièrement pertinent pour prouver des données personnelles ou sensibles, comme une identité légale ou des informations financières, avec une divulgation sélective. Si un produit doit permettre à tous les participants de s’accorder sur le même cours public, les flux traditionnels sont plus adaptés. Les deux approches peuvent également être combinées : cours publics via des oracles et attributs privés des utilisateurs via des assertions zkTLS. Cela contribue à inscrire des données privées issues d’Internet on-chain sans divulgation étendue ; certains systèmes décrivent ce modèle comme permettant de vérifier on-chain des données Internet privées provenant de sites HTTPS sans exposer l’intégralité du dossier.

La divulgation sélective s’appuie généralement sur la preuve de la transcription TLS. Le client communique toujours avec le serveur d’origine ; les parties témoins contribuent à associer la réponse à cette origine ; un circuit ou un protocole de rédaction produit ensuite une preuve plus compacte que d’autres parties peuvent utiliser. Dans une architecture MPC, la clé de session peut être répartie afin qu’aucune partie ne puisse en faire un usage abusif. Dans une architecture Proxy, le Proxy atteste du texte chiffré, tandis que le client conserve la clé de déchiffrement et prouve la connaissance du texte en clair au sein d’un calcul. Dans les deux cas, l’objectif est d’utiliser des champs privés sans les transmettre à chaque serveur vérificateur.

En quoi les hypothèses de confiance, l’intégrité des données et les modes de défaillance diffèrent-ils ?

La confiance dans zkTLS repose sur l’association au domaine et au certificat, ainsi que sur l’honnêteté et la disponibilité de la voie passant par le notaire, le Proxy ou le TEE. Si le serveur d’origine renvoie un champ incorrect, une preuve formellement valide peut malgré tout être acceptée : la provenance ne garantit pas la véracité du contenu. Lorsque la divulgation zero-knowledge est correctement mise en œuvre, le vérificateur ne connaît pas les informations personnelles du prouveur. Les évaluateurs doivent néanmoins demander quelles parties détiennent les éléments de la clé, quelles parties exécutent le protocole MPC ou Proxy et quel certificat de serveur authentifie le point de terminaison TLS.

La confiance dans un oracle traditionnel repose sur la composition de l’ensemble de nœuds, les règles appliquées aux différentes sources et les incitations économiques. Les défaillances prennent plus souvent la forme d’une manipulation de la source, d’une collusion entre nœuds ou de flux obsolètes ou biaisés. Les données privées introduisent également des risques de sécurité et de fuite de données supplémentaires si un vérificateur ou un opérateur doit les examiner directement. Les listes de contrôle diffèrent : zkTLS met l’accent sur les vérifications d’association, de prédicat, d’authenticité et d’intégrité des données, ainsi que sur les racines de confiance ; les oracles se concentrent sur l’actualité des données, les seuils d’écart et les sources utilisées pour l’agrégation. Négliger l’un ou l’autre de ces aspects donne une fausse impression de vérification sous prétexte que le système « semble utilisable ». Une falsification côté client reste un mode de défaillance important en l’absence de témoin ; un témoin corrompu constitue un mode de défaillance important lorsque les parties au protocole colludent.

Comment arbitrer entre latence, coût et types de données ?

Trois règles pratiques s’appliquent : les données continues des marchés publics sont généralement mieux adaptées aux oracles traditionnels ; les preuves ponctuelles ou peu fréquentes portant sur des données propres à un utilisateur ou sur des données financières sont généralement mieux adaptées à zkTLS ; les captures d’écran et les PDF conviennent aux dossiers opérationnels, mais pas à la provenance cryptographique.

zkTLS entraîne un coût par session et un coût de génération de preuve, généralement avec une latence plus élevée que celle d’un flux actif. Il convient aux seuils de solde, aux niveaux d’adhésion et aux données relatives à l’emploi ou à la réputation. Cela inclut la preuve qu’un compte bancaire ou que le solde d’un compte bancaire dépasse un seuil requis sans exposer les identifiants sous-jacents ni l’intégralité du relevé. Une voie TLS fondée sur MPC peut nécessiter de nombreuses communications ; une voie Proxy peut réduire les calculs interactifs, mais elle nécessite toujours un serveur témoin disponible ; les voies TEE déplacent la gestion des clés vers du matériel scellé. Les oracles traditionnels assurent des mises à jour continues et conviennent aux cours, aux taux et aux événements publics. Ils sont conçus pour fournir des données de marché à faible latence que de nombreuses applications clientes utilisent à chaque bloc.

Les captures d’écran, les PDF ou les téléversements manuels peuvent montrer « quelque chose qui ressemble à une page », mais un tiers ne peut pas vérifier cryptographiquement qu’une session TLS a bien atteint le serveur du domaine cible ni que les champs n’ont pas été modifiés par le client. Les assertions de type zkTLS peuvent garantir l’authenticité des données et préserver leur provenance pour ce type d’entrée privée, mais elles ne prouvent toujours pas que les informations métier de l’origine sont exactes. Même dans ce cas, des pages d’origine incorrectes, des ruptures du DOM et l’indisponibilité d’un notaire peuvent encore compromettre la correction ou la disponibilité. Considérer les captures d’écran comme le seul contrôle revient à faire confiance à l’utilisateur qui les téléverse et à l’évaluateur ; considérer les preuves comme la « vérité » revient à ignorer que des erreurs de l’origine peuvent rester formellement valides. Les équipes qui utilisent à la fois des captures d’écran et des preuves cryptographiques doivent préciser quelle catégorie d’éléments probants chaque contrôle accepte.

Devriez-vous choisir zkTLS ou un oracle traditionnel ?

Privilégiez zkTLS si : les données se trouvent derrière une page HTTPS accessible après connexion ou une API privée à laquelle un client peut accéder auprès d’un serveur d’origine ; une divulgation minimale au niveau du prédicat est requise ; aucun flux public agrégé à partir de plusieurs sources n’est immédiatement disponible ; la latence de génération de preuve par requête ainsi qu’une racine de confiance reposant sur un notaire, un Proxy ou un TEE sont acceptables. Il s’agit souvent de la meilleure voie pour la vérification d’identité ou d’autres preuves portant sur des données privées d’utilisateurs lorsque la divulgation intégrale est inacceptable. Choisissez MPC lorsque le calcul conjoint entre les parties est plus important que la simplicité d’utilisation dans le navigateur ; choisissez Proxy lorsque vous souhaitez exploiter les fonctionnalités Proxy existantes du client ; choisissez TEE lorsque la conservation des clés dans un environnement scellé constitue le principal contrôle.

Privilégiez un oracle traditionnel si : des cours de marché publics ou des résultats d’événements doivent être mis à jour en continu ; les contrats doivent effectuer leur règlement à partir d’un flux lisible sur le réseau ; une agrégation mature de plusieurs sources et un suivi des écarts existent déjà ; la confidentialité n’est pas la principale contrainte des champs concernés. Ces flux servent généralement à orienter les décisions des smart contracts à partir de systèmes externes partagés, plutôt que de dossiers personnels. Les réseaux d’oracles sont conçus pour permettre à de nombreux contrats clients d’utiliser le même flux public sans que chaque utilisateur ouvre une session TLS privée.

Combinez les deux si : les cours publics passent par un oracle et les attributs privés des utilisateurs passent par zkTLS. Cette combinaison est courante lorsque les applications ont besoin de flux publics ainsi que d’assertions privées pour des opérations liées aux actifs du monde réel ou pour une logique métier sensible. Dans tous les cas, inscrivez « provenance ≠ vérité » dans les règles : les erreurs du serveur d’origine, la collusion entre nœuds, la corruption du notaire, une gestion insuffisante des clés et les modifications de page sont des risques à part entière, et non des détails secondaires. Le choix du protocole doit préciser quelles parties doivent rester honnêtes pour que la preuve conserve sa valeur.

Résumé

zkTLS et les oracles traditionnels répondent à des questions on-chain différentes : les oracles traditionnels servent principalement les données externes partagées, tandis que zkTLS aide à rendre vérifiables des dossiers Web privés tout en préservant la confidentialité. Historiquement, cet écart a rendu les flux publics plus faciles à utiliser, laissant les données privées comparativement sous-exploitées. Après comparaison de l’accès aux sources, de la confidentialité, des racines de confiance et de la latence, on constate que les champs de pages privées accessibles après connexion et les flux publics se remplacent rarement l’un l’autre.

En bref : utilisez un oracle traditionnel lorsque plusieurs contrats ont besoin du même flux public ; utilisez zkTLS lorsqu’un client doit prouver une réponse TLS privée provenant d’un serveur d’origine au moyen d’une preuve à divulgation sélective. MPC, Proxy et TEE restent les principaux types de témoins de cette voie de protocole, et chacun modifie les parties qui détiennent les éléments de la clé ainsi que la quantité de calcul interactif que le client doit exécuter. Les captures d’écran et les PDF ne peuvent pas combler une lacune de provenance cryptographique ; une preuve TLS ne peut pas garantir automatiquement que le contenu de l’origine est exact. Un choix fondé sur une liste « Choisir si », associé à l’intégration des modes de défaillance du notaire/des nœuds et de l’origine au modèle de menace, est préférable à un débat sur les appellations.

FAQ

Quelle est la différence entre zkTLS et les oracles traditionnels ?

Les oracles traditionnels fournissent principalement des données publiques à un smart contract, tandis que les produits utilisent zkTLS lorsque l’authenticité des données doit être démontrée pour une session HTTPS détenue par un utilisateur. Cela détermine également si le vérificateur voit le dossier sous-jacent ou uniquement une preuve le concernant. zkTLS prouve que des champs d’une session TLS proviennent d’un serveur associé à un domaine et à un certificat. Certaines architectures utilisent la MPC — le calcul multipartite sécurisé — pendant l’établissement de la liaison TLS entre le client et les parties agissant comme notaires, tandis que d’autres reposent sur des témoins utilisant un Proxy ou un TEE. Les oracles traditionnels inscrivent en continu des faits publics off-chain, tels que des cours, dans les contrats au moyen d’ensembles de nœuds et d’une agrégation de plusieurs sources. L’un optimise la provenance des sessions ; l’autre optimise la disponibilité des flux et la résistance aux manipulations. Dans les architectures fondées sur un Proxy ou un témoin, le serveur d’origine n’a généralement pas besoin d’être modifié, et le client conserve ou partage la clé de session conformément aux règles du protocole.

Quand utiliser zkTLS plutôt qu’un oracle traditionnel ?

Utilisez zkTLS pour les champs privés accessibles après connexion qui nécessitent une divulgation minimale et qui ne disposent pas d’API publique signée, notamment lorsqu’un produit doit permettre un partage vérifiable de données provenant d’une source privée au moyen d’un jeton d’accès ou d’identifiants de session. Le client peut ainsi s’authentifier directement auprès du serveur d’origine au lieu de transmettre des dossiers bruts à un intermédiaire. Certaines implémentations exécutent localement le calcul de la preuve zero-knowledge afin de prouver certains attributs sans téléverser l’intégralité du dossier. Utilisez les oracles traditionnels pour les cours de marché publics ou les résultats d’événements continus qui nécessitent un règlement lisible sur le réseau ; cela permet de conserver les dossiers privés hors d’un flux d’oracle public tout en laissant les contrats utiliser des cours partagés. Les flux publics et les attributs privés peuvent être combinés dans un même produit lorsque différentes parties ont besoin de catégories d’éléments probants différentes.

Les captures d’écran ou les téléversements de PDF peuvent-ils remplacer une preuve zkTLS ?

Pas de manière fiable. Les captures d’écran et les PDF d’une page Web peuvent sembler convaincants sur le plan opérationnel, mais ils ne fournissent pas de provenance de session TLS vérifiable et ne contiennent pas de preuve cryptographique de l’origine ou de l’intégrité de la session. Un tiers ne peut donc pas facilement exclure la possibilité que les images aient été modifiées ou qu’elles proviennent de pages incorrectes. À l’inverse, un témoin Proxy HTTP peut observer ou acheminer l’échange afin de préserver une provenance vérifiable, ce qu’une capture d’écran ou un PDF ne permet pas. Les assertions de type zkTLS fournissent des voies de vérification de l’association au domaine et de l’intégrité, mais si l’origine renvoie de mauvaises données, une preuve peut tout de même être formellement valide.

Une vérification zkTLS réussie signifie-t-elle que les données de l’origine sont exactes ?

Non. Une validation réussie signifie généralement que l’assertion satisfait les exigences de provenance et d’intégrité dans le cadre des hypothèses de confiance établies. La preuve peut inclure des contrôles d’intégrité tels qu’un code d’authentification de message appliqué aux données de réponse. Elle peut démontrer la provenance et l’intégrité alors que les informations sensibles sous-jacentes reflètent toujours un champ incorrect ou une donnée erronée saisie côté origine. Les erreurs de saisie des données d’origine, les pages falsifiées ou les mauvais champs d’API peuvent donc toujours produire des preuves formellement valides. Certaines architectures dérivent également une clé de chiffrement pendant la session afin que l’utilisateur puisse déchiffrer la réponse, tandis que le vérificateur ne peut toujours pas voir le dossier sous-jacent. La provenance vérifiable et la véracité du contenu sont deux niveaux distincts.

Les oracles traditionnels peuvent-ils utiliser directement les champs d’une page Web accessible après connexion par un utilisateur ?

Généralement pas dans le cadre d’une session HTTPS personnelle. Les nœuds traditionnels récupèrent habituellement des sources publiques à partir d’API ou d’autres points de terminaison publics, et non la transcription de la session privée accessible après connexion d’un utilisateur ou ses Web Proofs. Certaines architectures plus récentes d’oracles privés à privés envoient plutôt les données TLS authentifiées vers des serveurs de calcul aveugle au lieu de les publier dans un flux standard. Ce modèle vise à fournir la provenance des données privées, à maintenir le chiffrement des données privées pour répondre aux exigences réglementaires et à combiner les données de plusieurs clients dans le cadre de calculs conjoints. Des plateformes telles que les Private-to-Private Oracles de Nillion utilisent le calcul aveugle pour préserver la confidentialité, tandis que Reclaim Protocol constitue un exemple de modèle Proxy distinct de cette approche. Cela peut également renforcer la sécurité en déplaçant les données de session sensibles vers un calcul privé au lieu d’exposer le contenu brut des pages. Lorsque les pages privées accessibles après connexion ne disposent pas d’API publique ouverte et signée, les Web Proofs de type zkTLS ou les partenariats de données dédiés sont plus adaptés qu’une tâche de flux standard.