Comment construire un protocole cross-chain faux-décentralisé ?
TechFlow SélectionTechFlow Sélection
Comment construire un protocole cross-chain faux-décentralisé ?
« Les grands designs semblent toujours très simples, mais le processus qui les crée est en réalité extrêmement complexe. »
Dédié à des analyses Web3 approfondiesAuteur : Kang Shuiyue, fondateur de Fox Tech et Way Network, président du groupe DanYang Investment
Une citation d’Adam Back (chef d’équipe principal du développement Bitcoin, PDG de BlockStream) m’a profondément marqué : « Un grand design semble toujours très simple, mais le processus de conception en lui-même est extrêmement complexe ». Toutefois, tous les designs produits qui semblent simples ne méritent pas pour autant d’être qualifiés de « grands », comme c’est le cas de LayerZero.
Les protocoles multichaînes paraissent sûrs tant qu’aucun incident ne se produit, mais lorsqu’un problème survient, il s’agit généralement d’un événement dramatique. En examinant les pertes financières liées aux incidents de sécurité survenus ces deux dernières années sur différentes blockchains, les failles dans les protocoles multichaînes arrivent en tête des classements.
L’importance et l’urgence de résoudre les problèmes de sécurité des protocoles multichaînes dépassent même celles des solutions de mise à échelle d’Ethereum. L’interopérabilité entre protocoles multichaînes constitue une exigence fondamentale pour que Web3 devienne un véritable réseau. Ces protocoles attirent souvent des financements colossaux, et leur TVL ainsi que leur volume de transactions augmentent continuellement sous la pression de la demande réelle. Pourtant, en raison d’une faible visibilité du public, il est difficile de distinguer leurs niveaux de sécurité respectifs.
Examinons d’abord une architecture de produit : la communication entre Chain A et Chain B est assurée par un Relayer, surveillé par un Oracle.
Cette architecture présente un avantage notable : elle supprime la nécessité d’utiliser une troisième chaîne (sur laquelle aucun dApp n’est généralement déployé) pour exécuter un algorithme de consensus et faire valider les transactions par une dizaine de nœuds. Elle permet ainsi d’offrir aux utilisateurs une expérience fluide de « transfert rapide entre chaînes ». De par sa légèreté, sa faible quantité de code, et l’utilisation d’un Oracle existant tel que Chainlink, ce type de projet peut être lancé rapidement. Mais il est aussi facilement reproductible — son seuil technologique est pratiquement nul.
Figure 1 : Version de base d’un protocole multichaîne faussement décentralisé
Cette architecture comporte au moins deux problèmes :
1. LayerZero réduit la validation par plusieurs dizaines de nœuds à une simple vérification par un Oracle unique, ce qui diminue considérablement le niveau de sécurité.
2. Une fois simplifié à une seule entité de validation, on doit supposer que le Relayer et l’Oracle sont indépendants. Or cette hypothèse de confiance ne peut pas tenir indéfiniment ; elle n’est pas suffisamment « crypto-native » et ne garantit pas fondamentalement l’impossibilité d’une collusion malveillante entre les deux parties.
C’est précisément le modèle de base adopté par LayerZero. En tant que solution « ultra-légère » de type sécurité isolée, il se contente de transmettre des messages, sans assumer aucune responsabilité — ni même avoir la capacité — en matière de sécurité applicative.
Mais alors, si l’on ouvrait le rôle de Relayer afin que n’importe qui puisse opérer un relais, cela résoudrait-il ces problèmes ?
La figure 2 représente simplement une multiplication des entités de la figure 1. D’emblée, rappelons que « décentralisé » ne signifie pas simplement augmenter le nombre d’opérateurs ou autoriser toute personne à rejoindre — cela s’appelle « permissionless ». Le côté demande a toujours été permissionless. Rendre également permissionless le côté offre n’est pas une révolution technologique, mais un changement de marché, sans lien direct avec la sécurité intrinsèque du produit. Dans LayerZero, le Relayer n’est qu’un intermédiaire chargé de relayer des informations, tout comme l’Oracle — tous deux sont des tiers de confiance (Trusted Third Parties). Tenter de renforcer la sécurité multichaîne en passant d’un acteur de confiance à trente est futile : non seulement cela ne change pas la nature du produit, mais cela crée aussi de nouveaux risques.
Figure 2 : Version avancée d’un protocole multichaîne faussement décentralisé
Si un projet de jeton multichaîne autorise la modification des nœuds LayerZero configurés, un attaquant pourrait remplacer ces nœuds par ses propres nœuds « LayerZero » et ainsi falsifier n’importe quel message. En définitive, les projets utilisant LayerZero subiraient de graves failles de sécurité, d’autant plus critiques dans des scénarios complexes. Dans un système étendu, la compromission d’un seul élément peut entraîner une réaction en chaîne catastrophique.
LayerZero n’a pas en soi la capacité de résoudre ce problème. En cas d’incident, LayerZero rejeterait naturellement la responsabilité sur les applications externes. Les utilisateurs finaux doivent donc eux-mêmes évaluer attentivement la sécurité de chaque projet utilisant LayerZero. Cela pousse les projets axés sur l’utilisateur à être prudents avant d’intégrer LayerZero, de peur d’être contaminés par des applications malveillantes appartenant au même écosystème. Ce constat complique sérieusement le développement de l’écosystème.
Si LayerZero ne peut pas partager la sécurité comme le font les Layer1 ou Layer2, alors ce Layer0 ne mérite pas d’être appelé Infrastructure. Car ce qui rend une infrastructure « fondamentale », c’est justement sa capacité à partager la sécurité. Si un projet se revendique comme une infrastructure, il devrait fournir, comme les autres infrastructures, un niveau de sécurité uniforme à tous les projets de son écosystème, c’est-à-dire que tous ces projets bénéficient collectivement de la sécurité de l’infrastructure sous-jacente.
Ainsi, pour être précis, LayerZero n’est pas une infrastructure (Infrastructure), mais un middleware. Les développeurs d’applications intégrant le SDK/API de ce middleware peuvent effectivement définir librement leurs propres stratégies de sécurité.
L’équipe L2BEAT a publié le 5 janvier 2023 un article intitulé *Circumventing Layer Zero: Why Isolated Security is No Security*, dans lequel elle critique l’hypothèse selon laquelle le propriétaire de l’application (ou celui détenant les clés privées) ne ferait jamais d’actes malveillants. Prenons l’exemple du « méchant Bob » qui obtient l’accès aux configurations de LayerZero. Il pourrait alors remplacer l’Oracle et le Relayer par défaut par des composants qu’il contrôle, et convaincre un contrat intelligent utilisant LayerZero sur Ethereum de retirer tous les jetons d’Alice, une utilisatrice honnête. Lien vers l'article original
Le 31 janvier 2023, l’équipe Nomad a également publié un article pointant deux vulnérabilités critiques dans le Relayer de LayerZero. Actuellement en configuration de signature multi-signature à deux parties, ces failles ne peuvent être exploitées que par du personnel interne ou des membres d’équipe identifiés. La première permet d’envoyer des messages frauduleux depuis le contrat multi-signature, la seconde permet de modifier un message après sa signature par l’Oracle et le contrat multi-signature. Ces deux failles peuvent entraîner le vol de tous les fonds des utilisateurs. Lien vers l'article original
Quand on est séduit par des apparences sophistiquées, il faut revenir à l’essentiel.
Le 31 octobre 2008, le livre blanc du Bitcoin est publié. Le 3 janvier 2009, le bloc génèse du BTC voit le jour. Voici le résumé du livre blanc *Bitcoin : un système monétaire électronique pair-à-pair* :
Abstract. A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.
Traduction du résumé en chinois :
Un système monétaire électronique purement pair-à-pair permettrait d’envoyer des paiements en ligne directement d’une partie à une autre sans passer par une institution financière. Les signatures numériques apportent une partie de la solution, mais les principaux avantages disparaissent si un tiers de confiance reste nécessaire pour empêcher la double dépense. Nous proposons une solution au problème de la double dépense via un réseau pair-à-pair. Ce réseau horodatera les transactions en les hachant dans une chaîne continue de preuve de travail basée sur le hachage, formant un registre impossible à modifier sans refaire la preuve de travail. La chaîne la plus longue sert non seulement de preuve de la séquence des événements observés, mais aussi de preuve qu’elle provient du plus grand ensemble de puissance de calcul. Tant qu’une majorité de la puissance de calcul est contrôlée par des nœuds qui ne cherchent pas à attaquer le réseau, ils produiront la chaîne la plus longue et surpasseront les attaquants. Le réseau lui-même requiert une structure minimale. Les messages sont diffusés au mieux, et les nœuds peuvent quitter ou rejoindre le réseau à tout moment, en acceptant la chaîne de preuve de travail la plus longue comme preuve de ce qui s’est produit durant leur absence.
À partir de cet article fondateur, en particulier de ce résumé, les gens ont extrait ce que l’on appelle désormais largement le « consensus de Satoshi », dont la caractéristique centrale est l’élimination totale d’un Trusted Third Party, réalisant ainsi un système « sans confiance » (trustless) et décentralisé (decentralized). Ici, le terme « centre » désigne précisément ce Trusted Third Party. Les protocoles de communication multichaîne sont essentiellement similaires au Bitcoin : il s’agit de systèmes pair-à-pair où une partie envoie directement un actif de la chaîne A à une autre partie sur la chaîne B, sans passer par un tiers de confiance.
Le « consensus de Satoshi », caractérisé par la décentralisation et l’absence de confiance, est devenu l’objectif commun de tous les développeurs d’infrastructures. On peut dire que tout protocole multichaîne ne satisfaisant pas au « consensus de Satoshi » est un protocole faussement décentralisé, et ne devrait pas utiliser des termes élevés comme « décentralisé » ou « sans confiance » pour décrire ses fonctionnalités. Pourtant, LayerZero se décrit lui-même comme suit : « Omnichain communication, interoperability, decentralized infrastructure. LayerZero is an omnichain interoperability protocol designed for lightweight message passing across chains. LayerZero provides authentic and guaranteed message delivery with configurable trustlessness ».
En réalité, LayerZero exige à la fois que le Relayer et l’Oracle ne collaborent pas malicieusement, et que les utilisateurs fassent confiance aux développeurs d’applications utilisant LayerZero comme tiers de confiance. En outre, les entités participant à la signature multi-signature sont des rôles privilégiés pré-sélectionnés. Par ailleurs, aucun mécanisme de preuve de fraude (fraud proof) ou de preuve de validité (validity proof) n’est généré au cours du processus multichaîne, encore moins soumis à la chaîne pour vérification on-chain. Par conséquent, LayerZero ne satisfait absolument pas au « consensus de Satoshi » et n’est ni décentralisé ni sans confiance.
Après que les équipes L2BEAT et Nomad aient publié des articles bien intentionnés en tant que découvreurs de problèmes, la réponse de LayerZero a été un « déni », puis un autre « déni ». Avant Bitcoin, de nombreuses monnaies électroniques ont existé, mais toutes ont échoué, car elles n’ont pas réussi à atteindre les objectifs de décentralisation, de résistance aux attaques et de valeur intrinsèque. Il en va de même pour les protocoles multichaînes : peu importe le montant du financement, le trafic ou la « pureté de lignage », s’ils ne parviennent pas à offrir une sécurité réellement décentralisée, ils finiront très probablement par échouer en raison d’une faible résilience face aux attaques.
Un ami, dont je pensais qu’il soutenait fermement LayerZero, m’a un jour posé cette question intrigante : « Si LayerZero voulait améliorer son protocole multichaîne en utilisant des preuves à connaissance nulle (zero-knowledge proofs), comme Way Network, quel serait le niveau de difficulté et quels obstacles rencontreraient-ils ? » Une question intéressante, dont la clé réside dans le fait qu’ils ne reconnaissent pas avoir de problème.
Pour savoir comment construire un véritable protocole multichaîne décentralisé, vous pouvez consulter mon article précédent : « Pourquoi utiliser des preuves à connaissance nulle pour développer un protocole multichaîne ? »
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
