Défis de sécurité des protocoles cross-chain et limitations de LayerZero
Dans l'écosystème Web3, l'importance des protocoles cross-chain devient de plus en plus évidente. Cependant, les événements de sécurité survenus ces dernières années montrent que ces protocoles présentent des risques potentiels énormes. En fait, les pertes causées par les protocoles cross-chain figurent parmi les plus importantes dans divers incidents de sécurité blockchain, et leur importance dépasse même celle des solutions d'extension d'Ethereum.
Certains protocoles cross-chain adoptent un design apparemment simple, mais cela ne signifie pas qu'ils constituent des solutions excellentes ou sécurisées. Prenons l'exemple d'un protocole cross-chain bien connu, dont l'architecture est simple, mais présente des vulnérabilités de sécurité évidentes.
L'architecture de base de ce protocole est la suivante : la communication entre la Chaîne A et la Chaîne B est effectuée par un Relayer, tandis qu'un Oracle supervise le Relayer. Bien que ce design évite le processus complexe de consensus nécessitant une troisième chaîne, offrant aux utilisateurs une expérience rapide de cross-chain, il entraîne également des risques de sécurité graves.
Tout d'abord, la simplification de la validation multi-nœuds à une validation Oracle unique réduit considérablement le niveau de sécurité. Ensuite, cette conception doit supposer que le Relayer et l'Oracle sont complètement indépendants, une hypothèse qui est difficile à garantir de manière permanente dans la réalité, ce qui présente un risque de collusion malveillante.
Certaines personnes pourraient penser qu'en augmentant le nombre de Relayer, on peut améliorer la sécurité. Cependant, cette approche ne résout pas fondamentalement le problème. Augmenter le nombre de participants n'est pas équivalent à la décentralisation et ne peut pas changer les caractéristiques essentielles du produit.
Plus important encore, si un projet utilisant ce protocole permet la modification des nœuds de configuration, un attaquant pourrait potentiellement les remplacer par des nœuds sous son contrôle, permettant ainsi de falsifier des messages. Ce risque serait encore plus grave dans des scénarios complexes, et le protocole lui-même n'a pas la capacité de résoudre ce problème.
Certaines équipes de recherche en sécurité ont souligné les vulnérabilités potentielles de ce protocole. Par exemple, si le propriétaire de l'application ou le détenteur de la clé privée agit de manière malveillante, cela pourrait entraîner le vol des actifs des utilisateurs. D'autres recherches ont révélé que les relais de ce protocole présentent des vulnérabilités critiques qui pourraient être exploitées par des personnes internes ou des membres d'équipe dont l'identité est connue.
Un véritable protocole de cross-chain décentralisé doit suivre le principe fondamental du "consensus de Satoshi Nakamoto", à savoir éliminer les tiers de confiance, réalisant ainsi une véritable décentralisation et détrustification. Cependant, certains protocoles de cross-chain qui se disent décentralisés ne respectent en réalité pas ces normes. Ils peuvent exiger que les utilisateurs fassent confiance à plusieurs acteurs pour ne pas conspirer pour nuire, ou considérer les développeurs d'applications comme un tiers de confiance.
Construire un véritable protocole cross-chain décentralisé est une tâche ardue. Cela nécessite non seulement d'éviter l'introduction de tiers de confiance dans la conception, mais doit également être capable de générer des preuves de fraude ou des preuves de validité, et de les mettre sur la chaîne pour vérification. Ce n'est qu'ainsi que l'on pourra réellement parvenir à une décentralisation et à une détrustification.
Lors de l'évaluation des protocoles cross-chain, nous ne devrions pas nous laisser tromper par un design de surface épuré ou des financements énormes. De véritables solutions cross-chain sécurisées et décentralisées nécessitent des efforts supplémentaires en matière de conception et de mise en œuvre technique, et peuvent nécessiter l'utilisation de technologies avancées telles que les preuves à connaissance nulle pour améliorer la sécurité et le degré de décentralisation.
À l'avenir, seuls les protocoles capables de réaliser une véritable sécurité décentralisée pourront se démarquer dans une concurrence féroce et fournir une infrastructure cross-chain fiable pour l'écosystème Web3.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
12 J'aime
Récompense
12
6
Partager
Commentaire
0/400
DefiVeteran
· Il y a 14h
layer0 ne fonctionne pas, le cross-chain m'étouffe...
Voir l'originalRépondre0
ForumMiningMaster
· Il y a 14h
On est arrivé et c'est déjà une chute, c'est vraiment une perte.
Voir l'originalRépondre0
ZenMiner
· Il y a 14h
Simple ≠ sûr, j'ai vu tant de tragédies.
Voir l'originalRépondre0
wrekt_but_learning
· Il y a 14h
J'ai toujours pensé que LayerZero n'était pas fiable... j'attendais juste d'être pris au piège.
Voir l'originalRépondre0
PrivacyMaximalist
· Il y a 14h
Le risque de cross-chain est vraiment trop grand, qui ose meurt.
Voir l'originalRépondre0
AirdropGrandpa
· Il y a 14h
Rendre les choses simples n'est pas toujours bon. Cette casserole doit être portée pendant des années.
Les problèmes de sécurité de LayerZero et les défis de décentralisation des protocoles cross-chain
Défis de sécurité des protocoles cross-chain et limitations de LayerZero
Dans l'écosystème Web3, l'importance des protocoles cross-chain devient de plus en plus évidente. Cependant, les événements de sécurité survenus ces dernières années montrent que ces protocoles présentent des risques potentiels énormes. En fait, les pertes causées par les protocoles cross-chain figurent parmi les plus importantes dans divers incidents de sécurité blockchain, et leur importance dépasse même celle des solutions d'extension d'Ethereum.
Certains protocoles cross-chain adoptent un design apparemment simple, mais cela ne signifie pas qu'ils constituent des solutions excellentes ou sécurisées. Prenons l'exemple d'un protocole cross-chain bien connu, dont l'architecture est simple, mais présente des vulnérabilités de sécurité évidentes.
L'architecture de base de ce protocole est la suivante : la communication entre la Chaîne A et la Chaîne B est effectuée par un Relayer, tandis qu'un Oracle supervise le Relayer. Bien que ce design évite le processus complexe de consensus nécessitant une troisième chaîne, offrant aux utilisateurs une expérience rapide de cross-chain, il entraîne également des risques de sécurité graves.
Tout d'abord, la simplification de la validation multi-nœuds à une validation Oracle unique réduit considérablement le niveau de sécurité. Ensuite, cette conception doit supposer que le Relayer et l'Oracle sont complètement indépendants, une hypothèse qui est difficile à garantir de manière permanente dans la réalité, ce qui présente un risque de collusion malveillante.
Certaines personnes pourraient penser qu'en augmentant le nombre de Relayer, on peut améliorer la sécurité. Cependant, cette approche ne résout pas fondamentalement le problème. Augmenter le nombre de participants n'est pas équivalent à la décentralisation et ne peut pas changer les caractéristiques essentielles du produit.
Plus important encore, si un projet utilisant ce protocole permet la modification des nœuds de configuration, un attaquant pourrait potentiellement les remplacer par des nœuds sous son contrôle, permettant ainsi de falsifier des messages. Ce risque serait encore plus grave dans des scénarios complexes, et le protocole lui-même n'a pas la capacité de résoudre ce problème.
Certaines équipes de recherche en sécurité ont souligné les vulnérabilités potentielles de ce protocole. Par exemple, si le propriétaire de l'application ou le détenteur de la clé privée agit de manière malveillante, cela pourrait entraîner le vol des actifs des utilisateurs. D'autres recherches ont révélé que les relais de ce protocole présentent des vulnérabilités critiques qui pourraient être exploitées par des personnes internes ou des membres d'équipe dont l'identité est connue.
Un véritable protocole de cross-chain décentralisé doit suivre le principe fondamental du "consensus de Satoshi Nakamoto", à savoir éliminer les tiers de confiance, réalisant ainsi une véritable décentralisation et détrustification. Cependant, certains protocoles de cross-chain qui se disent décentralisés ne respectent en réalité pas ces normes. Ils peuvent exiger que les utilisateurs fassent confiance à plusieurs acteurs pour ne pas conspirer pour nuire, ou considérer les développeurs d'applications comme un tiers de confiance.
Construire un véritable protocole cross-chain décentralisé est une tâche ardue. Cela nécessite non seulement d'éviter l'introduction de tiers de confiance dans la conception, mais doit également être capable de générer des preuves de fraude ou des preuves de validité, et de les mettre sur la chaîne pour vérification. Ce n'est qu'ainsi que l'on pourra réellement parvenir à une décentralisation et à une détrustification.
Lors de l'évaluation des protocoles cross-chain, nous ne devrions pas nous laisser tromper par un design de surface épuré ou des financements énormes. De véritables solutions cross-chain sécurisées et décentralisées nécessitent des efforts supplémentaires en matière de conception et de mise en œuvre technique, et peuvent nécessiter l'utilisation de technologies avancées telles que les preuves à connaissance nulle pour améliorer la sécurité et le degré de décentralisation.
À l'avenir, seuls les protocoles capables de réaliser une véritable sécurité décentralisée pourront se démarquer dans une concurrence féroce et fournir une infrastructure cross-chain fiable pour l'écosystème Web3.