Discussion sur la sécurité des protocoles cross-chain : importance de la Décentralisation et de l'absence de confiance.

La sécurité des protocoles cross-chain a toujours été un point focal dans l'industrie. Ces dernières années, les événements de sécurité liés aux protocoles cross-chain ont entraîné des pertes considérables, leur importance dépassant même celle des solutions d'extension d'Ethereum. L'interopérabilité des protocoles cross-chain est une nécessité intrinsèque à la mise en réseau Web3, mais le grand public a une capacité insuffisante à identifier le niveau de sécurité de ces protocoles.

Un protocole de cross-chain bien connu a adopté une conception architecturale simplifiée. Son processus de communication est exécuté par un relais, et l'oracle supervise le relais. Cette conception évite la validation de consensus de la troisième chaîne traditionnelle, offrant aux utilisateurs une expérience de cross-chain rapide. Cependant, cette architecture présente au moins deux problèmes :

1. La simplification de la validation multi-nœuds en une seule validation d'oracle a considérablement réduit le coefficient de sécurité.
2. Supposons que le relais et l'oracle soient indépendants, cette hypothèse de confiance est difficile à établir sur le long terme, elle n'est pas suffisamment native à la cryptographie.

Ce protocole, en tant que solution "ultra légère" cross-chain, n'est responsable que du transfert de messages et ne peut pas garantir la sécurité des applications. Même en ouvrant les permissions des relais pour permettre à plus de participants de s'exécuter, cela ne résout pas fondamentalement les problèmes mentionnés ci-dessus. Augmenter le nombre d'entités de confiance ne peut pas améliorer la sécurité cross-chain, cela pourrait même soulever de nouveaux problèmes.

Si un projet de jeton cross-chain utilisant ce protocole permet de modifier les nœuds de configuration, un attaquant pourrait les remplacer par ses propres nœuds et falsifier n'importe quel message. Ce risque est plus grave dans des scénarios complexes. Le protocole lui-même a du mal à résoudre ce problème, et en cas d'incident de sécurité, la responsabilité pourrait être attribuée aux applications externes.

Ce protocole ressemble davantage à un middleware qu'à une infrastructure. L'infrastructure devrait fournir une sécurité cohérente à tous les projets écologiques, mais ce protocole ne peut pas le faire. Les développeurs d'applications qui intègrent son SDK/API peuvent personnaliser leurs politiques de sécurité, mais cela ne signifie pas qu'ils partagent la sécurité.

Une équipe de sécurité a souligné que l'hypothèse selon laquelle les propriétaires d'applications ne feraient pas le mal dans ce protocole est incorrecte. Si un acteur malveillant obtient un accès de configuration, il pourrait modifier les oracles et les relais en composants contrôlés, permettant ainsi de voler les actifs des utilisateurs. Une autre équipe a découvert deux vulnérabilités clés dans le relais de ce protocole, qui pourraient entraîner l'envoi de messages frauduleux et la modification de messages.

En revenant au livre blanc de Bitcoin, nous pouvons extraire les caractéristiques essentielles du "consensus de Satoshi Nakamoto" : la décentralisation et la désintermédiation. Un protocole de communication cross-chain devrait essentiellement être un système pair à pair, sans besoin de tiers de confiance. Les protocoles cross-chain qui ne respectent pas ce consensus peuvent être considérés comme des protocoles pseudo-décentralisés.

Ce protocole exige que les relais et les oracles ne conspirent pas pour agir malicieusement, tout en demandant aux utilisateurs de faire confiance aux développeurs d'applications utilisant ce protocole. Lors de son processus de cross-chain, aucune preuve de fraude ou de validité n'est générée, et ces preuves ne sont donc pas vérifiées sur la chaîne. Par conséquent, ce protocole ne satisfait pas à la "consensus de Satoshi" et ne peut pas être qualifié de système décentralisé et sans confiance.

Lorsqu'il fait face à des questions de sécurité, l'attitude de réponse de ce protocole est généralement de nier. Cependant, peu importe l'ampleur du financement ou la taille du trafic, si le produit ne peut pas réaliser une véritable sécurité décentralisée, il pourrait échouer en raison d'une capacité d'attaque insuffisante.

Construire un véritable protocole cross-chain décentralisé reste un défi important auquel l'industrie est confrontée. Certaines technologies émergentes, telles que les preuves à divulgation nulle de connaissance, pourraient offrir de nouvelles perspectives pour résoudre ce problème.