Explorer la sécurité et la décentralisation des protocoles cross-chain

Les problèmes de sécurité des protocoles cross-chain ont récemment suscité une attention considérable. D'après les pertes causées par les événements de sécurité survenus sur différentes blockchains au cours des deux dernières années, les pertes liées aux événements de sécurité des protocoles cross-chain se classent en tête. L'importance et l'urgence de résoudre les problèmes de sécurité des protocoles cross-chain dépassent même celles des solutions d'extension d'Ethereum. L'interopérabilité entre les protocoles cross-chain est un besoin intrinsèque à l'interconnexion de Web3. Ce type de protocole mobilise généralement d'énormes financements, avec une valeur totale verrouillée de (TVL) et un volume de transactions en constante augmentation sous l'effet d'une demande rigide. Cependant, en raison d'une faible connaissance du public concernant ces protocoles cross-chain, il est difficile d'évaluer avec précision leur niveau de sécurité.

Regardons d'abord une architecture de conception de produit typique cross-chain. Dans le processus de communication entre la Chaîne A et la Chaîne B, le Relayer exécute les opérations spécifiques, tandis que l'Oracle est chargé de superviser le Relayer. Un avantage de cette architecture est qu'elle évite la nécessité d'une troisième chaîne (généralement non déployée dApp) pour accomplir l'algorithme de consensus et le processus de validation par des dizaines de nœuds, ce qui permet d'offrir à l'utilisateur final une expérience de "cross-chain rapide". En raison de l'architecture légère, de la faible quantité de code, et du fait que l'Oracle peut directement utiliser des services existants tels que Chainlink, ce type de projet peut être mis en ligne rapidement, mais il est aussi facilement imitable, avec une barrière technologique relativement basse.

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

1. Simplifier le processus de validation de dizaines de nœuds en une seule validation Oracle, ce qui réduit considérablement le coefficient de sécurité.

2. Après avoir été simplifiée en une validation unique, il faut supposer que le Relayer et l'Oracle sont indépendants l'un de l'autre. Mais cette hypothèse de confiance ne peut pas être maintenue indéfiniment, le manque de caractéristiques de décentralisation suffisantes ne permettant pas de garantir fondamentalement que les deux ne s'entendront pas pour commettre des actes malveillants.

Certaines personnes peuvent se demander si l'ouverture du Relayer, permettant à un plus grand nombre de participants d'exécuter des relais, pourrait résoudre les problèmes mentionnés ci-dessus. En réalité, augmenter simplement le nombre d'opérateurs n'est pas équivalent à la Décentralisation. Permettre à quiconque de se connecter au système ne représente qu'une réalisation sans permission, ce qui est un changement du côté du marché, sans grande relation avec la sécurité du produit lui-même. Le Relayer est essentiellement un intermédiaire chargé de transmettre des informations, tout comme les Oracles, et appartient à la catégorie des tiers de confiance. Tenter d'améliorer la sécurité cross-chain en augmentant le nombre de sujets de confiance est futile, car cela ne change pas les caractéristiques essentielles du produit et pourrait même entraîner de nouveaux problèmes.

Si un projet de jeton cross-chain permet de modifier la configuration des nœuds utilisés, un attaquant pourrait le remplacer par un nœud qu'il contrôle, ce qui lui permettrait de falsifier n'importe quel message. Ce risque de sécurité pourrait avoir des conséquences plus graves dans des scénarios plus complexes. Dans un système vaste, il suffit qu'un maillon soit remplacé pour déclencher une réaction en chaîne. Et certains protocoles cross-chain eux-mêmes n'ont pas la capacité de résoudre ce type de problème, et si un accident de sécurité se produit réellement, la responsabilité pourrait bien être attribuée aux applications externes.

Pour les projets qui se présentent comme des infrastructures, si elles ne peuvent pas offrir une sécurité partagée comme Layer 1 ou Layer 2, alors cette position de "l'infrastructure" est discutable. La véritable infrastructure est "de base" parce qu'elle peut fournir une garantie de sécurité cohérente pour l'ensemble de l'écosystème. Par conséquent, le positionnement de certains protocoles cross-chain pourrait être plus précisément celui de middleware, plutôt que d'infrastructure.

Certaines équipes de sécurité ont signalé des vulnérabilités potentielles dans certains protocoles cross-chain. Par exemple, si un acteur malveillant obtient un accès à la configuration du protocole, il pourrait modifier les oracles et les relais pour qu'ils soient contrôlés par des composants dont il a la main, trompant ainsi les contrats intelligents et entraînant le vol des actifs des utilisateurs. De plus, des recherches ont révélé que certains relais de protocole présentent des vulnérabilités critiques, bien qu'ils soient actuellement protégés par une signature multiple, ils pourraient néanmoins être exploités par des personnes internes ou des membres d'équipes identifiés.

Lors de l'évaluation des protocoles cross-chain, nous devrions revenir à l'essentiel et nous référer aux concepts fondamentaux présentés dans le livre blanc de Bitcoin. La caractéristique principale du consensus de Satoshi Nakamoto est d'éliminer les tiers de confiance, réalisant ainsi une décentralisation (Décentralisation) et une absence de confiance (Trustless). Le protocole de communication cross-chain devrait essentiellement être, comme Bitcoin, un système pair à pair, permettant à une partie d'envoyer directement de la Chaîne A à l'autre partie de la Chaîne B, sans avoir besoin de passer par un intermédiaire de confiance.

Le "consensus de Satoshi", qui présente des caractéristiques de Décentralisation et de confiance, est devenu l'objectif commun de tous les développeurs d'infrastructure ultérieurs. Les protocoles cross-chain qui ne satisfont pas à ce consensus ont du mal à être considérés comme de véritables protocoles cross-chain décentralisés, et ne devraient pas utiliser à la légère des termes avancés tels que "décentralisé" ou "sans confiance" pour décrire les caractéristiques de leurs produits.

Un véritable protocole de décentralisation cross-chain devrait être capable de générer des preuves de fraude ou de validité tout au long du processus cross-chain et de les enregistrer sur la chaîne pour vérification. Ce n'est qu'ainsi que la décentralisation et la confiance peuvent être réellement réalisées.

Pour les projets qui prétendent utiliser des technologies innovantes (comme les preuves à divulgation nulle de connaissance) pour améliorer les protocoles cross-chain, la clé réside dans leur capacité à reconnaître les problèmes qui les affectent réellement. Ce n'est qu'en faisant face à ces problèmes qu'ils pourront réellement faire progresser la technologie et construire un écosystème cross-chain plus sûr et plus décentralisé.