Tout savoir sur Chainlink DECO : une oracle privée
TechFlow SélectionTechFlow Sélection
Tout savoir sur Chainlink DECO : une oracle privée
Web3 redéfinit la valeur des données, mais la blockchain à structure décentralisée est un système fermé et déterministe.
Dédié à des analyses Web3 approfondiesRédaction : kokii.eth, stagiaire chez Qiming Venture Partners
0. Introduction
Web3 redéfinit la valeur des données, mais les blockchains à structure distribuée sont des systèmes déterministes fermés. Les contrats intelligents ne disposent pas de fonctionnalité d'appel aux API externes, ce qui a donné naissance au mécanisme des oracles afin d'aider les contrats intelligents à obtenir des données externes.
Faire remonter des données hors chaîne vers la chaîne n'est pas en soi difficile ; le défi réside dans la création de confiance via des conceptions techniques et mécanismes. Le problème de l'oracle consiste précisément à garantir la confiance tout au long du processus allant de la source des données jusqu'à leur traitement et transmission.
Une condition fondamentale pour qu’un oracle soit largement reconnu est sa décentralisation, c’est-à-dire l’absence de point de défaillance unique et la possibilité de vérifier les données. La solution courante pour atteindre une décentralisation hors chaîne consiste à utiliser plusieurs nœuds de données formant un réseau d'oracles décentralisé. Chaque nœud collecte les données, parvient à un consensus, puis les transmet aux contrats intelligents sur la blockchain.
Architecture de Chainlink
Actuellement, l'utilisation principale des oracles est de fournir des flux de prix (Price Feed) aux applications DeFi, en mettant à jour de manière sécurisée, rapide et précise les prix des actifs sous-jacents. Selon les données de DefiLlama, Chainlink est l'une des principales solutions d'oracle disponibles sur le marché. Au moment de la rédaction de cet article, elle garantissait une valeur totale d’environ 11 milliards de dollars, représentant environ 46 % du marché.
Données du marché des oracles
Avec le développement de la blockchain, la demande de données hors chaîne devient de plus en plus forte. Se contenter de fournir des prix aux applications DeFi ne suffit plus aux besoins des développeurs. La majorité des données du monde réel et du Web2 ne sont pas publiquement accessibles, mais elles sont essentielles pour construire de nouvelles applications innovantes dans Web3 (prêts basés sur le crédit, réseaux sociaux, identités numériques, KYC/AML, etc.). Par conséquent, les nouveaux oracles doivent permettre aux contrats intelligents de prendre en charge des cas d’utilisation complexes impliquant des données sensibles tout en préservant la confidentialité.
DECO est la solution proposée par Chainlink dans cette direction : en utilisant la technologie des preuves à divulgation nulle de connaissance (ZKP), elle permet à un utilisateur de générer une preuve de données privées hors chaîne destinée à un contrat intelligent, sans divulguer ces données ni au public ni aux nœuds de l’oracle eux-mêmes.
DECO peut se connecter aux API existantes, même lorsque celles-ci nécessitent une authentification par l'utilisateur final (par exemple, accéder au solde d'un compte bancaire après connexion), sans exiger aucune modification de la part du fournisseur de données. Actuellement en phase alpha, DECO effectue des tests de validation conceptuelle avec plusieurs partenaires.
1. Contexte
Nous fournissons ici les notions nécessaires concernant TLS et ZKP, sur lesquelles repose DECO.
1.1 TLS
TLS (Transport Layer Security, sécurité de la couche transport) est un protocole de sécurité puissant et largement déployé, ancêtre de SSL. Il vise à assurer la confidentialité et l’intégrité des communications Internet. Situé entre la couche applicative et la couche TCP/IP, son usage principal est de chiffrer les échanges entre les applications web et les serveurs.
Les communications HTTP transitent en texte clair, vulnérables à l’écoute, à la falsification ou à l’usurpation. Une fois TLS activé, les données HTTP envoyées par l’utilisateur au site web (clics, saisie de formulaires, etc.) ainsi que celles renvoyées par le site sont chiffrées. Le destinataire doit disposer d’une clé pour déchiffrer ces données. HTTPS correspond à l’application du chiffrement TLS sur le protocole HTTP. C’est désormais la norme pour les sites web, qui doivent installer un certificat TLS sur leur serveur d’origine. Les navigateurs marquent désormais comme « non sécurisés » tous les sites ne passant pas par HTTPS.
Sites non-HTTPS
L'idée centrale de TLS repose sur le chiffrement asymétrique. Le certificat TLS/SSL publié par le site contient la clé publique, tandis que la clé privée reste installée sur le serveur d'origine et appartient au propriétaire du site. Le client demande d’abord la clé publique du serveur, puis chiffre ses messages avec celle-ci. À la réception, le serveur déchiffre le message à l’aide de sa clé privée.
Toutefois, le chiffrement asymétrique est coûteux en calcul. Pour réduire le temps de session, chaque session génère une « clé de session » (session key), utilisée pour chiffrer les données. Cette clé étant symétrique, elle permet un chiffrement très rapide. La clé publique du serveur sert uniquement à chiffrer la clé de session elle-même, limitant ainsi la durée des opérations coûteuses.
Le protocole TLS peut donc être divisé en deux couches principales :
-
Protocole de poignée de main (handshake protocol) : communication en clair, où les deux parties s’authentifient mutuellement via un chiffrement asymétrique, choisissent les algorithmes de chiffrement à utiliser et génèrent une clé de session commune destinée au chiffrement symétrique du protocole suivant.
-
Protocole d’enregistrement (record protocol) : constitue le cœur du protocole, assurant la confidentialité et l'intégrité des données transmises.
Pile protocolaire TLS
La suite cryptographique (CipherSuite) de TLS combine quatre algorithmes :
-
Authentification : vérifie l’identité des participants. Les méthodes courantes incluent RSA, DSA et ECDSA.
-
Échange de clés : négociation entre les deux parties d’une clé de chiffrement commune. La méthode dominante est ECDHE.
-
Chiffrement : chiffrement symétrique des données échangées. L'utilisation de GCM tend à devenir la norme.
-
MAC (Code d'authentification de message) : vérifie l’intégrité des données et détecte toute tentative de falsification. Les standards incluent SHA256, SHA384 et SHA1.
TLS est très robuste, mais présente une limite : il ne permet pas à un utilisateur de prouver à un tiers que les données consultées proviennent bien d’un site spécifique. En effet, les données sont chiffrées symétriquement, et tant l’utilisateur que le serveur peuvent signer les données. Prenons un exemple : de nombreux serveurs web stockent les informations d’identité d’Alice et peuvent facilement attester qu’elle a plus de 18 ans. Mais Alice peine à prouver ce fait à Bob. Elle pourrait faire une capture d’écran, mais celle-ci serait facilement falsifiable. Même si la preuve était authentifiée, cela révélerait trop d’informations — sa date exacte de naissance — alors qu’il suffirait de savoir qu’elle est majeure.
Un oracle doit pouvoir prouver de manière décentralisée (sans dépendre d’un point unique comme un serveur web) l’origine des données privées hors chaîne (provenance), et permettre aux contrats intelligents d’y accéder sans compromettre la confidentialité. Les preuves à divulgation nulle de connaissance (ZKP) peuvent aider à atteindre ces objectifs.
1.2 ZKP
Les preuves à divulgation nulle de connaissance (Zero Knowledge Proof, ZKP) suscitent un grand intérêt dans le domaine de la blockchain. Elles sont principalement utilisées dans les ZK-Rollups (où des compromis ont été faits sur la conception algorithmique pour améliorer l’efficacité de mise à l’échelle, produisant des preuves de validité non strictement « zk ») et dans les technologies de confidentialité (véritables ZKP). Une preuve à divulgation nulle permet à un prouveur (Prover) de convaincre un vérificateur (Verifier) qu’il connaît une solution (Witness) à un problème de calcul donné (Statement), sans révéler aucune information supplémentaire sur cette solution.
Un système ZK typique comporte deux composantes :
-
Frontend : un compilateur transforme l’assertion à vérifier en langage spécifique au domaine (DSL), puis la convertit dans un format adapté aux ZKP, tel qu’un circuit arithmétique.
-
Backend : le système de preuve, un protocole interactif qui vérifie la correction du circuit, comme Marlin, Plonky2 ou Halo2.
Système ZK
Construire un processus interactif de questions-réponses dans un système ouvert comme la blockchain est complexe. La preuve doit pouvoir être vérifiée par n’importe qui à tout moment. Ainsi, les systèmes ZK utilisés en blockchain sont généralement non interactifs. On peut transformer un système interactif en non interactif grâce à l’heuristique de Fiat-Shamir.
2. Fonctionnement de DECO
DECO étend le protocole HTTPS/TLS sans nécessiter de modifications côté serveur.
L’idée centrale de DECO consiste à établir un nouveau protocole de poignée de main à trois parties entre le Prover (l’utilisateur ou une application Dapp exécutant DECO Prover), le Verifier (un oracle Chainlink exécutant DECO Verifier) et le Server (le fournisseur de données).
-
Provenance : lorsque le Prover interroge un serveur web, le Verifier assiste à l’échange et reçoit un engagement (Commitment) créé par le Prover à partir des données de session TLS. Cela permet au Verifier de valider l’origine authentique des informations.
-
Confidentialité : si les données ne nécessitent pas de confidentialité, le Prover peut directement fournir au Verifier la clé de déchiffrement, permettant aux développeurs d’intégrer les données dans leur Dapp. Si la confidentialité est requise, le Prover utilise une preuve ZKP pour intégrer les données sans les divulguer.
Exemple DECO
Plus précisément, le protocole DECO comprend trois phases :
-
Poignée de main à trois parties : le Prover, le Verifier et le Server établissent une clé de session dans un format spécial, garantissant l’impossibilité de falsifier les données.
-
Exécution de la requête : le Prover utilise une requête contenant ses paramètres privés θs (comme mot de passe, clé API) pour interroger le Server.
-
Génération de la preuve : le Prover prouve que la réponse satisfait certaines conditions.
Architecture DECO
2.1 Poignée de main à trois parties
Note : la description ci-dessous suppose l'utilisation de l'algorithme AES-CBC-HMAC. TLS 1.3 conserve uniquement AEAD, plus sécurisé, utilisant une seule clé pour le chiffrement et le MAC, sans clé MAC distincte. Toutefois, grâce à l'indépendance des clés dans TLS 1.3, un protocole similaire peut être construit avec une complexité comparable.
Le Prover P ne doit pas pouvoir s'engager *après* avoir obtenu la clé MAC, sinon il pourrait falsifier ou modifier les données. L'idée de la poignée de main à trois parties est donc de considérer conjointement le Prover P et le Verifier V comme un client TLS unique, négociant avec le serveur TLS S une clé MAC partagée. La clé MAC k est divisée côté client : P détient kp, V détient kv, avec k = kp + kv. En outre, P conserve également la clé de chiffrement symétrique k^{Enc}. Si V n'est pas malveillant, ce protocole garantit l'authenticité des données.
2.2 Exécution de la requête
Après la poignée de main, la clé MAC étant partagée secrètement, P et V exécutent un protocole interactif (calcul sécurisé à deux parties) pour construire un message TLS chiffré Q à partir des paramètres privés θs. Ensuite, P envoie Q au serveur S comme un client TLS standard. Durant cette étape, seul P communique avec S, et aucune requête n’est divulguée à V.
Après avoir reçu la réponse R de S, P s'engage envers V en lui envoyant le chiffré R̂, puis reçoit kv de V afin de vérifier l'authenticité de la réponse R.
2.3 Génération de la preuve
Ensuite, P doit prouver que le clair R correspondant au chiffré R̂ satisfait certaines propriétés. S’il n’y a pas de besoin de confidentialité, la clé de déchiffrement k^{Enc} peut être révélée directement. Sinon, une preuve à divulgation nulle (ZKP) est nécessaire.
Supposons que le texte clair soit composé de plusieurs blocs R=(B1,...,Bn). DECO utilise une technique appelée ouverture sélective (Selective Opening) pour générer la preuve ZKP :
-
Révèle uniquement une ligne spécifique : prouve que le i-ème bloc de R est Bi, sans révéler les autres blocs.
-
Masque les lignes contenant des données sensibles : prouve que R_{-i} est identique à R sauf que Bi a été supprimé.
Cependant, souvent le Verifier doit s’assurer que la sous-chaîne révélée apparaît dans le bon contexte. La méthode ci-dessus ne suffit pas à garantir l’intégrité contextuelle. Pour combler ce manque, DECO utilise une technique appelée analyse en deux étapes à divulgation nulle (Two-stage Parsing) : le Prover analyse localement ses données de session, identifie la plus petite sous-chaîne susceptible de convaincre le Verifier, puis l’envoie. Cela préserve la confidentialité.
Les preuves à divulgation nulle non interactives (NIZK) sont généralement coûteuses en calcul et en mémoire côté Prover. Étant donné que le Verifier dans DECO est désigné (l’oracle Chainlink), on peut utiliser des preuves interactives plus efficaces, avec une faible utilisation mémoire, sans configuration de confiance, et des calculs peu coûteux.
Dans le test alpha actuel, le rôle de Prover est encore assumé par une Dapp. Dans les itérations futures, il est prévu que le Prover puisse être déployé localement par l’utilisateur final (par exemple sur smartphone) ou dans un environnement d’exécution fiable (TEE).
3. Applications
DECO permet de vérifier la validité des informations d'identité hors chaîne d’un utilisateur tout en préservant la confidentialité des données, ouvrant ainsi la voie à de nombreuses applications innovantes dans Web3, allant de la finance aux réseaux sociaux.
- Restauration auto-gérée de l’identité / preuve d’identité légale (qui vous êtes) : avec DECO, des institutions disposant déjà de mécanismes d’authentification matures (banques, réseaux sociaux) peuvent servir de gardiens dans un processus de restauration sociale.
- Prêts sur solvabilité / preuve de fonds (combien avez-vous) : Teller est un protocole DeFi de prêt sur solvabilité qui utilise DECO pour prouver que le solde du compte bancaire hors chaîne d’un utilisateur dépasse un seuil minimum dynamique requis pour le prêt.
-
Preuve de statut de fan / preuve d’interaction (avec qui avez-vous interagi) : Clique est un oracle social développant une solution permettant d’analyser en profondeur l’influence, la fidélité et la contribution des utilisateurs hors chaîne sur diverses plateformes sociales (via l’API Twitter par exemple).
-
Identité numérique / preuve d’identité sociale (vous possédez un compte en ligne) : PhotoChromic est une solution d’identité numérique utilisant DECO pour lier les utilisateurs Web3 à leurs comptes Twitter ou Discord, sans exposer leurs données personnelles sous-jacentes, permettant aux applications de filtrer les utilisateurs réels.
-
Résistance aux attaques Sybil dans les DAO, SBT, KYC/AML, etc.
4. Autres acteurs
-
Axiom construit un oracle ZK pour TWAP Uniswap, en exploitant exclusivement des sources de données vérifiables issues de la chaîne, proche de l’indexation (ex. Hyper Oracle). Axiom et DECO sont plutôt complémentaires : de plus en plus d’activités économiques se déroulent sur chaîne (oracle purement on-chain), tandis que de nombreuses données hors chaîne doivent y être intégrées (oracle privé hors chaîne).
-
Empiric Network utilise le calcul ZK pour placer entièrement l’oracle sur chaîne, sans infrastructure hors chaîne par laquelle les données doivent transiter. Ce n’est donc pas une approche concurrente à DECO.
5. Conclusion
Chainlink, leader incontesté des oracles aujourd’hui, grâce à DECO, permettra aux contrats intelligents d’accéder à d’immenses volumes de données privées hors chaîne tout en protégeant la vie privée, ouvrant la voie à de nombreuses applications allant de la finance à l’identité et aux réseaux sociaux.
Les risques potentiels concernent la vitesse de génération des preuves par le Prover et la centralisation possible du Verifier.
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
