Transmettez le titre original ‘Comment pouvons-nous rendre l’utilisation des données web2 dans web3 réellement privée et vérifiable ?’

De nombreuses personnes qui prétendent que le web3 est le nouvel Internet le définissent par l’expression « lire, écrire, posséder ». Les parties « lire » et « écrire » sont claires, mais lorsqu’il s’agit de « posséder » en termes de données, nous ne possédons presque rien aujourd’hui.

Les données des utilisateurs sont souvent volées par les entreprises et utilisées à leur avantage. Nous ne possédons vraiment rien sur Internet.

Cependant, nous ne pouvons pas simplement passer à un monde où seul le web3 existe sans partager quoi que ce soit. Non, nous devons encore partager, mais seulement ce qui est nécessaire.

En tant que personne possédant un passeport plus faible, je suis obligé de demander des visas électroniques et de fournir d’innombrables détails sur moi-même pour prouver que je suis éligible pour des visas spécifiques. Et je me demande toujours :

• Pourquoi devrais-je partager l’intégralité de mon relevé bancaire alors qu’ils n’ont besoin de confirmer qu’un niveau de revenu spécifique?

• Pourquoi devrais-je fournir la réservation d’hôtel exacte au lieu de simplement prouver que j’ai réservé un hôtel dans ce pays ?

• Pourquoi dois-je soumettre tous les détails de mon passeport alors qu’ils ont juste besoin de vérifier ma résidence permanente dans mon pays actuel ?

Il y a deux préoccupations principales ici : les services en savent beaucoup plus qu’ils n’en ont besoin, et les données que vous fournissez ne sont pas privées. Mais quel est le lien avec la sécurité et la confidentialité dans les cryptomonnaies ?

1. Web3 ne va pas y arriver sans les données web2.

Comme la plupart d’entre vous le savent, les contrats intelligents n’ont essentiellement aucune idée du coût du BTC, de l’ETH, du SOL ou de tout autre actif. Cette tâche est déléguée aux oracles, qui publient constamment des données publiques du monde extérieur au contrat intelligent.

Dans le monde d’Ethereum, ce rôle est presque monopolisé par @chainlink avec leurs réseaux Oracle pour s’assurer que nous ne dépendons pas d’un seul nœud. Nous avons donc vraiment besoin de données web2 pour plus de cas d’utilisation au-delà de la simple connaissance du prix de certains actifs.

Cependant, cela s’applique uniquement aux données publiques. Que se passe-t-il si je veux connecter de manière sécurisée mon compte bancaire ou mon compte Telegram et partager des informations sensibles qui ne sont pas disponibles publiquement mais qui me sont privées?

La première pensée est : comment pouvons-nous amener ces données sur une blockchain avec la preuve que les données privées sont sécurisées ?

Malheureusement, cela ne fonctionne pas de cette manière car les serveurs ne signent pas les réponses qu’ils envoient, vous ne pouvez donc pas vérifier de manière fiable quelque chose comme cela dans les contrats intelligents.

Le protocole qui sécurise la communication sur un réseau informatique s’appelle TLS : Transport Layer Security. Même si vous n’en avez pas entendu parler, vous l’utilisez quotidiennement. Par exemple, en lisant cet article, vous verrez le “https://“ dans la barre d’adresse de votre navigateur.

Si vous avez essayé d’accéder au site Web avec une connexion “http://“ (sans le “s”), votre navigateur vous avertirait que la connexion n’est pas sécurisée. Le “s” dans le lien signifie TLS, qui sécurise votre connexion, garantissant la confidentialité et empêchant quiconque de voler les données que vous transmettez.

2. La connexion est déjà sécurisée, ne pouvons-nous pas simplement la transporter et l’utiliser dans le web3 ?

Comme je l’ai mentionné précédemment, nous sommes confrontés à un problème de vérifiabilité : les serveurs ne signent pas les réponses qu’ils envoient, donc nous ne pouvons pas vraiment vérifier les données.

Même si une source de données accepte de partager ses données, le protocole TLS standard ne peut pas prouver son authenticité aux autres. Simplement transmettre une réponse ne suffit pas : les clients peuvent facilement modifier les données localement, partager ces réponses expose entièrement, risquant la vie privée des utilisateurs.

Une approche du problème de vérifiabilité est une version améliorée de TLS appelée zkTLS.

