Préface

La piste de Restaking représentée par EigenLayer a suscité une immense attention, devenant l'une des directions les plus chaudes dans Ethereum actuellement. E2M Research a également discuté de manière approfondie d'EigenLayer. EigenLayer étend la sécurité d'Ethereum à d'autres applications sur le réseau blockchain tout en offrant des récompenses supplémentaires aux détenteurs d'ETH ou de LST participants.

De même, Babylon permet aux utilisateurs de Bitcoin de miser du BTC pour renforcer la sécurité des réseaux PoS, améliorer la sécurité du réseau tout en gagnant des récompenses et maintenir la garde de soi du Bitcoin. Étant donné que le mainnet de Bitcoin ne peut pas prendre en charge des contrats intelligents complets, la conception architecturale de Babylon et ses scénarios d'application diffèrent considérablement de ceux d'EigenLayer. Anurag Arjun, ancien co-fondateur de Polygon et fondateur d'Avail, a également déclaré sur les réseaux sociaux que, par rapport à des projets comme Eigenlayer, Babylon semble être plus sous-estimé. Il gagnera un élan de développement, ce qui pourrait être un déverrouillage majeur pour l'écosystème BTC.

Cet article vise à fournir une compréhension plus approfondie des similitudes et des différences entre les deux projets en les comparant sous différents aspects.

Introduction à Babylone

Babylon est une suite de protocoles de partage de sécurité Bitcoin. Actuellement, elle comprend deux protocoles :

• Horodatage Bitcoin : Ce protocole envoie un horodatage succinct et vérifiable de n'importe quelle donnée (par exemple, une blockchain PoS) à Bitcoin.
• Bitcoin Staking: Ce protocole permet aux actifs Bitcoin d'être mis en jeu de manière décentralisée (et auto-garde) pour fournir une sécurité économique à tout système décentralisé.

Protocole de horodatage Bitcoin

Tout d'abord, examinons la structure du protocole de horodatage Bitcoin :

L'architecture de Babylone est représentée dans le diagramme ci-dessus. Elle se compose de trois parties, avec deux niveaux de points de contrôle:

