L'importance de la sécurité des protocoles cross-chain et les insuffisances de LayerZero

Les problèmes de sécurité des protocoles cross-chain ont suscité une attention considérable ces dernières années. En regard des pertes financières causées par les événements de sécurité survenus sur diverses 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 au premier rang. 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 une exigence intrinsèque pour connecter l'écosystème Web3. Ces protocoles reçoivent généralement d'énormes financements, et leur valeur totale verrouillée (TVL) ainsi que le nombre de transactions augmentent également sous la pression d'une demande rigide. Cependant, en raison du faible niveau de reconnaissance du grand public envers ces protocoles, il est difficile d'évaluer avec précision leur niveau de sécurité.

Voyons d'abord une architecture typique de conception de produit cross-chain. Dans le processus de communication entre la Chaîne A et la Chaîne B, des opérations concrètes sont exécutées par le Relayer, tandis que l'Oracle supervise le Relayer. L'avantage de cette architecture est qu'elle évite le processus complexe d'algorithme de consensus et de validation par plusieurs nœuds qui nécessiterait traditionnellement une troisième chaîne (qui n'est généralement pas déployée avec dApp), offrant ainsi aux utilisateurs finaux une expérience de "cross-chain rapide". Grâce à une architecture légère, à un code réduit et à la possibilité d'utiliser directement Chainlink comme Oracle, ce type de projet peut être rapidement mis en ligne, mais il est également facilement imitable, avec une barrière technique presque nulle.

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

1. La simplification du processus de validation de dizaines de nœuds en une seule validation Oracle réduit considérablement le coefficient de sécurité.

2. Une fois simplifié en une seule validation, il faut supposer que le Relayer et l'Oracle sont indépendants l'un de l'autre. Cette hypothèse de confiance est difficile à maintenir de manière permanente, ne correspond pas à la philosophie native des cryptomonnaies et ne peut pas garantir fondamentalement que les deux ne conspireront pas pour commettre des actes malveillants.

Certains protocoles cross-chain adoptent ce modèle de base. En tant que solution cross-chain "ultra-légère" de type sécurité indépendante, elles ne sont responsables que de la transmission des messages et ne sont pas responsables de la sécurité des applications, et n'ont pas la capacité d'assumer cette responsabilité.

Même si plusieurs parties sont autorisées à faire fonctionner des relais, cela ne résout pas complètement les problèmes mentionnés ci-dessus. Tout d'abord, la décentralisation ne signifie pas seulement qu'il y a plus d'opérateurs ou que tout le monde peut se connecter. La demande a toujours été sans autorisation, faire en sorte que l'offre soit également sans autorisation n'est pas une révolution, c'est juste un changement du côté du marché, ce qui n'a pas grand-chose à voir avec la sécurité du produit lui-même. Les Relayers de certains protocoles sont essentiellement des intermédiaires qui se contentent de transmettre des informations, tout comme les Oracles, ils appartiennent tous à des tiers de confiance. Essayer d'augmenter le nombre de parties de confiance de 1 à 30 pour améliorer la sécurité cross-chain est futile, cela ne change pas les caractéristiques du produit et pourrait même engendrer de nouveaux problèmes.

Si un projet de jeton cross-chain permet de modifier les nœuds de configuration, il est alors possible qu'un attaquant puisse les remplacer par ses propres nœuds, et ainsi falsifier n'importe quel message. En conséquence, les projets utilisant ce protocole peuvent toujours faire face à d'énormes problèmes de sécurité, et ce problème sera encore plus grave dans des scénarios plus complexes. Dans un grand système, il suffit qu'un maillon soit remplacé pour déclencher une réaction en chaîne. Certains protocoles cross-chain eux-mêmes n'ont pas la capacité de résoudre ce problème, et si un incident de sécurité survient réellement, ils risquent fort de rejeter la responsabilité sur des applications externes.