Le mécanisme de fonctionnement de zkTLS est similaire à TLS mais légèrement différent, voici comment cela fonctionne :

• Vous visitez un site Web via une connexion TLS sécurisée et envoyez la demande requise.

• zkTLS génère une preuve zk qui vérifie les données tout en ne révélant que les détails spécifiques que l’utilisateur souhaite prouver, ce qui permet de préserver la confidentialité de tout le reste.

• La preuve zk générée est ensuite utilisée par d’autres applications pour confirmer et vérifier que les informations fournies sont correctes.

Quand je dis zkTLS, je fais référence à des projets utilisant zkTLS, mais il existe différentes approches pour la vérifiabilité des données en utilisant diverses solutions :

1. TEE (Environnement d’Exécution Fiable)
2. MPC (Calcul multipartite)
3. Proxy

Intéressamment, chaque approche introduit son propre ensemble de cas d’utilisation uniques. Alors, en quoi diffèrent-elles?

3. Pourquoi n’y a-t-il pas de norme unique pour zkTLS ? En quoi sont-ils différents ?

zkTLS n’est pas une seule technologie car la vérification des données web privées sans les exposer peut être abordée sous plusieurs angles, chacun avec ses propres compromis. L’idée principale est d’étendre TLS avec des preuves, mais la façon dont vous générez et validez ces preuves dépend du mécanisme sous-jacent.

Comme je l’ai mentionné auparavant, trois principales approches consistent à utiliser TEE-TLS, MPC-TLS ou Proxy-TLS.

TEE repose sur un matériel spécialisé, tel que Intel SGX ou AWS Nitro Enclaves, pour créer une “boîte noire” sécurisée où les données peuvent être traitées et les preuves générées. Le matériel garantit que les données restent privées et que les calculs sont à l’épreuve des manipulations.

Dans une configuration zkTLS basée sur TEE, le TEE exécute le protocole, prouvant l’exécution et le contenu de la session TLS. Le vérificateur est le TEE lui-même, donc la confiance dépend du fabricant du TEE et de sa résistance aux attaques. Cette approche est efficace avec une faible surcharge computationnelle et réseau.

Cependant, il présente un défaut majeur : vous devez faire confiance au fabricant du matériel, et les vulnérabilités des TEE (comme les attaques par canaux latéraux) peuvent compromettre tout le système.

Proxy-TLS et MPC-TLS sont les approches les plus largement adoptées en raison de leur plus large éventail de cas d’utilisation. Des projets comme@OpacityNetworket@reclaimprotocol, qui sont construits sur @eigenlayer, utilisez ces modèles pour garantir la sécurité et la confidentialité des données ainsi qu’une couche supplémentaire de sécurité économique.

Voyons à quel point ces solutions sont sécurisées, quels cas d’utilisation les protocoles zkTLS permettent, et ce qui est déjà opérationnel aujourd’hui.

4. Qu’est-ce qui rend le MPC-TLS et Opacity Network si spécial?

Pendant la poignée de main TLS (où un client et un serveur conviennent de communiquer de manière sécurisée en partageant des clés de chiffrement), le rôle du site web reste inchangé, mais le processus du navigateur fait quelque chose de différent.

Au lieu de générer sa propre clé secrète, il utilise un réseau de nœuds pour créer une clé secrète multipartite via MPC. Cette clé effectue le handshake pour le navigateur, garantissant qu’aucune entité unique ne connaît la clé partagée.

Le chiffrement et le déchiffrement nécessitent la coopération de tous les nœuds et du navigateur, chacun ajoutant ou supprimant sa partie du chiffrement séquentiellement avant que les données n’atteignent ou ne quittent le site Web. MPC-TLS offre une sécurité renforcée et peut être distribuée de manière à ce qu’aucun groupe n’ait tout le pouvoir.

Opacity Network améliore le classique@tlsnotarycadre en ajoutant des protections pour minimiser les problèmes de confiance. Il utilise plusieurs mesures de sécurité telles que:

1. Vérification on-chain des identifiants de compte web2
2. Engagement du schéma
3. Révéler le schéma
4. Echantillonnage aléatoire du réseau MPC
5. Journal vérifiable des tentatives

Les identifiants de compte, étant statiques dans les systèmes web2, permettent une preuve par comité où dix nœuds différents doivent confirmer la propriété. Cela lie le compte à un portefeuille unique, empêchant les tentatives répétées avec différents portefeuilles pour trouver un nœud collusif.

