Expansion de la pile technologique : aperçu des principes et des applications potentielles de zkTLS

Auteur : @Web3_Mario
Résumé : J'ai récemment cherché de nouvelles orientations de projet et j'ai rencontré une pile technologique à laquelle je n'avais jamais été confronté auparavant lors de la conception de produits. J'ai donc fait quelques recherches et compilé mes apprentissages pour les partager avec vous. En résumé, zkTLS est une nouvelle technologie qui combine les preuves à connaissance zéro (ZKP) et TLS (Transport Layer Security Protocol). Dans le secteur Web3, elle est principalement utilisée dans les environnements de machines virtuelles en chaîne pour vérifier l'authenticité des données HTTPS hors chaîne qu'elle fournit sans avoir à faire confiance à un tiers. L'authenticité ici comprend trois aspects : la source des données provient bien d'une ressource HTTPS, les données renvoyées n'ont pas été falsifiées et la validité des données peut être garantie. Grâce à ce mécanisme de mise en œuvre cryptographique, les contrats intelligents en chaîne acquièrent la capacité d'accéder de manière fiable aux ressources HTTPS Web2 hors chaîne, brisant ainsi les silos de données.
Qu'est-ce que le protocole TLS ?
Afin de bien comprendre la valeur de la technologie zkTLS, il est nécessaire de faire un bref aperçu du protocole TLS. Tout d'abord, TLS (Transport Layer Security Protocol) est utilisé pour fournir le chiffrement, l'authentification et l'intégrité des données dans les communications réseau, garantissant ainsi la transmission sécurisée des données entre un client (tel qu'un navigateur) et un serveur (tel qu'un site Web). Les amis qui ne sont pas dans le domaine du développement réseau peuvent constater que lors de l'accès à un site Web, certains noms de domaine sont précédés de https et d'autres de http. Lors de l'accès à ce dernier, les principaux navigateurs indiquent qu'il n'est pas sécurisé. Le premier est susceptible de rencontrer l'invite « Votre lien n'est pas un lien privé » ou une erreur de certificat HTTPS. La raison de cette invite réside dans la disponibilité du protocole TLS.
Plus précisément, le protocole HTTPS utilise le protocole TLS sur la base du protocole HTTP pour garantir la confidentialité et l'intégrité de la transmission des informations, et rend également l'authenticité du serveur vérifiable. Nous savons que le protocole HTTP est un protocole réseau de transmission en texte clair, et ce protocole ne peut pas vérifier l'authenticité du serveur, ce qui pose plusieurs problèmes de sécurité :
1. Les informations que vous et le serveur transmettez peuvent être écoutées par des tiers, entraînant ainsi une fuite de confidentialité ;
2. Vous ne pouvez pas vérifier l'authenticité du serveur, c'est-à-dire si votre demande est détournée par d'autres nœuds malveillants et renvoie des informations malveillantes ;
3. Vous ne pouvez pas vérifier l'intégrité des informations renvoyées, c'est-à-dire s'il est possible que des données soient perdues en raison de problèmes de réseau ;
Et le protocole TLS est conçu pour résoudre ces problèmes. Voici une explication : certains amis peuvent connaître le protocole SSL, mais en fait, le protocole TLS est développé sur la base de la version SSL 3.1, mais en raison de certains problèmes commerciaux connexes, il a été renommé, mais en fait, il est cohérent. Par conséquent, dans certains contextes, les deux mots peuvent être interchangés.
L'idée principale du protocole TLS pour résoudre les problèmes ci-dessus est :
1. Communication chiffrée : utilisation du chiffrement symétrique (AES, ChaCha20) pour protéger les données et empêcher l'écoute clandestine.
2. Authentification d'identité : vérification de l'identité du serveur par le biais d'un certificat numérique (tel qu'un certificat X.509) délivré par un tiers à une organisation désignée, afin d'éviter les attaques de l'homme du milieu (MITM).
3. Intégrité des données : utilisation de HMAC (Hash Message Authentication Code) ou AEAD (Authenticated Encryption) pour garantir que les données n'ont pas été falsifiées.
Nous allons expliquer brièvement les détails techniques du protocole HTTPS basé sur le protocole TLS dans le processus d'interaction des données. L'ensemble du processus est divisé en deux étapes. La première est l'étape de la poignée de main (Handshake), c'est-à-dire que le client et le serveur négocient les paramètres de sécurité et établissent une session chiffrée. La seconde est l'étape de la transmission des données, c'est-à-dire l'utilisation d'une clé de session pour la communication chiffrée. Le processus spécifique est divisé en quatre étapes :
1. Le client envoie ClientHello :
Le client (par exemple, le navigateur) envoie un message ClientHello au serveur, qui comprend :
Versions TLS prises en charge (par exemple, TLS 1.3)
Algorithmes de chiffrement pris en charge (Cipher Suites, par exemple AES-GCM, ChaCha20)
Nombre aléatoire (Client Random) (utilisé pour la génération de clés)
Paramètres de partage de clé (par exemple, clé publique ECDHE)
SNI (Server Name Indication) (facultatif, pour la prise en charge de HTTPS à plusieurs domaines)
Son objectif est de faire connaître les capacités de chiffrement du client au serveur et de préparer les paramètres de sécurité.
2. Le serveur envoie ServerHello :
Le serveur répond au message ServerHello, qui comprend :
Algorithme de chiffrement sélectionné
Nombre aléatoire du serveur (Server Random)
Certificat du serveur (certificat X.509)
Paramètres de partage de clé du serveur (par exemple, clé publique ECDHE)
Message Finished (pour confirmer la fin de la poignée de main)
Son objectif est de faire connaître l'identité du serveur au client et de confirmer les paramètres de sécurité.
3. Le client vérifie le serveur :
Le client effectue les opérations suivantes :
Vérifier le certificat du serveur : s'assurer que le certificat est émis par une autorité de certification (AC) de confiance et vérifier s'il est expiré ou révoqué ;
Calculer la clé partagée : utiliser sa propre clé publique ECDHE et celle du serveur pour calculer la clé de session (Session Key), qui est utilisée pour le chiffrement symétrique ultérieur (par exemple, AES-GCM).
Envoyer un message Finished : prouver l'intégrité des données de la poignée de main pour empêcher les attaques de l'homme du milieu (MITM).
Son objectif est de s'assurer que le serveur est fiable et de générer une clé de session.
4. Démarrer la communication chiffrée :
Le client et le serveur utilisent désormais la clé de session négociée pour la communication chiffrée.
Utilisation du chiffrement symétrique (par exemple, AES-GCM, ChaCha20) pour chiffrer les données, ce qui améliore la vitesse et la sécurité.
Protection de l'intégrité des données : utilisation de AEAD (par exemple, AES-GCM) pour empêcher la falsification.

