Défis de sécurité des protocole cross-chain et importance réelle de la Décentralisation

Ces dernières années, les protocoles cross-chain jouent un rôle de plus en plus important dans l'écosystème de la blockchain. Cependant, ces protocoles font également face à de sérieux défis en matière de sécurité. D'après les données des deux dernières années, les incidents de sécurité liés aux protocoles cross-chain ont causé les pertes les plus importantes parmi tous les types d'incidents de sécurité blockchain, leur importance et leur urgence dépassant même celles des solutions d'extension d'Ethereum.

L'interopérabilité entre les protocoles cross-chain est un besoin intrinsèque de la décentralisation du réseau Web3. Ce type de protocole peut généralement obtenir d'énormes financements, et sa valeur totale verrouillée (TVL) ainsi que son volume de transactions continuent d'augmenter. Cependant, le grand public a une faible capacité de reconnaissance des niveaux de sécurité de ces protocoles, ce qui rend difficile l'évaluation précise de leurs risques.

Analysons d'abord une architecture typique de communication cross-chain. Dans cette architecture, la communication entre la Chaîne A et la Chaîne B est exécutée par un Relayer, tandis qu'un Oracle supervise le Relayer. L'avantage de ce design est qu'il évite la complexité des méthodes traditionnelles qui nécessitent une troisième chaîne (généralement non déployée dApp) pour réaliser des algorithmes de consensus et des validations multi-nœuds, offrant ainsi aux utilisateurs une expérience de "rapide cross-chain". Étant donné que l'architecture est légère, avec peu de code, et qu'elle peut tirer parti de solutions Oracle prêtes à l'emploi (comme Chainlink), ce type de projet peut être rapidement mis en ligne, mais il est également facile à imiter, avec une barrière technique relativement basse.

Cependant, cette architecture présente au moins deux problèmes majeurs:

1. La simplification de la validation multi-nœuds en une validation Oracle unique a considérablement réduit le coefficient de sécurité.
2. Le modèle de validation simplifié doit supposer que le Relayer et l'Oracle sont indépendants, mais cette hypothèse de confiance est difficile à établir de manière permanente, ne correspond pas à la philosophie native de la cryptographie et ne peut pas fondamentalement empêcher une collusion malveillante entre les deux parties.

Certaines solutions cross-chain adoptent ce mode "ultra léger". En tant que solution cross-chain légère de type sécurité indépendante, elles ne sont responsables que de la transmission des messages, sans être responsables de la sécurité des applications, et n'ont pas la capacité de prendre cette responsabilité.

Certaines personnes pourraient se demander si l'ouverture du Relayer, permettant à plus de participants de faire fonctionner les relais, pourrait résoudre les problèmes mentionnés ci-dessus. Cependant, augmenter simplement le nombre d'opérateurs n'est pas équivalent à la Décentralisation. La Décentralisation ne se réfère pas seulement à l'augmentation du nombre de participants ou à l'ouverture des accès, c'est simplement un changement du côté du marché, qui n'a pas beaucoup à voir avec la sécurité du produit lui-même. Dans certaines solutions, le Relayer est essentiellement un intermédiaire responsable de la transmission d'informations, similaire à un Oracle, et appartient à un tiers de confiance. Essayer d'améliorer la sécurité cross-chain en augmentant le nombre d'entités de confiance est vain, car cela ne modifie pas les caractéristiques essentielles du produit et peut même introduire de nouveaux problèmes.

Si un projet cross-chain permet de modifier la configuration de ses nœuds, un attaquant pourrait remplacer ces nœuds par ceux qu'il contrôle, permettant ainsi de falsifier n'importe quel message. Dans ce cas, les projets utilisant ce protocole pourraient faire face à d'énormes risques de sécurité, surtout dans des scénarios complexes. Dans un grand système, il suffit qu'un seul maillon soit remplacé pour déclencher une réaction en chaîne. Certains protocoles cross-chain eux-mêmes pourraient ne pas être en mesure de résoudre ce problème et, en cas d'incident de sécurité, ils pourraient rejeter la responsabilité sur des applications externes.

Si un projet qui se prétend être une "infrastructure" ne peut pas partager la sécurité comme le fait un Layer 1 ou un Layer 2, alors il ne peut pas être véritablement qualifié d'infrastructure. Ce qui rend une infrastructure "de base", c'est sa capacité à fournir une sécurité cohérente à l'ensemble de l'écosystème. Par conséquent, certains protocoles cross-chain peuvent être plus précisément décrits comme des middleware, plutôt que comme une infrastructure.

Certaines équipes de sécurité ont signalé des risques potentiels liés à certains protocoles cross-chain. Par exemple, des études montrent que si le propriétaire de l'application (ou la personne détenant la clé privée) obtient l'accès à la configuration du protocole, il pourrait modifier les oracles et les relais pour les remplacer par des composants qu'il contrôle, manipulant ainsi les transactions cross-chain. De plus, certains relais de protocoles peuvent présenter des vulnérabilités critiques, bien qu'ils soient actuellement protégés par plusieurs signatures, il existe toujours un risque d'exploitation par des membres du personnel ou des membres d'équipe ayant une identité connue.

Lors de l'évaluation des protocoles cross-chain, nous devrions revenir aux origines de la technologie blockchain. L'idée fondamentale proposée dans le livre blanc de Bitcoin, "Bitcoin : un système de monnaie électronique peer-to-peer", à savoir la décentralisation et l'absence de confiance, est devenue l'objectif commun de tous les développeurs d'infrastructure ultérieurs. Les protocoles cross-chain qui ne satisfont pas à ces caractéristiques pourraient avoir du mal à être qualifiés de véritables protocoles cross-chain décentralisés.

Un véritable protocole de décentralisation cross-chain devrait permettre une communication directe de point à point, sans dépendre d'un tiers de confiance. Il devrait avoir une capacité de résistance aux attaques et être capable de générer des preuves de fraude vérifiables ou des preuves de validité. Ces preuves devraient pouvoir être mises en chaîne et vérifiées en chaîne, afin d'assurer la sécurité et la crédibilité du système.

Construire un véritable protocole de décentralisation cross-chain est une tâche difficile. Certaines méthodes innovantes, comme l'utilisation de la technologie des preuves à divulgation nulle de connaissance, pourraient offrir de nouvelles idées pour résoudre ces problèmes. Cependant, la clé réside dans le fait que l'équipe de développement du protocole doit faire face aux défis de sécurité existants et rechercher activement des solutions d'amélioration, plutôt que de simplement nier l'existence des problèmes.

Dans le contexte du développement continu de la technologie blockchain, nous devons évaluer et concevoir les protocoles cross-chain de manière plus prudente et responsable. Ce n'est qu'en réalisant véritablement la Décentralisation et les caractéristiques sans confiance que nous pourrons construire une infrastructure cross-chain sécurisée, fiable et ayant une valeur à long terme, favorisant ainsi le développement sain de tout l'écosystème blockchain.