Vous pouvez voir comment fonctionne l’opacité en détail ci-dessous :

Les nœuds d’opacité fonctionnent dans un TEE, rendant la collusion presque impossible si le TEE est sécurisé. Au-delà des TEE, Opacity utilise également Eigenlayer pour tirer parti d’un AVS, obligeant les nœuds à restaker 32 stETH, avec des réductions immédiates en cas de faute, évitant les retards associés aux temps de refroidissement.

Vous pouvez voir que l’Opacité utilise à la fois le MPC et le TEE, mais parce que le MPC est utilisé pour zkTLS tandis que le TEE est utilisé essentiellement pour la sécurité des nœuds, il est toujours appelé MPC-TLS.

Cependant, si les TEE venaient à échouer, cela pourrait permettre à un nœud de s’engager dans une collusion au sein du MPC. C’est l’une des raisons pour lesquelles une couche de sécurité économique supplémentaire est nécessaire pour prévenir ce comportement.

C’est aussi pourquoi Opacity développe un mécanisme de lanceur d’alerte où les utilisateurs qui peuvent prouver qu’un notaire a agi de manière inappropriée seront récompensés d’une part de la pénalité imposée sur la mise du notaire.

En raison de sa simplicité d’intégration, de sa sécurité et de la confidentialité qu’elle offre, Opacity a attiré divers protocoles pour l’intégrer dans leurs produits à travers les secteurs des consommateurs, de la finance décentralisée et des agents d’IA.

L’équipe de @earnos_iodéveloppe une plateforme où les marques peuvent récompenser les utilisateurs pour leur engagement ou l’achèvement de tâches. EarnOS utilise la technologie d’Opacity pour prouver les caractéristiques via des applications populaires sans révéler d’informations personnelles, permettant aux marques de cibler les audiences tout en préservant la confidentialité des utilisateurs et en leur permettant de gagner des récompenses.

L’opacité est également intégrée dans le @daylightenergy_protocole, développant un réseau électrique décentralisé où les utilisateurs peuvent gagner des récompenses pour contribuer à des solutions d’énergie propre. Grâce à Opacity, les utilisateurs peuvent prouver la propriété de l’appareil énergétique on-chain sans matériel spécialisé.

L’opacité peut même être intégrée aux agents d’IA, apportant plus de vérifiabilité et de transparence à un domaine qui rencontre actuellement des défis importants. zkTLS a récemment été intégré dans @elizaOS, permettant des interactions en IA vérifiables sans perte de confidentialité.

Cependant, TEE-TLS et MPC-TLS ne sont que deux variations de zkTLS, il en existe également une troisième appelée Proxy-TLS, le réseau Reclaim étant la représentation la plus célèbre de ce modèle. Alors, en quoi est-il différent sur le plan technologique des deux autres variations, et quels cas d’utilisation peuvent être activés par Proxy-TLS?

5. Qu’est-ce qui rend Proxy-TLS et Reclaim Protocol si spéciaux ?

Les proxys HTTPS, courants sur Internet, transmettent le trafic chiffré sans accéder à son contenu. Dans le modèle de proxy zkTLS, il fonctionne presque de la même manière avec de légères additions :

• Le navigateur envoie des demandes au site Web via un proxy, qui gère également les réponses du site Web.

• Le proxy voit tous les échanges chiffrés et atteste de leur authenticité, en notant s’il s’agit d’une demande ou d’une réponse.

• Le navigateur génère ensuite une preuve zk qui indique qu’il peut chiffrer ces données avec une clé partagée sans révéler la clé et montre le résultat.

• Cela fonctionne parce qu’il est presque impossible de créer une fausse clé qui transforme les données en quelque chose de sensé, donc simplement montrer que vous pouvez le décrypter suffit.

Révéler la clé compromettrait tous les messages précédents, y compris des données sensibles telles que les noms d’utilisateur et les mots de passe. Proxy-TLS est assez rapide, abordable et gère bien de grands volumes de données, ce qui en fait un choix idéal pour les environnements à haut débit.

La majorité des serveurs ne restreignent pas l’accès en fonction des adresses IP variables, rendant cette méthode assez largement applicable.

Le protocole Reclaim utilise Proxy-TLS pour une vérification efficace des données et emploie des mandataires pour contourner les pare-feu Web2 empêchant le blocage de mandataires à grande échelle.

Voici comment cela fonctionne :