Par conséquent, après ces quatre étapes, les problèmes du protocole HTTP peuvent être résolus efficacement. Cependant, cette technologie de base largement utilisée dans le réseau Web2 a causé des problèmes pour le développement d'applications Web3, en particulier lorsque les contrats intelligents en chaîne souhaitent accéder à certaines données hors chaîne. En raison du problème de disponibilité des données, la machine virtuelle en chaîne n'ouvrira pas la capacité d'appeler des données externes afin de garantir la traçabilité de toutes les données et de garantir la sécurité du mécanisme de consensus.
Cependant, après une série d'itérations, les développeurs ont constaté que les DApp ont encore besoin de données hors chaîne, de sorte qu'une série de projets Oracle de prédiction sont apparus, tels que Chainlink et Pyth. Ils agissent comme un pont de relais entre les données en chaîne et les données hors chaîne pour briser ce phénomène de silos de données. Dans le même temps, afin de garantir la disponibilité des données de relais, ces Oracle sont généralement mis en œuvre par le biais d'un mécanisme de consensus PoS, c'est-à-dire que le coût du mauvais comportement des nœuds de relais est supérieur aux avantages, de sorte qu'il ne fournira pas d'informations incorrectes à la chaîne du point de vue des avantages économiques. Par exemple, si nous voulons accéder au prix pondéré de BTC sur les bourses centralisées telles que Binance et Coinbase dans un contrat intelligent, nous devons compter sur ces Oracle pour accéder et additionner les données hors chaîne, puis les transmettre et les stocker dans le contrat intelligent en chaîne avant de pouvoir les utiliser.