• Bitcoin, en tant que couche de service de timestamp.
• La chaîne de Babylone (une chaîne construite sur le Cosmos SDK), est la couche intermédiaire.
• La blockchain PoS (par exemple, d'autres zones Cosmos) est le consommateur de sécurité.

Une considération importante de conception est que Bitcoin a une capacité très limitée à transporter des données. Dans ce cas, la chaîne de Babylone remplit plusieurs fonctions:

• Il agrège les flux de points de contrôle de nombreuses chaînes de consommation PoS, de sorte qu'un seul flux de points de contrôle doit être inséré dans le réseau Bitcoin pour horodater les événements sur toutes les chaînes de consommation PoS.
• Ses points de contrôle dans le réseau Bitcoin peuvent être rendus compacts en utilisant des techniques cryptographiques (par exemple, des signatures agrégées).
• Il reçoit des points de contrôle des chaînes PoS de consommateurs via le protocole IBC.
• Il vérifie la disponibilité des données des checkpoints des chaînes de consommateurs PoS, de sorte que les attaquants ne puissent pas dater des données non disponibles.

Cette structure aide les chaînes PoS à améliorer leur sécurité, par exemple, contre les attaques à longue portée.

Pour protéger une chaîne PoS contre les attaques à longue portée, nous pouvons envoyer les checkpoints de bloc de la chaîne PoS à BTC et choisir la fourchette avec un timestamp BTC antérieur comme fourchette valide. Cela ne laisse que deux possibilités :

• La fourchette attaquante aura un horodatage ultérieur dans le réseau principal BTC, auquel cas la fourchette ne sera jamais choisie par personne.
• Pour être choisi, l'attaquant doit créer une fourchette BTC très longue où la fourchette PoS attaquante a un horodatage antérieur, ce qui est économiquement impossible.

Ainsi, les attaques à longue portée peuvent être atténuées grâce aux horodatages BTC.

En plus de répondre aux attaques à longue portée, l'horodatage BTC irréversible des blocs PoS offre d'autres avantages en matière de sécurité pour les chaînes PoS:

• Éliminer la subjectivité faible : les horodatages Bitcoin sont objectifs, éliminant la dépendance des chaînes PoS sur le consensus social et la subjectivité faible.
• Durées de déliaison plus courtes: En remplaçant le consensus social, les horodatages BTC peuvent raccourcir les délais de déliaison des chaînes PoS de semaines à un jour.
• Nouveau démarrage de la chaîne : les nouvelles chaînes PoS de faible valeur sont plus vulnérables aux attaques de fork. Les horodatages BTC peuvent aider à protéger la croissance de la chaîne.
• Synchronisation d'état et vérification de l'instantané : Les faits objectifs concernant une chaîne PoS fournis par BTC permettent aux utilisateurs de la chaîne PoS de vérifier l'état de la chaîne ou les instantanés téléchargés depuis le réseau P2P.
• Sécuriser les transactions importantes : les horodatages BTC peuvent être utilisés pour confirmer davantage les transactions PoS importantes, au prix d'une latence de confirmation plus longue.
• Résistance à la censure : les horodatages BTC peuvent également résister à la censure des transactions sur les chaînes PoS en publiant des transactions censurées sur le BTC.

Protocole de mise en jeu de Bitcoin

Le protocole de jalonnement de Bitcoin de Babylon permet aux détenteurs de Bitcoin de mettre en jeu leurs Bitcoins sans avoir à faire confiance à un tiers ; ce jalonnement ne nécessite pas de pont entre les chaînes pour offrir des garanties complètes de jalonnement pouvant être annulées pour cette chaîne de PoS.

Voici un exemple de mise en jeu de Bitcoin :

Alice a un Bitcoin et elle veut le mettre en jeu sur une chaîne PoS. Tout d'abord, elle conclut un accord de mise en jeu en envoyant une transaction de mise en jeu à la chaîne Bitcoin. Cette transaction est une transaction Bitcoin qui verrouille son Bitcoin dans un coffre-fort auto-custodial. Le Bitcoin verrouillé ne peut être déverrouillé que par la clé privée d'Alice par l'un des deux chemins suivants:

(1) Alice initie une “transaction de déliaison”, auquel cas le Bitcoin sera déverrouillé et retourné à Alice dans les trois jours.

(2) Alice initie une "transaction de pénalisation", envoyant le Bitcoin à une adresse de destruction.

Une fois que cette transaction de mise en jeu entre dans la chaîne Bitcoin, Alice peut commencer à signer des blocs avec sa clé pour valider la chaîne PoS.

Pendant son devoir de vérification, il existe deux chemins possibles.

Source: https://docs.babylonchain.io/papers/btc_staking_litepaper(CN).pdf

Le "chemin heureux" (figure (a)) est là où Alice suit honnêtement le protocole, et quand elle souhaite retirer ses Bitcoins, elle initie une demande de déliaison en envoyant une transaction de déliaison à la chaîne Bitcoin (figure (b)). Une fois que la transaction de déliaison entre dans la chaîne Bitcoin, le devoir de validation d'Alice sur la chaîne PoS se termine, et après trois jours, Alice peut retirer et récupérer ses Bitcoins. La chaîne PoS récompensera également Alice avec des récompenses.

Le « chemin malheureux » (figure (b)) est là où Alice devient malveillante et participe à une attaque de double dépense sur la chaîne PoS. Dans ce cas, le contrat de mise en jeu garantit que la clé privée d'Alice sera divulguée. Ensuite, n'importe qui peut envoyer une transaction de réduction à la chaîne Bitcoin en tant qu'Alice et brûler ses Bitcoins. L'existence de ce chemin malheureux garantit qu'un attaquant sera réduit, ce qui dissuade tout le monde de mal se comporter - tout le monde se comporte normalement sur le « chemin heureux ».

Pour la réduction des mauvais comportements, Babylon utilise des signatures à extraction unique (EOTS). L'idée principale est qu'un utilisateur peut signer un message une fois, similaire à un schéma de signature normal. EOTS nécessite un paramètre d'étiquette supplémentaire (la hauteur du bloc est le paramètre supplémentaire lors de la signature d'un bloc pendant la validation). Si l'utilisateur tente de signer le même message deux fois avec la même étiquette (en signant deux blocs à la même hauteur), la clé privée de l'utilisateur peut être extraite de ces deux signatures.

Comparaison

Tout d'abord, il existe une différence structurelle significative entre le protocole Babylon et EigenLayer :

Babylone :

Diagramme de structure du protocole Babylon

EigenLayer :

Diagramme de structure EigenLayer

Babylon se compose du protocole Bitcoin Timestamp et du protocole de mise en jeu, et comme Bitcoin n'est pas Turing-complet, une grande partie du travail de traitement doit être effectuée par une chaîne séparée, c'est pourquoi le protocole Babylon a sa propre chaîne construite sur le Cosmos SDK, avec son propre ensemble de nœuds de validation correspondants. Il comprend également des composants indépendants tels que le gestionnaire EOTS et le fournisseur de finalité.

En revanche, EigenLayer est essentiellement un ensemble de contrats intelligents qui peuvent accepter des enjeux d'utilisateurs et gérer des contrats AVS, le réseau Ethereum sous-jacent exécutant et assurant la sécurité.

Deuxièmement, les deux protocoles diffèrent dans leur mise en œuvre du slashing.

Étant donné qu'Ethereum prend en charge la fonctionnalité des contrats intelligents, la logique de réduction d'EigenLayer est mise en œuvre dans les contrats, ce qui permet des conditions de réduction plus complexes adaptées à différents AVSs. Pendant ce temps, si une situation survient qui ne peut être résolue par les conditions de réduction prédéfinies, il y aura un comité de veto hors chaîne pour la résoudre par un vote.

Contrainte par la fonctionnalité du mainnet Bitcoin, Babylon met en œuvre la logique de réduction via EOTS. Il présente plus de limitations et ne peut mettre en œuvre qu'une logique de réduction relativement simple pour le cas de la signature de la même hauteur de bloc de manière répétée.

