Comparaison entre le protocole Babylon et EigenLayer
TechFlow SélectionTechFlow Sélection
Comparaison entre le protocole Babylon et EigenLayer
Étant donné que le réseau principal de Bitcoin ne prend pas en charge les contrats intelligents complets, l'architecture de Babylon ainsi que ses scénarios d'application présentent de nombreuses différences par rapport à EigenLayer.
Dédié à des analyses Web3 approfondiesRédaction : Shawn, E2M Research
Le secteur du Restaking, incarné par EigenLayer, a suscité un vif intérêt et s'impose aujourd'hui comme l'une des directions les plus prometteuses de l'écosystème Ethereum. E2M Research a d'ailleurs consacré de nombreuses analyses à EigenLayer. Ce dernier étend la sécurité d'ETH à d'autres applications sur le réseau blockchain tout en offrant aux détenteurs d'ETH ou de LST une rémunération supplémentaire.
De même, Babylon permet aux utilisateurs de Bitcoin de staker leurs BTC afin de renforcer la sécurité des réseaux PoS, d'améliorer leur robustesse et de générer des revenus, tout en conservant l'autogestion de leurs bitcoins. En raison de l'impossibilité pour la chaîne principale Bitcoin de supporter des contrats intelligents complets, l'architecture et les cas d'utilisation de Babylon diffèrent sensiblement de ceux d'EigenLayer. Anurag Arjun, ancien fondateur de Polygon et fondateur d'Avail, a déclaré sur les réseaux sociaux que Babylon était gravement sous-estimé par rapport à des projets comme Eigenlayer. Il prévoit que Babylon connaîtra soudainement une accélération significative, ce qui constituera une libération majeure pour l'écosystème BTC.
Cet article vise à comparer ces deux projets selon plusieurs angles afin d'en comprendre plus profondément similitudes et différences.
Présentation de Babylon
Babylon est un protocole de partage de la sécurité du Bitcoin. Actuellement, il comprend deux protocoles :
-
Horodatage Bitcoin : ce protocole envoie vers Bitcoin des horodatages concis et vérifiables pour n'importe quelle donnée (par exemple, des blockchains PoS)
-
Staking Bitcoin : ce protocole permet aux actifs Bitcoin d'être mis en jeu, de manière non fongible (et auto-gérée), afin de fournir une sécurité économique à tout système décentralisé.
Protocole d'horodatage Bitcoin
Voici tout d'abord le schéma structurel du protocole d'horodatage Bitcoin :
L'architecture de Babylon est illustrée ci-dessus. Elle se compose de trois parties et implique deux niveaux de points de contrôle (checkpoints) :
-
Bitcoin, agissant comme couche de service d'horodatage ;
-
La chaîne Babylon (une blockchain construite avec Cosmos SDK), servant de couche intermédiaire ;
-
Les blockchains PoS, utilisatrices de cette sécurité (par exemple, d'autres zones Cosmos).
Un aspect clé de conception tient au fait que la capacité de données supportée par Bitcoin est extrêmement limitée. Dans ce contexte, la chaîne Babylon remplit plusieurs fonctions :
-
Elle agrège les flux de points de contrôle (checkpoint streams) de nombreuses blockchains PoS consommatrices, de sorte qu’un seul flux inséré dans le réseau Bitcoin suffit à horodater simultanément tous les événements des chaînes PoS clientes.
-
Les points de contrôle insérés dans le réseau Bitcoin peuvent être rendus compacts grâce à des techniques cryptographiques (comme les signatures agrégées).
-
Elle reçoit les points de contrôle des chaînes PoS via le protocole IBC.
-
Elle vérifie la disponibilité des données des points de contrôle des chaînes PoS, empêchant ainsi un attaquant d’horodater des données indisponibles.
Cette architecture contribue à renforcer la sécurité des chaînes PoS, notamment contre les attaques longues (long-range attacks).
Pour protéger une chaîne PoS contre les attaques longues, on peut envoyer ses points de contrôle vers BTC et choisir comme branche légitime celle possédant l'horodatage BTC le plus ancien. Deux scénarios sont alors possibles :
-
La branche d'attaque aura un horodatage BTC plus récent, et ne sera donc jamais sélectionnée ;
-
Pour être choisie, l'attaquant devrait créer une longue bifurcation du réseau BTC où sa branche PoS aurait un horodatage antérieur, ce qui est économiquement irréalisable.
Ainsi, les attaques longues peuvent être neutralisées grâce à l'horodatage BTC.
Outre la protection contre les attaques longues, les horodatages BTC irréversibles des blocs PoS apportent d'autres avantages de sécurité :
-
Élimination de la subjectivité faible : l'horodatage Bitcoin est objectif, éliminant ainsi la dépendance des chaînes PoS au consensus social et à la subjectivité faible.
-
Délai de déblocage plus court : en remplaçant le consensus social, l'horodatage BTC peut réduire le délai de déblocage du staking d'une chaîne PoS de plusieurs semaines à un jour.
-
Lancement de nouvelles chaînes : les nouvelles chaînes PoS à faible valorisation sont plus vulnérables aux attaques par bifurcation. L'horodatage BTC peut aider à sécuriser leur croissance initiale.
-
Validation de la synchronisation d'état et des instantanés : les faits objectifs fournis par BTC permettent aux utilisateurs de valider l’état ou les snapshots téléchargés depuis le réseau P2P.
-
Protection des transactions importantes : l'horodatage BTC peut confirmer davantage certaines transactions PoS critiques, au prix d’un délai de confirmation accru.
-
Résistance à la censure : l'horodatage BTC permet aussi de contrecarrer la censure des transactions sur les chaînes PoS en publiant celles-ci directement sur BTC.
Protocole de staking Bitcoin
Le protocole de staking Bitcoin de Babylon permet aux détenteurs de Bitcoin de staker leurs BTC sans faire confiance à aucun tiers. Ce staking « n'exige pas » de transférer les BTC vers une chaîne PoS via pont, tout en offrant une garantie de sécurité pleinement punitible (slashable) à cette chaîne PoS.
Voici un exemple de staking Bitcoin :
Alice possède un bitcoin qu’elle souhaite staker sur une chaîne PoS. Elle commence par envoyer une transaction de mise en jeu vers la chaîne Bitcoin pour entrer dans un contrat de staking. Cette transaction bloque son bitcoin dans un coffre-fort auto-géré. Les bitcoins bloqués ne peuvent être déverrouillés qu’à l’aide de la clé privée d’Alice, selon deux méthodes :
(1) Alice lance une « transaction de déblocage (unbonding transaction) », les bitcoins seront alors débloqués et lui retournés après trois jours.
(2) Alice lance une « transaction de slashing (slashing transaction) », envoyant les bitcoins vers une adresse de destruction.
Une fois la transaction de mise en jeu confirmée sur Bitcoin, Alice peut commencer à signer des blocs avec sa clé pour valider la chaîne PoS.
Durant sa période de validation, deux scénarios sont possibles.
Premier cas : le « chemin heureux (happy path) » (figure (a)), où Alice suit honnêtement le protocole. Quand elle souhaite retirer son staking, elle envoie une transaction de déblocage sur Bitcoin (figure (b)). Une fois cette transaction confirmée, ses obligations de validation sur la chaîne PoS prennent fin. Trois jours plus tard, elle peut retirer ses bitcoins. La chaîne PoS lui verse également une récompense.
Deuxième cas : le « chemin malheureux (unhappy path) » (figure (b)), où Alice devient malveillante et participe à une double dépense sur la chaîne PoS. Le protocole de staking garantit alors que sa clé privée sera divulguée. N'importe qui peut alors utiliser cette clé pour envoyer une transaction de slashing vers Bitcoin et détruire les bitcoins d'Alice. La simple existence de ce chemin malheureux dissuade toute attaque, incitant tous les participants à suivre le « chemin heureux » — c’est-à-dire à se comporter correctement.
Pour le slashing, Babylon utilise des signatures uniques extractibles (EOTS - Extractable One-Time Signatures). L'idée centrale est qu'un utilisateur peut signer un message une seule fois, comme dans un schéma de signature classique. EOTS nécessite un paramètre d'étiquette supplémentaire (par exemple, la hauteur du bloc lors de la validation). Si un utilisateur tente de signer deux fois le même message avec la même étiquette (deux blocs à la même hauteur), sa clé privée peut être extraite à partir des deux signatures.
Comparaison
Tout d'abord, les architectures de Babylon et d'EigenLayer sont très différentes :
Babylon :
EigenLayer :
Babylon est composé du protocole d'horodatage Bitcoin et du protocole de staking. Étant donné que Bitcoin n'est pas Turing-complet, de nombreux traitements doivent être gérés par une chaîne dédiée. Ainsi, Babylon dispose de sa propre chaîne, construite avec Cosmos SDK, et possède ses propres nœuds validateurs, ainsi que des modules indépendants comme EOTS Manager et Finality Provider.
En revanche, EigenLayer repose essentiellement sur un ensemble de contrats intelligents capables d'accepter les mises en jeu des utilisateurs et de gérer les contrats AVS. Sa sécurité et son exécution reposent entièrement sur le réseau Ethereum.
Ensuite, les mécanismes de slashing diffèrent entre les deux.
Grâce aux contrats intelligents d'Ethereum, la logique de slashing d'EigenLayer est intégralement codée dans les contrats, permettant des conditions complexes adaptées à chaque AVS. En cas de situation imprévue non couverte par les règles prédéfinies, un comité hors chaîne (off-chain dispute resolution committee) intervient par vote.
Contrairement à cela, en raison des limitations fonctionnelles de Bitcoin, Babylon implémente le slashing via EOTS. Ce mécanisme impose davantage de contraintes et ne permet qu'une logique de slashing relativement simple, uniquement applicable aux cas de double signature sur le même bloc.
Cette différence dans la mise en œuvre du slashing influence directement leurs publics cibles.
EigenLayer, capable de mettre en œuvre des logiques de slashing complexes, peut fournir des services de sécurité à une large variété d'AVS. Son principal avantage réside dans sa cohérence avec Ethereum. Ce dernier possède l’écosystème le plus vaste du domaine cryptographique, impliquant plus d'utilisateurs et une demande plus importante. La solution d'EigenLayer a le potentiel de résoudre certaines limitations d'Ethereum, telles que la nécessité de ponts sécurisés et décentralisés, de solutions de disponibilité des données ou encore de couches de séquençage décentralisées pour les Layer 2. Dans l'écosystème Ethereum, l'utilisation d'ETH comme actif de staking est considérée comme « politiquement correcte ». Par conséquent, les applications développées autour d'EigenLayer serviront majoritairement l'écosystème Ethereum.
Babylon, en revanche, cible principalement les chaînes PoS, notamment celles de l’écosystème Cosmos. En effet, le service d’horodatage Bitcoin nécessite l’échange de messages entre la chaîne Babylon et les chaînes Cosmos via le protocole IBC, ce qui limite son champ d’application. Ces chaînes PoS requièrent chacune leur propre ensemble de validateurs. Toutefois, l’avantage de Babylon réside dans l’ampleur déjà atteinte par l’écosystème Cosmos, qui abrite de nombreuses chaînes PoS de qualité comme Celestia, Osmosis, Axelar ou dYdX. Tous ces protocoles peuvent facilement se connecter à Babylon pour bénéficier de la sécurité du Bitcoin. Contrairement à EigenLayer, dont le développement exige que de nombreux projets reconstruisent spécifiquement des AVS compatibles — une étape qui ralentit son démarrage —, Babylon tire parti de l’approche bien éprouvée du SDK Cosmos pour le développement d’applications, ce qui peut s’avérer plus convivial pour les développeurs. Cela constitue un avantage supplémentaire : Babylon choisit d’intégrer l’écosystème Cosmos à la sécurité du Bitcoin.
Ces différences reflètent aussi les orientations distinctes 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 développé de nombreux Layer 2, mais sans encore résoudre pleinement leur interconnexion. À l’inverse, l’écosystème Cosmos a prioritairement résolu l’interopérabilité entre différentes zones, mais manque d’un noyau de sécurité puissant. La capitalisation du Cosmos Hub étant trop faible pour assumer ce rôle, il existe un besoin naturel de trouver un tel noyau. Babylon répond précisément à ce besoin en introduisant la sécurité du BTC. Parallèlement, EigenLayer cherche à exporter la sécurité d’Ethereum vers l’écosystème Cosmos. D’un point de vue architectural, l’approche de Babylon semble mieux adaptée à l’écosystème Cosmos.
Conclusion
Babylon et EigenLayer cherchent tous deux à exploiter la sécurité de Bitcoin et d’Ethereum pour l’étendre à davantage d’applications. Toutefois, en raison du caractère non Turing-complet de Bitcoin, son écosystème est largement en retard sur celui d’Ethereum, et les voies actuelles d’émission d’actifs et de réseaux de couche 2 empruntent des chemins différents. Cela explique les divergences entre Babylon et EigenLayer en matière d’architecture technique, de mécanismes de slashing et de cibles d’utilisation. Pour l’instant, chacun occupe un créneau spécifique avec ses propres atouts. Mais avec l’évolution vers les blockchains modulaires et l’interconnexion croissante entre écosystèmes, une concurrence entre les deux pourrait émerger à l’avenir, sans qu’aucun ne domine de manière exclusive.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@E2mResearch