Si un protocole ne peut pas partager la sécurité comme Layer1 ou Layer2, alors il ne peut pas être qualifié d'infrastructure. L'infrastructure est dite "de base" parce qu'elle peut partager la sécurité. Si un projet se prétend être une infrastructure, alors il devrait fournir une sécurité cohérente à tous ses projets écologiques, c'est-à-dire que tous les projets écologiques partagent la sécurité de cette infrastructure. Par conséquent, il est exact de dire que certains protocoles cross-chain ne sont pas des infrastructures, mais plutôt des middleware. Les développeurs d'applications qui intègrent ce middleware SDK/API peuvent effectivement définir librement leurs propres politiques de sécurité.

Certain équipes de recherche ont souligné qu'il est incorrect de supposer que le propriétaire de l'application (ou la personne possédant la clé privée) n'agira pas de manière malveillante. Si un acteur malveillant obtient l'accès à la configuration du protocole cross-chain, il pourrait remplacer les oracles et les relais par des composants qu'il contrôle, manipulant ainsi les contrats intelligents utilisant ce mécanisme, ce qui peut entraîner le vol d'actifs des utilisateurs.

De plus, des études montrent que certains relais de protocole cross-chain présentent des vulnérabilités critiques. Bien qu'ils soient actuellement en état de multi-signature, ces vulnérabilités ne peuvent être exploitées que par des personnes internes ou des membres d'une équipe d'identité connue, mais il existe néanmoins des risques potentiels. Ces vulnérabilités pourraient permettre l'envoi de messages frauduleux à partir de multi-signatures, ou la modification de messages après la signature par un oracle et des messages ou transactions multi-signatures, ce qui pourrait entraîner le vol de fonds de tous les utilisateurs.

En retraçant l'origine du Bitcoin, nous pouvons voir le concept central proposé par Satoshi Nakamoto dans le livre blanc : un système de monnaie électronique entièrement peer-to-peer qui permet aux paiements en ligne d'être envoyés directement d'une partie à une autre sans passer par des institutions financières. Ce concept met en avant les caractéristiques de décentralisation et de confiance minimale, qui sont devenues l'objectif commun de tous les développeurs d'infrastructure par la suite.

Cependant, certains protocoles cross-chain exigent dans la pratique que les deux rôles Relayer et Oracle ne conspirent pas pour mal agir, tout en exigeant que les utilisateurs considèrent les développeurs d'applications utilisant ce protocole comme des tiers de confiance. Les entités de confiance participant à la "multi-signature" sont toutes des rôles privilégiés préalablement arrangés. Plus important encore, aucun preuve de fraude ou preuve de validité n'a été générée tout au long du processus cross-chain, sans parler de la mise en chaîne et de la vérification en chaîne de ces preuves. Par conséquent, ces protocoles ne répondent en réalité pas au "consensus de Satoshi Nakamoto" et ne peuvent pas être qualifiés de véritables systèmes décentralisés et sans confiance.

Face aux problèmes de sécurité, l'attitude de réponse de certains protocoles cross-chain est souvent de "nier" puis de "nier" à nouveau. Cependant, l'histoire nous dit que de nombreuses monnaies électroniques ont été tentées avant Bitcoin, 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 cross-chain : peu importe l'ampleur du financement, le volume des utilisateurs ou la "pureté" des origines, tant que le produit ne parvient pas à réaliser une véritable sécurité décentralisée, il y a de fortes chances qu'il échoue finalement en raison d'une capacité insuffisante à résister aux attaques.

Construire un véritable protocole cross-chain décentralisé est un défi complexe. Certaines solutions émergentes, telles que l'utilisation de la technologie de preuve à zéro connaissance pour améliorer les protocoles cross-chain, pourraient apporter de nouvelles percées dans ce domaine. Cependant, la clé réside dans la capacité des développeurs de protocoles à reconnaître les problèmes existants et à être disposés à prendre les mesures nécessaires pour s'améliorer.