zkTLS s’adresse aux lecteurs qui doivent transmettre des valeurs issues d’une page web ou d’une API authentifiée à un contrat ou à une contrepartie — ce n’est pas un nouveau protocole de transport destiné à remplacer HTTPS. Par rapport aux captures d’écran ou aux déclarations personnelles, zkTLS transforme « la session a atteint le site cible » et « le champ satisfait un prédicat » en éléments de preuve vérifiables. Les flux continus de marchés publics reposent plus souvent sur des oracles blockchain ; la comparaison avec les flux est présentée ci-dessous.
Les sections suivantes couvrent la définition, les étapes allant de la session à la preuve, les différences entre MPC, Proxy et TEE, les cas d’utilisation, la comparaison avec les oracles et les risques, ainsi que des descriptions publiques des mécanismes, telles que l’explication de zkTLS par Oasis et la page consacrée au modèle zk-TLS d’EthSystems.
Points essentiels
- zkTLS transforme une session HTTPS en une affirmation vérifiable : il lie le domaine et le certificat, et peut ne divulguer que le résultat d’un prédicat.
- Son nom est souvent trompeur : toutes les conceptions n’utilisent pas de preuve à divulgation nulle de connaissance lors du handshake ; MPC, Proxy et TEE constituent les trois approches les plus courantes.
- TLS se termine par une clé de session symétrique partagée. Un client seul peut donc fabriquer une démonstration de transcription — d’où le recours à des notaires, des proxys ou des TEE.
- La provenance n’est pas synonyme de véracité : si l’origine renvoie un champ erroné, une preuve peut rester formellement valide.
- Les vérificateurs doivent contrôler la liaison au domaine et au certificat, le prédicat, ainsi que la signature d’attestation ou la racine de confiance sur le chemin de preuve.
Qu’est-ce que zkTLS et quel problème résout-il ?
zkTLS comble une lacune du protocole TLS ordinaire : la sécurité de la couche de transport (Transport Layer Security, TLS) sous-tend les connexions HTTPS des navigateurs, en chiffrant et en authentifiant le canal client-serveur. Pourtant, après la fin de la session, il est difficile de convaincre un tiers que le serveur a réellement renvoyé ce contenu sans fournir des éléments de déchiffrement susceptibles d’être utilisés abusivement ou sans s’appuyer sur des captures d’écran. Les contrats ont donc du mal à exploiter les champs accessibles après connexion.
Un handshake TLS standard dérive une clé de session symétrique : le navigateur et le serveur peuvent tous deux chiffrer et déchiffrer. Si un utilisateur présente seul un texte chiffré avec cette clé, les autres parties ne peuvent pas exclure que l’utilisateur ait chiffré un texte en clair falsifié, puis l’ait déchiffré à la demande. Un client isolé ne peut donc pas être un témoin fiable. Cette limite motive le recours à des notaires, des proxys ou des TEE.
zkTLS fournit des éléments de preuve de provenance et d’intégrité, et non une décision définitive sur la véracité métier. Prouver qu’un champ de solde provient de la session TLS d’un site ne réfute ni une mauvaise saisie des données ni une page altérée. Cette problématique est proche des récits sur les flux à divulgation nulle de connaissance dans zkOracle et zkCoprocessor, mais relève d’un domaine différent.
À haut niveau, zkTLS fait passer une session HTTPS normale à une preuve vérifiable : l’utilisateur ouvre une session avec l’origine ; un chemin MPC, Proxy ou TEE produit des éléments de preuve vérifiables ; puis une preuve à divulgation sélective est générée et contrôlée.
- Ouvrir la session — Établissez une connexion TLS avec le domaine cible ; le certificat et la liaison au domaine font partie de l’affirmation ultérieure.
- Co-attester ou déléguer — Un notaire participe au handshake et au déchiffrement (MPC), un proxy atteste la direction du texte chiffré (Proxy), ou un TEE exécute la requête, afin qu’un client seul ne puisse pas facilement falsifier le texte chiffré envoyé par le serveur ; certaines conceptions considèrent cela comme un protocole multipartite plutôt que comme un flux reposant sur un client unique.
- Récupérer le champ cible — Au sein de la session, demandez la page de compte ou l’API et recevez la réponse chiffrée.
- Construire l’affirmation — Générez une preuve, ou des signatures de chemin, sur les engagements de transcription, l’identité du serveur et un prédicat tel que solde > seuil ; les approches fondées sur des circuits transforment les contraintes de transcription en sorties de preuve.
- Soumettre pour vérification — Un contrat ou une contrepartie contrôle la preuve et les racines de confiance, puis l’accepte ou la rejette.
La divulgation sélective constitue une seconde couche courante : elle permet de prouver qu’un solde dépasse un seuil sans révéler le montant exact, ou d’extraire un champ tout en masquant le reste. Selon la note de Reclaim sur le « zk » dans zkTLS, la confidentialité par divulgation nulle de connaissance constitue souvent une amélioration ; l’exigence plus fondamentale consiste à convaincre un tiers que la réponse provient réellement de l’origine.
Figure 1. zkTLS part d’une session HTTPS client, passe par un chemin d’attestation MPC/Proxy/TEE, puis aboutit à une preuve à divulgation sélective contrôlée par un vérificateur ou un smart contract.
Une liste de contrôle pour le vérificateur doit couvrir au moins quatre éléments : la liaison du domaine et du certificat à l’origine revendiquée ; un prédicat conforme aux règles métier ; la signature du chemin de preuve ou la racine de confiance présente sur une liste d’autorisation ; et la question de savoir si des changements dans la structure de l’origine compromettraient l’analyseur. Omettre l’un de ces éléments transforme « vérifiable » en « ressemble à une preuve », alors que l’objectif est de fournir des données vérifiables aux smart contracts ou aux contreparties.
Pourquoi l’appelle-t-on zkTLS ? Quelles sont les différences entre MPC, Proxy et TEE ?
« zkTLS » est un terme générique populaire qui suggère que les preuves à divulgation nulle de connaissance doivent être exécutées lors du handshake, mais ce n’est pas toujours le cas. Cette étiquette est souvent employée au sens large pour un protocole hybride, bien que toutes les implémentations ne correspondent pas réellement à cette description. De nombreuses conceptions s’apparentent davantage à des preuves Web ou à des attestations TLS : l’accent porte sur la vérifiabilité, et non sur l’utilisation obligatoire de ZK dans le handshake.
| Approche |
Mécanisme principal |
Notes sur la confiance et les coûts |
| MPC / 2PC (notaire de type TLSNotary) |
La clé de session est détenue conjointement afin que ni l’utilisateur ni le notaire ne puisse falsifier seul la transcription |
Dépend de l’honnêteté et de la disponibilité du notaire ; latence plus élevée |
| Proxy |
Un proxy HTTPS atteste si le texte chiffré provient du navigateur ou du serveur ; l’utilisateur prouve en ZK le déchiffrement sans révéler la clé |
Surcharge moindre ; suppose que le proxy ne collabore pas pour mentir sur la direction |
| TEE |
Les requêtes s’exécutent dans des environnements d’exécution de confiance qui attestent l’intégrité de la réponse |
Surcharge faible ; dépend du fabricant de la puce, des racines d’attestation TEE et de l’isolation matérielle inviolable |
Les trois approches répondent à la même question : comment convaincre un tiers que le texte chiffré provient du serveur sans transmettre la clé symétrique, ce qui pourrait être exploité abusivement. Les proxys peuvent observer la direction du transfert de données sans voir le texte en clair. Les conceptions MPC/2PC, de type TLSNotary, utilisent des clés conjointes afin d’empêcher la falsification unilatérale ; les conceptions Proxy associent des attestations de direction à une preuve de déchiffrement côté utilisateur ; les conceptions TEE hébergent la session dans une isolation matérielle. La confidentialité par ZK peut s’y ajouter pour masquer certains champs, mais les TEE et la plupart des handshakes MPC ne constituent pas du ZK au niveau du handshake.
Le choix d’une approche dépend du modèle de menace et des coûts : acceptabilité d’un notaire, proxy ou TEE unique ; nécessité de maintenir une faible latence pour les sessions ; prise en charge limitée à certaines versions de TLS par l’origine. Les approches MPC garantissent également qu’aucun nœud unique ne détient jamais la clé complète. Considérez « zk » comme une étiquette désignant des données web vérifiables, et non comme une taxonomie cryptographique stricte.
À quoi peut servir zkTLS ?
Un cas d’utilisation classique consiste à prouver qu’un compte hors chaîne satisfait à un seuil sans publier le relevé complet : seuils de solde pour l’éligibilité au crédit, vérifications de solde bancaire dans des processus financiers sans révéler le montant exact, champs relatifs à l’emploi ou à la réputation provenant d’un portail nécessitant une connexion, et confirmation d’activité hors chaîne pour les règles de quêtes. Le schéma commun concerne des données situées derrière HTTPS, sans API publique signée prête à l’emploi.
Les cas d’utilisation liés à l’identité et aux attributs incluent la vérification d’identité et les justificatifs vérifiés, ainsi que les tranches d’âge, niveaux d’adhésion ou notes synthétiques : le vérificateur voit le résultat d’un prédicat, et non une page complète de données privées. Des produits structurés comme des protocoles, tels que l’oracle zkTLS de zkPass, présentent des données privées rendues vérifiables on-chain ; il convient de distinguer la manière dont un protocole encapsule les preuves de ce que garantit le modèle zkTLS.
Une autre catégorie concerne les flux de données préservant la confidentialité : les applications ont besoin de champs provenant de sites web dans des applications on-chain sans exposer le texte en clair issu de l’extraction à tous les observateurs. Dans ce cas, zkTLS fournit une preuve de champ avec provenance ; il doit toujours être distingué des flux de prix continus et de l’agrégation multisource utilisés dans la finance décentralisée et les flux de travail web-vers-chaîne plus larges.
En quoi zkTLS diffère-t-il des oracles traditionnels ?
Les oracles traditionnels se concentrent sur l’écriture de faits hors chaîne, tels que les prix ou les résultats d’événements, sur les blockchains, souvent par l’intermédiaire d’ensembles de nœuds ou de flux multisources. Cette différence relève du problème des oracles : intégrer dans les contrats des données hors chaîne ou web fiables. zkTLS se concentre sur la preuve que des champs d’une session HTTPS proviennent d’une origine spécifique, éventuellement avec divulgation sélective. Les flux optimisent la disponibilité et la résistance à la manipulation ; zkTLS optimise la transformation d’une session web en une affirmation vérifiable.
Pour comparer l’architecture des flux, les hypothèses de confiance et les modes de défaillance, consultez zkTLS et les oracles traditionnels. Règle simple : les flux continus de marchés publics restent adaptés aux réseaux d’oracles matures ; les champs privés accessibles après connexion qui nécessitent une divulgation minimale sont mieux adaptés à zkTLS. Certains systèmes considèrent également la portabilité des données comme un objectif de conception distinct : les deux approches peuvent être combinées, mais aucune ne remplace l’autre.
Quels sont les avantages et les risques liés à l’utilisation ou à la confiance accordée à zkTLS pour des données sensibles ?
Les avantages comprennent l’exportation de champs vérifiables chaque fois que l’utilisateur peut encore établir une connexion HTTPS avec l’origine, sans attendre une API de flux dédiée ; la divulgation sélective permet aux contrats de vérifier un fait sans exposer l’intégralité de l’enregistrement privé ; et les affirmations peuvent être contrôlées de manière programmatique par les contrats.
Les risques sont tout aussi concrets. L’honnêteté et la disponibilité des notaires, proxys ou TEE constituent des racines de confiance : la collusion, le refus ou l’indisponibilité peuvent entraîner des acceptations erronées ou des échecs. Les conceptions fondées sur les TEE comportent également des risques de sécurité liés au fabricant du matériel ou à la racine d’attestation. L’honnêteté de l’origine ne relève pas du périmètre du protocole : des pages erronées peuvent toujours produire des preuves formellement valides. Les modifications du chemin d’un champ peuvent invalider les prédicats ; certaines piles de notaires ne couvrent que certaines versions de TLS.
Les parties dépendantes doivent également évaluer le coût de génération des preuves, la latence des sessions et le risque de conservation des transcriptions de session. zkTLS améliore la provenance vérifiable ; il ne transforme pas des pages web arbitraires en sources de vérité non auditées.
Résumé
zkTLS transforme des sessions HTTPS quotidiennes en affirmations vérifiables et divulguées de manière minimale, afin que les contrats puissent vérifier de quel serveur lié à un domaine provient un champ, au lieu de se fier à des captures d’écran. « zk » ne garantit pas l’utilisation de la divulgation nulle de connaissance lors du handshake ; MPC, Proxy et TEE assurent l’intégrité selon différentes hypothèses de confiance.
Avant le déploiement, tenez compte du fait qu’un client isolé détenant la clé symétrique peut mettre en scène une fausse démonstration de session ; les listes de contrôle des vérificateurs doivent couvrir le domaine et le certificat, le prédicat ainsi que les racines de confiance ; la provenance n’est pas la véracité du contenu ; et la distinction entre oracles traditionnels et zkTLS sépare les flux continus des preuves de champs issus de pages privées. Choisissez l’approche en fonction du modèle de menace et intégrez les risques liés à l’origine et à l’attestation dans ce modèle.
FAQ
Qu’est-ce que zkTLS ?
zkTLS désigne une famille de conceptions reposant sur TLS/HTTPS standard et produisant des affirmations qu’un tiers peut contrôler : des données spécifiques proviennent d’un serveur lié à un domaine et à un certificat, avec la possibilité de ne divulguer que le résultat d’un prédicat. Il relie les champs privés du Web2 à la vérification par contrat sans remplacer HTTPS.
Le client et l’origine ouvrent une session ; un notaire MPC, un Proxy ou un TEE co-atteste ou délègue l’opération afin qu’un client isolé ne puisse pas falsifier le texte chiffré du serveur ; une preuve à divulgation sélective est construite ; le vérificateur contrôle la liaison au domaine, le prédicat et les racines de confiance avant d’accepter ou de rejeter l’affirmation.
zkTLS doit-il utiliser des preuves à divulgation nulle de connaissance lors du handshake TLS ?
Non. De nombreux systèmes désignés comme zkTLS utilisent MPC, Proxy ou TEE pour garantir l’intégrité ; les preuves à divulgation nulle de connaissance interviennent souvent plus tard, pour la divulgation sélective ou les preuves de déchiffrement de type Proxy. Le handshake lui-même peut ne jamais exécuter de circuit ZK — « zk » est une étiquette courante.
En quoi zkTLS diffère-t-il des oracles traditionnels ?
Les oracles traditionnels alimentent continuellement les contrats en faits hors chaîne avec des objectifs multisources et de disponibilité ; zkTLS prouve la provenance, ainsi que des prédicats facultatifs, de champs HTTPS au niveau de la session. Les flux publics et les champs de pages privées nécessitant une connexion répondent à des problèmes différents ; consultez le sujet de comparaison — les deux approches peuvent être combinées.
Quels sont les principaux risques liés à l’utilisation de zkTLS ?
Les principaux risques comprennent des notaires, proxys ou TEE compromis ou indisponibles ; des origines qui fournissent des données erronées alors que les preuves restent formellement valides ; des changements de structure de page qui rendent les analyseurs inopérants ; et des limites liées aux versions de TLS. Omettre les contrôles de liaison au domaine et de racine de confiance augmente le risque d’acceptation erronée.