Quels problèmes résout zkTLS ?Cependant, on a constaté que cette solution d'acquisition de données basée sur Oracle présente deux problèmes :
1. Coût trop élevé : nous savons que pour garantir que les données transmises à la chaîne par Oracle sont des données réelles et n'ont pas été falsifiées, il est nécessaire de garantir le mécanisme de consensus PoS. Cependant, la sécurité du mécanisme de consensus PoS est basée sur le montant des fonds gagés, ce qui entraîne des coûts de maintenance. De plus, dans des circonstances normales, il existe une grande quantité de redondance d'interaction de données dans le mécanisme de consensus PoS, car lorsque les ensembles de données doivent être transmis, calculés et résumés à plusieurs reprises en réseau, ils ne peuvent être consensuels, ce qui augmente également le coût d'utilisation des données. Par conséquent, dans des circonstances normales, les projets Oracle ne maintiennent gratuitement que certaines des données les plus courantes afin d'acquérir des clients, telles que les prix des principaux actifs tels que BTC. Pour les besoins exclusifs, il est nécessaire de payer pour cela. Cela entrave l'innovation applicative, en particulier certains besoins de longue traîne et personnalisés.
2. Faible efficacité : dans des circonstances normales, le consensus du mécanisme PoS prend un certain temps, ce qui entraîne un décalage des données en chaîne, ce qui est défavorable à certains scénarios d'utilisation à accès haute fréquence, car les données obtenues en chaîne présentent un retard important par rapport aux données réelles hors chaîne.
Afin de résoudre les problèmes susmentionnés, la technologie zkTLS a vu le jour. Son idée principale est d'introduire l'algorithme de preuve à connaissance zéro ZKP pour permettre aux contrats intelligents en chaîne d'agir en tant que tiers et de vérifier directement que les données fournies par un nœud sont bien les données renvoyées après avoir accédé à une ressource HTTPS et qu'elles n'ont pas été falsifiées. Cela permet d'éviter les coûts d'utilisation élevés des Oracle traditionnels dus à l'algorithme de consensus.
Certains amis peuvent se demander pourquoi ne pas intégrer directement la capacité d'appel d'API Web2 dans l'environnement VM en chaîne. La réponse est non, car la raison pour laquelle l'environnement en chaîne doit conserver des données fermées est de garantir la traçabilité de toutes les données, c'est-à-dire que dans le processus de consensus, tous les nœuds ont une logique d'évaluation unifiée pour l'exactitude d'une certaine donnée ou d'un certain résultat d'exécution, ou une logique de vérification objective. Cela garantit que dans un environnement de confiance complètement supprimé, la plupart des nœuds bienveillants peuvent s'appuyer sur leurs données redondantes pour juger de l'authenticité des résultats directs. Cependant, en raison des données Web2, il est difficile de construire cette logique d'évaluation unifiée, car en raison de certains retards de réseau, les résultats obtenus par différents nœuds accédant aux ressources HTTPS Web2 sont différents, ce qui ajoute des difficultés au consensus, en particulier pour certains domaines de données à haute fréquence. De plus, un autre problème clé est que la sécurité du protocole TLS sur lequel repose le protocole HTTPS dépend du nombre aléatoire généré par le client (Client Random) (utilisé pour la génération de clés) et des paramètres de partage de clé pour parvenir à une négociation avec le serveur pour la clé de chiffrement, mais nous savons que l'environnement en chaîne est public et transparent. Si l'on laisse les contrats intelligents maintenir le nombre aléatoire et les paramètres de partage de clé, les données clés seront exposées, ce qui portera atteinte à la confidentialité des données.
zkTLS adopte une autre approche. Son idée est de remplacer le coût élevé des Oracle traditionnels basés sur un mécanisme de consensus pour rendre les données disponibles par une protection cryptographique. Semblable à l'optimisation de ZK-Rollup par rapport à OP-Rollup dans L2. Plus précisément, en introduisant la preuve à connaissance zéro ZKP et en générant des preuves pour la ressource obtenue par le nœud de relais hors chaîne en demandant un certain HTTPS, les informations de vérification des certificats CA associés, la preuve de séquençage et la preuve d'intégrité des données basée sur HMAC ou AEAD, et en maintenant les informations de vérification nécessaires et l'algorithme de vérification en chaîne, de sorte que les contrats intelligents puissent vérifier l'authenticité, l'efficacité et la fiabilité de la source de données sans exposer les informations clés. Les détails spécifiques de l'algorithme ne sont pas discutés ici, les amis intéressés peuvent l'étudier en profondeur par eux-mêmes.
Le plus grand avantage de cette solution technique est de réduire le coût de réalisation de la disponibilité des ressources HTTPS Web2. Cela a stimulé de nombreux nouveaux besoins, en particulier en termes de réduction du prix d'acquisition des actifs de longue traîne en chaîne, en utilisant des sites Web faisant autorité dans le monde Web2 pour faire du KYC en chaîne, afin d'optimiser la conception de l'architecture technique de DID et Web3 Game. Bien sûr, nous pouvons constater que l'impact de zkTLS sur les entreprises Web3 existantes existe également, en particulier pour les projets Oracle grand public actuels. Par conséquent, afin de faire face à cet impact, les géants du secteur tels que Chainlink et Pyth suivent activement la recherche dans les directions connexes, en essayant d'occuper toujours une position dominante dans le processus d'itération technologique, et favoriseront également de nouveaux modèles commerciaux, tels que le passage de la facturation par heure à la facturation par utilisation, Compute as a service, etc. Bien sûr, la difficulté ici est la même que pour la plupart des projets ZK, à savoir comment réduire les coûts de calcul afin qu'ils aient une valeur commerciale.
En résumé, les amis peuvent également prêter attention à la dynamique de développement de zkTLS lors de la conception de produits, et intégrer cette pile technologique dans les aspects appropriés, peut-être peuvent-ils trouver de nouvelles directions dans l'innovation commerciale et l'architecture technique.