En raison des mises en œuvre de slashing différentes, les deux protocoles diffèrent également dans leurs services cibles.

La capacité d’EigenLayer à mettre en œuvre une logique de slashing complexe lui permet de fournir des services de sécurité pour un large éventail d’AVS. Pour EigenLayer, son avantage réside dans sa cohérence avec Ethereum. Ethereum possède le plus grand écosystème dans l’espace des crypto-monnaies, ce qui signifie plus d’utilisateurs et une plus grande demande. La solution d’EigenLayer a le potentiel de répondre aux limites d’Ethereum, telles que le besoin de ponts sécurisés et décentralisés, de solutions de disponibilité des données et de couches de séquenceur décentralisées pour les solutions de couche 2. Au sein de l’écosystème Ethereum, l’utilisation de l’ETH comme actif de jalonnement est considérée comme l’approche « politiquement correcte ». Ainsi, les applications construites autour d’EigenLayer serviront principalement l’écosystème Ethereum.

D'autre part, Babylon sert principalement les chaînes PoS, en particulier celles de l'écosystème Cosmos, car le service de timestamp Bitcoin doit transmettre des messages entre la chaîne Babylon et les chaînes Cosmos via le protocole IBC, ce qui limite son applicabilité. Toutes ces chaînes PoS nécessitent leurs propres ensembles distincts de nœuds de validation. Son avantage pourrait être que l'écosystème Cosmos a déjà atteint une échelle considérable et a produit de nombreuses excellentes chaînes PoS, telles que Celestia, Osmosis, Axelar, dYdX, et plus encore, qui peuvent toutes s'intégrer facilement avec la chaîne Babylon et bénéficier de la sécurité de Bitcoin. En revanche, le développement d'EigenLayer nécessiterait un nombre important de projets pour être re-développés et adaptés aux AVSs, le plaçant ainsi dans une situation initiale de désavantage. De plus, l'approche de construction de chaînes d'application en utilisant le SDK Cosmos a été largement validée et pourrait être plus conviviale pour les développeurs, donnant ainsi un avantage à Babylon en termes d'intégration de l'écosystème Cosmos sous l'ombrelle de sécurité de Bitcoin.

Cela est également lié aux orientations de développement des écosystèmes Ethereum et Cosmos. L'écosystème Ethereum a d'abord construit un noyau de sécurité massif, le réseau principal Ethereum, puis a formé de nombreuses solutions de couche 2 par-dessus, mais l'interopérabilité entre les couches 2 reste à résoudre. En revanche, l'écosystème Cosmos a d'abord abordé l'interopérabilité entre différentes zones mais manque d'un noyau de sécurité puissant, car la capitalisation boursière du Cosmos Hub est trop faible pour assumer cette responsabilité. Par conséquent, il est nécessaire de trouver naturellement un noyau de sécurité, c'est là qu'intervient Babylon, visant à apporter la sécurité du Bitcoin dans l'écosystème. En même temps, EigenLayer espère également apporter la sécurité d'Ethereum dans l'écosystème Cosmos par le biais de la collaboration. D'un point de vue architectural, l'approche de Babylon pourrait être mieux adaptée à l'écosystème Cosmos.

Résumé

Les deux protocoles Babylon et EigenLayer visent à débloquer la sécurité des réseaux Bitcoin et Ethereum respectivement pour plus d'applications. Cependant, en raison de la nature non Turing-complète de Bitcoin, le développement de son écosystème est loin derrière celui d'Ethereum. De plus, l'émission d'actifs de Bitcoin et les réseaux de couche 2 ont pris un chemin différent de celui d'Ethereum. Cela a entraîné des différences entre le protocole Babylon et EigenLayer en termes d'architecture technique, de mécanismes de réduction et de services cibles. Actuellement, les deux protocoles ont leurs domaines de concentration, chacun avec ses avantages. Cependant, à mesure que les blockchains modulaires et l'interconnectivité entre les différents écosystèmes se développent, les deux protocoles pourraient éventuellement entrer en concurrence, sans qu'un acteur dominant unique ne se dégage.

Articles de référence

https://twitter.com/E2mResearch/status/1783714279394586787 https://mirror.xyz/0x80894DE3D9110De7fd55885C83DeB3622503D13B/H6Atmt82NYjR5OgKN664IaTZJuR5hyfaRavvEHXoVvg https://pmcrypto.xyz/blog/wtf-is-eigenlayer-and-babylon-cn https://docs.eigenlayer.xyz/eigenlayer https://docs.babylonchain.io/docs/introduction/overview https://www.chaincatcher.com/article/2079486

Avertissement :

1. Cet article est republié à partir de [E2M Research] , with the copyright belonging to the original author [ShawnYang]. If there are any objections to the republication, please contact the Gate Learn Équipe, et ils s'en occuperont selon les procédures pertinentes.

2. Avertissement : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.

3. Les versions traduites de cet article par l'équipe Gate Learn ne peuvent être copiées, diffusées ou plagiées sans mentionner Gate.io.