Le principal problème ici est la collusion : si l’utilisateur et l’attestateur sont de connivence, ils peuvent signer pratiquement n’importe quoi et agir de manière malveillante. Pour atténuer ce problème, Reclaim intègre un sous-ensemble de validateurs choisis pour introduire le caractère aléatoire et bloquer de tels exploits.

Reclaim utilise AVS d’Eigen pour décentraliser la validation des données. Les opérateurs d’EigenLayer peuvent agir en tant qu’attestants, mais ils devront déployer leur propre AVS pour spécifier la logique d’attestation pour leur service.

Reclaim est une plateforme permettant des cas d’utilisation uniques comme l’importation de données de covoiturage pour les applications de transport, le pontage de données hors chaîne pour l’économie blockchain, la vérification des identités avec des données d’identité nationale, la création de solutions de données personnalisées via des outils de développement, et plus encore.

L’écosystème Reclaim abrite plus de 20 projets, mais j’aimerais mettre en avant 4 d’entre eux dans les marchés monétaires, l’identité numérique, la consommation et les secteurs de l’embauche.

@3janexyzest le premier marché monétaire basé sur le crédit sur Base, offrant des lignes de crédit sécurisées aux utilisateurs de crypto en évaluant leur solvabilité et leurs flux de trésorerie futurs, en utilisant à la fois des données financières sur chaîne et hors chaîne.

3Jane utilise le modèle proxy de Reclaim pour vérifier les données de crédit de VantageScore, Cred, Coinbase et Plaid, garantissant ainsi la confidentialité de ces données.

Une autre utilisation des cotes de crédit avec zkTLS est de passer par @zkme_‘s feature, zkCreditScore. It uses Reclaim Protocol to get your US credit score securely with zkTLS. This lets zkMe check a user’s credit score and make unique soulbound tokens (SBTs) to store this data.

Y a-t-il d’autres cas d’utilisation en dehors des scores de crédit? Bien sûr, il y en a.

Nous pouvons prendre @zkp2pà titre d’exemple, qui est un marché des biens de consommation qui exploite Reclaim pour vérifier les données des utilisateurs de Ticketmaster ainsi que pour vérifier les paiements des utilisateurs.

En même temps, @bondexapp, qui est l’une des plateformes d’emploi les plus populaires dans le domaine de la crypto, utilise Reclaim pour obtenir la preuve du travail des profils, vérifiant que les données sont réelles, privées et vérifiables.

En examinant les cas d’utilisation possibles via zkTLS, la capacité de vérifier les transcriptions TLS on-chain débloque déjà de nombreuses nouvelles fonctionnalités, permettant aux utilisateurs de contrôler leurs propres données sans avoir besoin de l’autorisation de grandes entreprises.

Plus important encore, zkTLS est conçu pour garantir que vos données personnelles ne sont pas utilisées contre vous. Alors, où cela nous mène-t-il ?

6. zkTLS est-il là pour rester ?

Il reste du travail à faire, mais les différents protocoles zkTLS introduisent déjà de nouveaux cas d’utilisation qui redistribuent le pouvoir aux utilisateurs.

@Tim_RoughgardenLe podcast a16z crypto a souligné que les preuves zk, proposées en 1985, n’ont gagné en popularité que grâce à des centaines de développeurs qui ont travaillé à réduire la taille et les coûts des preuves, notamment dans le cadre des applications blockchain.

Et maintenant, les contributions de l’industrie de la blockchain trouvent des applications dans d’autres domaines au-delà de la crypto elle-même.

Je m’attends à ce qu’une histoire similaire se déroule avec zkTLS, en commençant par la mise en œuvre dans le Web3, puis en s’étendant au-delà, car, comme je l’ai déjà dit, actuellement, nous « lisons » et « écrivons », mais nous sommes à peine protégés et nous ne « possédons » même pas nos propres données.

Avertissement :

1. Cet article est repris de [ Pavel Paramonov]. Tous les droits d’auteur appartiennent à l’auteur original [Pavel Paramonov]. Si des objections sont formulées à cette reproduction, veuillez contacter le Porte d’apprentissagel’équipe, et ils s’en occuperont rapidement.
2. Responsabilité de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l’auteur et ne constituent pas un conseil en investissement.
3. L’équipe de Gate Learn traduit l’article dans d’autres langues. Copier, distribuer ou plagier les articles traduits est interdit sauf mention contraire.