Extension de la pile technologique : Présentation des principes du zkTLS et de ses cas d'utilisation potentiels
TechFlow SélectionTechFlow Sélection
Extension de la pile technologique : Présentation des principes du zkTLS et de ses cas d'utilisation potentiels
Le plus grand avantage de zkTLS est qu'il réduit le coût de mise à disposition des ressources HTTPS Web2.
Dédié à des analyses Web3 approfondiesAuteur :@Web3_Mario
Résumé : Ces derniers temps, je cherchais de nouvelles directions de projet. En concevant un produit, j'ai rencontré une pile technologique que je n'avais jamais abordée auparavant, j'ai donc fait quelques recherches et partage ici mes réflexions avec vous.
En résumé, zkTLS est une nouvelle technologie combinant la preuve à connaissance nulle (ZKP) et le protocole TLS (Transport Layer Security). Dans l'écosystème Web3, elle sert principalement à permettre aux machines virtuelles sur chaîne de vérifier, sans faire confiance à un tiers, l'authenticité des données HTTPS hors chaîne fournies, et ce dans trois aspects : la source des données provient effectivement d'une ressource HTTPS spécifique, les données retournées n'ont pas été altérées, et leur validité temporelle peut être garantie.
Grâce à ce mécanisme cryptographique, les contrats intelligents sur chaîne acquièrent la capacité d'accéder de manière fiable aux ressources Web2 HTTPS hors chaîne, brisant ainsi les silos de données.
Qu'est-ce que le protocole TLS ?
Pour bien comprendre la valeur de la technologie zkTLS, il est utile de faire un bref rappel sur le protocole TLS. Le protocole TLS (Transport Layer Security) assure le chiffrement, l'authentification et l'intégrité des données dans les communications réseau, garantissant ainsi un transfert sécurisé des informations entre un client (par exemple, un navigateur) et un serveur (par exemple, un site web). Ceux qui ne sont pas spécialistes du développement web peuvent avoir remarqué que certains noms de domaine commencent par https tandis que d'autres utilisent http. Lorsqu'on accède à ces derniers, les navigateurs modernes affichent généralement un avertissement de sécurité. Pour les premiers, on rencontre souvent des messages comme « Votre connexion n'est pas privée » ou des erreurs liées au certificat HTTPS. Ces alertes sont directement liées à l'utilisation du protocole TLS.
Concrètement, le protocole HTTPS consiste à utiliser TLS au-dessus du protocole HTTP pour assurer confidentialité, intégrité des données et vérifiabilité de l'authenticité du serveur. On sait que HTTP est un protocole de transmission en clair, incapable de vérifier l'identité du serveur, ce qui pose plusieurs problèmes de sécurité :
1. Les informations échangées entre vous et le serveur peuvent être espionnées par un tiers, entraînant une fuite de données privées ;
2. Vous ne pouvez pas vérifier l'authenticité du serveur : votre requête pourrait être détournée par un nœud malveillant qui renvoie des informations falsifiées ;
3. Vous ne pouvez pas vérifier l'intégrité des données reçues : celles-ci pourraient être corrompues ou incomplètes à cause de problèmes réseau ;
C’est précisément pour résoudre ces problèmes que le protocole TLS a été conçu. Certains connaissent peut-être SSL. En réalité, TLS découle directement de la version 3.1 de SSL, simplement renommé pour des raisons commerciales, mais ils sont fondamentalement identiques. Ainsi, dans certains contextes, les deux termes peuvent être utilisés indifféremment.
Le protocole TLS apporte des solutions aux problèmes ci-dessus selon trois axes principaux :
1. Chiffrement des communications : utilisation du chiffrement symétrique (AES, ChaCha20) pour empêcher l’écoute.
2. Authentification d’identité : validation de l’identité du serveur via un certificat numérique délivré par une autorité tierce (comme un certificat X.509), empêchant les attaques de type homme du milieu (MITM).
3. Intégrité des données : utilisation de HMAC (code d’authentification par hachage) ou d’AEAD (chiffrement authentifié) pour garantir que les données n’aient pas été modifiées.
Nous allons maintenant expliquer brièvement les détails techniques du protocole HTTPS basé sur TLS lors d’un échange de données. Ce processus comporte deux phases : premièrement, la phase de poignée de main (Handshake), durant laquelle le client et le serveur négocient les paramètres de sécurité et établissent une session chiffrée ; deuxièmement, la phase de transmission des données, où les communications sont chiffrées à l’aide d’une clé de session. Cette procédure se déroule en quatre étapes :
1. Le client envoie un message ClientHello :
Le client (ex. : navigateur) envoie un message ClientHello au serveur contenant :
l Les versions TLS prises en charge (ex. : TLS 1.3)
l Les algorithmes de chiffrement supportés (suites cryptographiques, ex. : AES-GCM, ChaCha20)
l Un nombre aléatoire (Client Random), utilisé pour la génération de clés
l Des paramètres de partage de clé (ex. : clé publique ECDHE)
l SNI (Server Name Indication), facultatif, permettant de gérer plusieurs domaines HTTPS
L’objectif est d’informer le serveur des capacités cryptographiques du client et de préparer les paramètres de sécurité.
2. Le serveur répond avec ServerHello :
Le serveur répond avec un message ServerHello contenant :
l L’algorithme de chiffrement sélectionné
l Un nombre aléatoire côté serveur (Server Random)
l Le certificat du serveur (certificat X.509)
l Les paramètres de partage de clé du serveur (ex. : clé publique ECDHE)
l Un message Finished (pour confirmer la fin du handshake)
L’objectif est d’informer le client de l’identité du serveur et de confirmer les paramètres de sécurité.
3. Le client vérifie le serveur :
Le client effectue les opérations suivantes :
l Vérification du certificat du serveur : confirmation qu’il a été délivré par une AC (autorité de certification) de confiance, et que le certificat n’est ni expiré ni révoqué ;
l Calcul de la clé partagée : utilisation des clés publiques ECDHE du client et du serveur pour générer une clé de session, utilisée ensuite pour le chiffrement symétrique (ex. : AES-GCM) ;
l Envoi du message Finished : preuve que les données du handshake n’ont pas été altérées, empêchant les attaques MITM.
L’objectif est de s’assurer que le serveur est digne de confiance et de générer la clé de session.
4. Début de la communication chiffrée :
Le client et le serveur utilisent désormais la clé de session négociée pour communiquer de façon chiffrée.
l Utilisation du chiffrement symétrique (ex. : AES-GCM, ChaCha20) pour améliorer rapidité et sécurité.
l Protection de l’intégrité des données : recours à AEAD (ex. : AES-GCM) pour éviter toute modification.
Ainsi, après ces quatre étapes, les vulnérabilités du protocole HTTP sont efficacement résolues. Cependant, cette technologie largement utilisée dans Web2 pose des difficultés au développement d'applications Web3, notamment lorsque les contrats intelligents souhaitent accéder à certaines données hors chaîne. En raison de la nécessité de traçabilité des données, les machines virtuelles sur chaîne ne permettent pas d’appeler directement des données externes, afin de garantir la sécurité du mécanisme de consensus.
Cependant, après plusieurs itérations, les développeurs ont constaté que les DApp avaient besoin de données externes, ce qui a conduit à l’émergence de projets d’oracle tels que Chainlink ou Pyth. Ces oracles agissent comme des ponts relais entre les données sur chaîne et hors chaîne, brisant ainsi les silos de données. Pour garantir la fiabilité de ces données relayées, ces oracles reposent généralement sur un mécanisme de consensus PoS : le coût de la malhonnêteté pour les nœuds relais dépasse leurs gains, les incitant économiquement à ne pas transmettre d’informations erronées sur chaîne. Par exemple, si nous voulons accéder dans un contrat intelligent au prix pondéré du BTC sur des exchanges centralisés comme Binance ou Coinbase, nous devons compter sur ces oracles pour récupérer, agréger et transmettre ces données hors chaîne vers le contrat intelligent.
Quels problèmes zkTLS résout-il ?
Cependant, on s’est rendu compte que cette solution basée sur des oracles présente deux inconvénients :
1. Coût élevé : pour garantir que les données transmises sur chaîne par l’oracle sont authentiques et non altérées, un mécanisme de consensus PoS est requis. Or, la sécurité de PoS repose sur le montant mis en jeu, ce qui engendre des coûts de maintenance. De plus, PoS implique souvent une grande redondance dans les échanges de données : les données doivent être transmises, calculées et agrégées de manière répétée sur le réseau avant d’atteindre un consensus, ce qui augmente encore le coût d’utilisation des données. Par conséquent, pour attirer des clients, les projets d’oracle ne maintiennent gratuitement que les données les plus populaires, comme le prix du BTC. Pour des besoins spécifiques, un paiement est nécessaire. Cela freine l’innovation applicative, surtout pour les besoins long tail ou personnalisés.
2. Faible efficacité : le consensus PoS nécessite généralement un certain temps, ce qui entraîne un décalage des données sur chaîne. Cela nuit aux cas d’usage nécessitant un accès fréquent, car les données disponibles sur chaîne présentent un retard significatif par rapport aux données réelles hors chaîne.
Pour résoudre ces problèmes, la technologie zkTLS a vu le jour. Son idée principale est d’introduire des algorithmes ZKP (preuves à connaissance nulle) afin que les contrats intelligents sur chaîne puissent directement vérifier qu’un nœud fournit bien des données obtenues après consultation d’une ressource HTTPS, sans altération, évitant ainsi les coûts élevés induits par les mécanismes de consensus des oracles traditionnels.
Certains pourraient se demander pourquoi on ne donne pas directement aux machines virtuelles sur chaîne la capacité d’appeler des API Web2. La réponse est non, car l’environnement sur chaîne doit rester fermé afin de garantir la traçabilité de toutes les données : pendant le consensus, tous les nœuds doivent partager une logique d’évaluation uniforme concernant l’exactitude d’une donnée ou d’un résultat d’exécution, autrement dit une logique de vérification objective. Cela garantit qu’en l’absence totale de confiance, la majorité des nœuds honnêtes puissent valider directement la véracité d’un résultat grâce à leurs propres données redondantes. Toutefois, avec les données Web2, il est difficile d’établir une telle logique commune, car des délais réseau peuvent entraîner des résultats différents selon les nœuds lors de l’accès à une même ressource HTTPS, ce qui complique le consensus, particulièrement pour les données à haute fréquence. Un autre problème crucial réside dans le fait que la sécurité du protocole TLS, sur lequel repose HTTPS, dépend du nombre aléatoire généré par le client (Client Random) et des paramètres de partage de clé, utilisés pour négocier la clé de chiffrement avec le serveur. Or, l’environnement sur chaîne étant public et transparent, si un contrat intelligent devait gérer ces éléments sensibles, les données critiques seraient exposées, compromettant ainsi la confidentialité.
zkTLS adopte donc une autre approche : remplacer le coût élevé des oracles traditionnels — qui reposent sur des mécanismes de consensus pour assurer la disponibilité des données — par une protection cryptographique. À l’instar de l’optimisation de ZK-Rollup par rapport à OP-Rollup dans les L2. Plus précisément, en introduisant des preuves à connaissance nulle (ZKP), on calcule une preuve à partir des ressources HTTPS obtenues par un nœud relais hors chaîne, des informations de validation du certificat CA associé, des preuves temporelles et des preuves d’intégrité basées sur HMAC ou AEAD. En parallèle, des informations et algorithmes de vérification nécessaires sont conservés sur chaîne, permettant ainsi aux contrats intelligents de valider l’authenticité, la fraîcheur et la fiabilité de la source des données, sans exposer d’informations sensibles. Les détails algorithmiques précis ne seront pas abordés ici ; ceux intéressés peuvent approfondir par eux-mêmes.
L’avantage majeur de cette solution technique est la réduction drastique du coût nécessaire pour rendre disponibles les ressources HTTPS Web2. Cela ouvre la voie à de nouveaux besoins, notamment l’accès moins coûteux aux prix d’actifs long tail sur chaîne, l’utilisation de sites Web2 officiels comme base pour effectuer des KYC sur chaîne afin d’améliorer les architectures techniques de DID ou des jeux Web3. Bien sûr, on observe aussi que zkTLS impacte les entreprises Web3 existantes, en particulier les projets d’oracles dominants actuels. Face à cela, des géants comme Chainlink ou Pyth investissent activement dans ce domaine pour maintenir leur leadership technologique et explorer de nouveaux modèles économiques, par exemple passer d’un modèle basé sur le temps à un modèle basé sur l’utilisation, ou proposer du Compute as a Service. Comme pour la plupart des projets ZK, le défi principal reste la réduction du coût de calcul, afin d’atteindre une viabilité commerciale.
En conclusion, lors de la conception de produits, vous pouvez surveiller l’évolution de zkTLS et envisager d’intégrer cette pile technologique là où cela est pertinent. Cela pourrait vous ouvrir de nouvelles pistes d’innovation métier ou architecturale.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@web3_mario
