Avant-propos

À l’ère des blockchain modulaire dirigées par Ethereum, la fourniture de services de sécurité par l’intégration de la couche de disponibilité des données (DA) n’est pas plus long un concept nouveau. À l’heure actuelle, le concept de sécurité partagée introduit par le jalonnement offre une nouvelle dimension à l’espace modulaire. Il exploite le potentiel de « l’or et de l’argent numériques » pour fournir une sécurité de Bitcoin ou Ethereum à de nombreux protocoles blockchain et chaînes publiques. Ce récit est assez grandiose, car il débloque non seulement la liquidité d’actifs d’une valeur de plusieurs milliers de milliards de dollars, mais sert également d’élément clé dans les futures solutions de mise à l’échelle. Par exemple, les récentes levées de fonds massives de 70 millions de dollars par le protocole de jalonnement Bitcoin Babylon et de 100 millions de dollars par le protocole de rejalonnement Ethereum EigenLayer illustrent le fort soutien des sociétés de capital-risque leaders pour ce secteur.

Cependant, ces développements ont également soulevé d’importantes préoccupations. Si la modularité est la solution ultime pour la mise à l’échelle, et ces protocoles sont des composants cruciaux de cette solution, ils sont susceptibles de verrouiller des quantités massives de BTC et d’ETH. Cela remet en question la sécurité des protocoles eux-mêmes. La stratification complexe formée par de nombreux protocoles LSD (Liquid Staking Produits dérivés) et LRT (Layer 2 Rollup Tokens) deviendra-t-elle le plus grand cygne noir de l’avenir de la blockchain ? Leur logique commerciale est-elle solide ? Étant donné que nous avons déjà analysé EigenLayer dans nos articles précédents, la discussion suivante se concentrera principalement sur Babylon pour résoudre ces problèmes.

Extension de la sécurité Consensus

Bitcoin et Ethereum sont indéniablement les blockchains publiques les plus précieuses aujourd’hui. Leur sécurité, leur décentralisation et leur consensus de valeur, accumulés au fil des ans, sont les principales raisons pour lesquelles ils restent au sommet du monde de la blockchain. Ce sont des qualités rares que d’autres chaînes hétérogènes ont du mal à reproduire. L’idée centrale de la modularité est de « louer » ces qualités à ceux qui en ont besoin. Dans l’approche actuelle de la modularité, il existe deux factions principales :

La première faction utilise une couche 1 suffisamment sécurisée (généralement Ethereum) comme les trois couches inférieures ou une partie des couches fonctionnelles pour les Rollups. Cette solution offre le plus haut niveau de sécurité et de légitimité et peut absorber les ressources de l’écosystème de la chaîne principale. Cependant, il peut ne pas être particulièrement convivial en termes de débit et de coût pour des cumuls spécifiques (chaînes d’application, chaînes longues, etc.).

La deuxième faction vise à créer une existence proche de la sécurité de Bitcoin et Ethereum mais avec de meilleures performances en termes de coûts, comme Celestia. Celestia y parvient en utilisant une architecture de fonction DA pure, en minimisant les exigences matérielles des nœuds et en réduisant les coûts de gas. Cette approche simplifiée vise à créer une couche DA qui correspond à la sécurité et à la décentralisation d’Ethereum tout en offrant de solides performances dans les plus brefs délais. L’inconvénient de cette approche est que sa sécurité et sa décentralisation ont encore besoin d’un certain temps pour être pleinement développées, et qu’elle manque de légitimité tout en étant en concurrence directe avec Ethereum, leading au rejet par la communauté Ethereum.

Un troisième type dans cette faction comprend Babylon et EigenLayer. Ils utilisent le concept de base de Proof-of-Stake (POS) en tirant parti de la valeur des actifs de Bitcoin ou Ethereum pour créer des services de sécurité partagés. Par rapport aux deux premiers types, il s’agit d’une existence plus neutre. Son avantage réside dans le fait qu’il hérite de la légitimité et de la sécurité, tout en apportant une plus grande valeur d’utilité aux actifs de la chaîne principale et en offrant une plus grande flexibilité.

Potentiel de l’or numérique

Quelle que soit la logique sous-jacente de tout mécanisme de consensus, la sécurité d’une blockchain dépend en grande partie des ressources qui la soutiennent. Les chaînes PoW nécessitent du matériel et de l’électricité massifs, tandis que le PoS repose sur la valeur des actifs jalonnés. Bitcoin lui-même est soutenu par un réseau PoW extrêmement vaste, ce qui en fait la présence la plus sécurisée de tout l’espace blockchain. Cependant, en tant que chaîne publique avec une valeur marchande en circulation de 1,39 billion de dollars, représentant la moitié du marché de la blockchain, son utilité d’actif est principalement limitée aux transferts et aux paiements de gas.

Pour l’autre moitié du monde de la blockchain, en particulier après la transition d’Ethereum vers PoS suite à la mise à niveau de Shanghai, on peut dire que la plupart des chaînes publiques utilisent différentes architectures PoS pour parvenir à un consensus par défaut. Cependant, les nouvelles chaînes hétérogènes ne peuvent souvent pas attirer de participations substantielles, ce qui jette le doute sur leur sécurité. Dans l’ère modulaire actuelle, les zones Cosmos et diverses solutions Layer 2 peuvent utiliser diverses couches DA pour compenser, mais cela se fait souvent au détriment de l’autonomie. Pour la plupart des anciens mécanismes PoS ou chaînes de consortium, l’utilisation d’Ethereum ou de Celestia comme couche DA est également généralement peu pratique. La valeur de Babylon réside dans le fait de combler cette lacune en utilisant le jalonnement BTC pour protéger les chaînes PoS. Tout comme l’humanité a utilisé l’or pour soutenir la valeur de la monnaie papier, BTC est bien adapté pour jouer ce rôle dans le monde de la blockchain.

De 0 à 1

Libérer « l’or numérique » a toujours été le récit le plus ambitieux mais le plus difficile à réaliser dans l’espace blockchain. Qu’il s’agisse des premiers sidechains, du Lightning Network, des jetons enveloppés de bridge ou des runes et des BTC Layer 2 d’aujourd’hui, chaque solution a ses défauts inhérents. Si Babylon vise à exploiter la sécurité de Bitcoin, les solutions centralisées qui introduisent des hypothèses de confiance tierces doivent d’abord être exclues. Parmi les options restantes, Runes et Lightning Network (limités par des progrès de développement extrêmement lents) n’ont actuellement que la capacité d’émission d’actifs. Cela signifie que Babylon doit concevoir sa propre « scaling solution » pour permettre le jalonnement Bitcoin natif de 0 à 1.

En décomposant les éléments de base actuellement utilisables par Bitcoin, il y a essentiellement les suivants : 1. Modèle UTXO, 2. Horodatages, 3. Diverses méthodes de signature, 4. Opcodes de base. Compte tenu de la programmabilité limitée de Bitcoin et de sa capacité à supporter des données, la solution de Babylon est basée sur le principe du minimalisme. Sur Bitcoin, seules les fonctions essentielles pour les contrats de jalonnement doivent être remplies, ce qui signifie que le jalonnement, le slashing, les récompenses et la récupération de BTC sont tous gérés sur la chaîne principale. Une fois ce 0 à 1 atteint, des demandes plus complexes peuvent être traitées par la zone Cosmos. Cependant, une question critique demeure : comment enregistrer les données de la chaîne PoS sur la chaîne principale ?

Remote Staking

UTXO (Unspent Transaction Outputs) est le modèle de transaction conçu par Satoshi Nakamoto pour Bitcoin. L’idée de base est extrêmement simple : les transactions ne sont que des entrées et des sorties de fonds, de sorte que l’ensemble du système de transaction peut être exprimé en termes d’entrées et de sorties. UTXO représente la partie des fonds qui entrent mais ne sont pas entièrement dépensés, restant ainsi en tant que sorties de transaction non dépensées (c’est-à-dire Bitcoin non payé). L’ensemble du registre Bitcoin est essentiellement une collection d’UTXO, enregistrant l’état de chaque UTXO pour gérer la propriété et la circulation de Bitcoin. Chaque transaction dépense d’anciens UTXO et en génère de nouveaux. En raison de son potentiel inhérent d’évolutivité, UTXO est naturellement devenu le point de départ de nombreuses solutions de mise à l’échelle natives. Par exemple, l’utilisation d’UTXO et de multisig pour créer des mécanismes de pénalité et des canaux d’état pour le Lightning Network, ou la liaison d’UTXO pour mettre en œuvre des jetons semi-fongibles (SFT) comme les inscriptions et les runes, tout cela découle de ce point de départ crucial.

Babylon doit également tirer parti d’UTXO pour mettre en œuvre des contrats de jalonnement (appelé jalonnement à distance par Babylon, où la sécurité de Bitcoin est transmise à distance aux chaînes PoS via une couche intermédiaire). La mise en œuvre du contrat peut être décomposée en quatre étapes, en combinant astucieusement les opcodes existants :

Blocage des fonds

Les utilisateurs envoient des fonds à une adresse contrôlée par multisig. Grâce à OP_CTV (OP_CHECKTEMPLATEVERIFY, qui permet de créer des modèles de transaction prédéfinis garantissant que les transactions ne peuvent être exécutées que selon des structures et des conditions spécifiques), le contrat peut spécifier que ces fonds ne peuvent être dépensés que sous certaines conditions. Une fois les fonds bloqués, un nouvel UTXO est généré, indiquant que ces fonds ont été jalonnés.

Vérification de l’état

En appelant OP_CSV (OP_CHECKSEQUENCEVERIFY, qui permet de définir un verrou temporel relatif basé sur le numéro de séquence de la transaction, indiquant que l’UTXO ne peut être dépensé qu’après un certain temps relatif ou nombre de blocs), des verrous temporels peuvent être implémentés. Combiné avec OP_CTV, cela peut réaliser le jalonnement, le déjalonnement (permettant au staker de dépenser l’UTXO verrouillé une fois la période de jalonnement terminée) et le slashing (forcer la dépense d’UTXO vers une adresse verrouillée si le staker agit de manière malveillante, le rendant non dépensable, similaire à une adresse de trou noir).

Mises à jour de l’état

Chaque fois que les utilisateurs misent ou retirent des fonds stakés, cela implique de créer et de dépenser des UTXO. Les nouvelles sorties de transaction génèrent de nouveaux UTXO, et les anciens UTXO sont marqués comme dépensés. De cette façon, chaque transaction et mouvement de fonds est enregistré avec précision sur la blockchain, ce qui garantit la transparence et la sécurité.

Distribution des récompenses

En fonction du montant misé et de la durée du staking, le contrat calcule les récompenses et les distribue en générant de nouveaux UTXO. Ces récompenses peuvent être débloquées et dépensées via des conditions de script une fois que des critères spécifiques sont remplis.

Horodatages

Après avoir établi un contrat de jalonnement natif, il est naturel de se poser la question de l’enregistrement d’événements historiques provenant de chaînes externes. Dans le livre blanc de Satoshi Nakamoto, la blockchain Bitcoin a introduit un concept d’horodatage pris en charge par PoW, fournissant un ordre chronologique irréversible pour les événements. Dans le cas d’utilisation natif de Bitcoin, ces événements font référence à diverses transactions exécutées sur le registre. Aujourd’hui, pour améliorer la sécurité d’autres chaînes PoS, Bitcoin peut également être utilisé pour horodater des événements sur des blockchains externes. Chaque fois qu’un tel événement se produit, il déclenche une transaction envoyée aux mineurs, qui l’insèrent ensuite dans le registre Bitcoin, ajoutant ainsi un horodatage à l’événement. Ces horodatages permettent de résoudre divers problèmes de sécurité des blockchains. Le concept général d’ajout d’horodatages aux événements dans les chaînes enfants de la chaîne parente est connu sous le nom de « point de contrôle », et les transactions utilisées pour ajouter des horodatages sont appelées transactions de point de contrôle. Plus précisément, les horodatages dans la blockchain Bitcoin présentent les caractéristiques importantes suivantes :

• Format de l’heure : les horodatages enregistrent le nombre de secondes écoulées depuis le 1er janvier 1970 à 00:00:00 UTC, un format connu sous le nom d’heure Unix ou d’heure POSIX.
• Objectif : L’objectif principal d’un horodatage est de marquer l’heure de génération des blocs, d’aider les nœuds à déterminer l’ordre des blocs et d’aider au mécanisme d’ajustement de la difficulté du réseau.
• Horodatage et ajustement de la difficulté : Le réseau Bitcoin ajuste la difficulté de minage environ toutes les deux semaines, ou tous les blocs de 2016. Les horodatages jouent un rôle crucial dans ce processus, car le réseau ajuste la difficulté en fonction du temps de génération total des blocs 2016 les plus récents pour s’assurer que de nouveaux blocs sont générés environ toutes les 10 minutes.
• Vérification de validité : lorsqu’un nœud reçoit un nouveau bloc, il vérifie l’horodatage. L’horodatage d’un nouveau bloc doit être supérieur à l’heure médiane de plusieurs blocs précédents et ne doit pas dépasser l’heure du réseau de plus de 120 minutes (2 heures dans le futur).

Le serveur d’horodatage est une nouvelle primitive définie par Babylon, qui peut allouer des horodatages Bitcoin via des points de contrôle Babylon dans des blocs PoS, garantissant la précision et l’immuabilité de la séquence temporelle. Ce serveur agit comme la couche supérieure de l’ensemble de l’architecture de Babylon, servant de source centrale de confiance.

L’architecture à trois couches de Babylon

Comme illustré dans le diagramme, l’architecture globale de Babylon peut être divisée en trois couches : Bitcoin (servant de serveur d’horodatage), Babylon (une zone Cosmos agissant comme couche intermédiaire) et les chaînes de PoS en tant que couche de demande. Babylon se réfère à ces deux derniers comme le plan de contrôle (Babylone lui-même) et le plan de données (diverses chaînes de consommation PoS).

Après avoir compris la mise en œuvre de base sans confiance du protocole, examinons comment Babylone elle-même connecte les deux extrémités en utilisant la zone Cosmos. Selon l’explication détaillée du Tse Lab de Stanford sur Babylon, Babylon peut recevoir des flux de points de contrôle de plusieurs chaînes PoS et fusionner ces points de contrôle pour les publier sur Bitcoin. En utilisant des signatures agrégées des validateurs Babylon, la taille des points de contrôle peut être minimisée et la fréquence de ces points de contrôle est contrôlée en permettant aux validateurs Babylon de ne changer qu’une fois par époque.

Les validateurs de diverses chaînes PoS téléchargent des blocs Babylon pour vérifier si leurs points de contrôle PoS sont inclus dans les blocs Babylon vérifiés par Bitcoin. Cela permet aux chaînes PoS de détecter les divergences, par exemple si les validateurs Babylon créent un bloc indisponible vérifié par Bitcoin et mentent sur les points de contrôle PoS qu’il contient. Les principales composantes du protocole sont les suivantes :

· Points de contrôle : Seul le dernier bloc d’une époque babylonienne est vérifié par Bitcoin. Un point de contrôle se compose du hash du bloc et d’une seule signature BLS agrégée, correspondant aux signatures de la majorité des deux tiers des validateurs qui ont approuvé le bloc pour la finalité. Les points de contrôle de Babylone incluent également le numéro d’époque. Les blocs PoS peuvent attribuer des horodatages Bitcoin via des points de contrôle Babylon. Par exemple, les deux premiers blocs PoS sont contrôlés par des blocs Babylon, qui sont ensuite contrôlés par un bloc Bitcoin avec un horodatage t_3. Par conséquent, ces blocs PoS se voient attribuer le t_3 d’horodatage Bitcoin.

· Chaînes PoS canoniques : lorsqu’une fork de chaîne PoS se produit, la chaîne avec l’horodatage le plus ancien est considérée comme la chaîne PoS canonique. Si deux forks ont le même horodatage, l’égalité est rompue en faveur du bloc PoS avec un point de contrôle antérieur sur Babylon.

· Règles de retrait : Pour retirer, les validateurs envoient une demande de retrait à la chaîne PoS. Le bloc PoS contenant la demande de retrait est ensuite vérifié par Babylon, puis par Bitcoin, en lui attribuant un horodatage t_1. Une fois que le bloc Bitcoin avec t_1 d’horodatage atteint une profondeur de k, le retrait est accordé sur la chaîne PoS. Si un validateur avec des enjeux retirés tente une attaque à long portée, les blocs de la chaîne d’attaque ne peuvent se voir attribuer qu’un horodatage postérieur à t_1. En effet, une fois que le bloc Bitcoin avec t_1 d’horodatage atteint une profondeur de k, il ne peut pas être restauré. En observant l’ordre de ces points de contrôle sur Bitcoin, les clients PoS peuvent distinguer la chaîne canonique de la chaîne d’attaque et ignorer cette dernière.

· Règles de slashing : Si les validateurs ne retirent pas leurs mises lors de la détection d’une attaque, ils peuvent être réduits pour avoir des blocs PoS conflictuels à double signature. Les PoS validateurs malveillants savent que s’ils attendent que leur demande de retrait soit approuvée pour lancer une attaque à long portée, ils ne peuvent pas tromper les clients qui peuvent se référer à Bitcoin pour identifier la chaîne canonique. Par conséquent, ils peuvent forker la chaîne PoS tout en attribuant des horodatages Bitcoin aux blocs de la chaîne PoS canonique. Ces PoS validateurs, en collaboration avec des mineurs malveillants de Babylon validateurs et de Bitcoin, fork Babylon et Bitcoin de remplacer le bloc Bitcoin par un t_2 d’horodatage par un autre bloc avec t_3 d’horodatage. Dans la vue suivante des clients PoS, cela changerait la chaîne PoS canonique de la chaîne supérieure à la chaîne inférieure. Bien qu’il s’agisse d’une attaque de sécurité réussie, elle entraîne la slashing des enjeux des PoS validateurs malveillants, car ils ont signé deux fois des blocs conflictuels sans retirer leurs mises.

· Indisponibilité de PoS Règles de mise en pause des points de contrôle : PoS validateurs devez mettre en pause leur chaîne de PoS lorsqu’ils observent un point de contrôle PoS indisponible sur Babylon. Un point de contrôle de PoS indisponible est défini comme le hash signé par les deux tiers du PoS validateurs, ce qui correspond prétendument à un bloc PoS qui ne peut pas être observé. Si PoS validateurs n’interrompez pas la chaîne de PoS lors de l’observation d’un point de contrôle indisponible, un attaquant peut révéler une chaîne d’attaque précédemment indisponible, modifiant ainsi la chaîne canonique dans les vues client ultérieures. C’est parce que le point de contrôle de la chaîne de l’ombre révélé plus tard apparaît plus tôt sur Babylone. La règle de pause ci-dessus explique pourquoi nous exigeons que les hachages de bloc PoS envoyés en tant que points de contrôle soient signés par l’ensemble de validateurs PoS. Si ces points de contrôle n’étaient pas signés, n’importe quel attaquant pourrait envoyer un hash arbitraire, prétendant qu’il s’agit du hash d’un point de contrôle de bloc PoS indisponible sur Babylon. PoS validateurs devrait alors faire une pause au point de contrôle. Notez que la création d’une chaîne de PoS indisponible est difficile : il faut compromettre au moins les deux tiers de la PoS validateurs pour approuver le bloc PoS sans fournir de données à des validateurs honnêtes. Cependant, dans l’attaque supposée ci-dessus, l’adversaire malveillant suspend la chaîne PoS sans compromettre un seul validateur. Pour prévenir de telles attaques, nous exigeons que PoS points de contrôle soient signés par les deux tiers des PoS validateurs. Par conséquent, il n’y aura pas de points de contrôle PoS indisponibles sur Babylone à moins que les deux tiers des PoS validateurs ne soient compromis, ce qui est très peu probable en raison du coût de la compromission de PoS validateurs et n’affecte pas les autres chaînes de PoS ou Babylone elle-même.

· Indisponibilité des règles de mise en pause du point de contrôle Babylon : Les validateurs PoS et Babylon doivent mettre en pause la blockchain lorsqu’ils observent un point de contrôle Babylon indisponible sur Bitcoin. Un point de contrôle Babylon indisponible est défini comme un hash avec une signature BLS agrégée des deux tiers des validateurs Babylon, ce qui correspond prétendument à un bloc Babylon qui ne peut pas être observé. Si les validateurs Babylon ne mettent pas en pause la blockchain Babylon, un attaquant peut révéler une chaîne Babylon auparavant indisponible, modifiant ainsi la chaîne Babylon canonique dans les vues client ultérieures. De même, si PoS validateurs n’interrompez pas la chaîne de PoS, l’attaquant peut révéler une chaîne d’attaque PoS auparavant indisponible et la chaîne Babylon précédemment indisponible, modifiant ainsi la chaîne de PoS canonique dans les vues client ultérieures. En effet, la chaîne Babylone profonde révélée plus tard a un horodatage antérieur sur Bitcoin et comprend des points de contrôle de la chaîne d’attaque PoS révélée plus tard. Semblable à la règle de pause aux points de contrôle PoS indisponibles, cette règle explique pourquoi nous exigeons que les hachages de blocs Babylon envoyés en tant que points de contrôle aient une signature BLS agrégée prouvant les signatures des deux tiers des validateurs Babylon. Si les points de contrôle Babylon n’étaient pas signés, n’importe quel adversaire pourrait envoyer un hash arbitraire, prétendant qu’il s’agit du hash d’un point de contrôle de bloc Babylon indisponible sur Bitcoin. PoS validateurs et Babylon validateurs devraient alors attendre un point de contrôle qui n’a pas de Babylone ou de chaînes PoS indisponibles dans sa préimage. La création d’une chaîne Babylon indisponible nécessite de compromettre au moins les deux tiers des validateurs Babylon. Cependant, dans l’attaque supposée ci-dessus, l’adversaire met en pause toutes les chaînes du système sans compromettre un seul validateur Babylon ou PoS. Pour prévenir de telles attaques, nous exigeons que les points de contrôle Babylon soient prouvés par des signatures agrégées ; ainsi, il n’y aura pas de points de contrôle Babylon indisponibles à moins que les deux tiers des validateurs ne soient compromis, ce qui est hautement improbable en raison du coût de la compromission des validateurs Babylon. Mais dans les cas extrêmes, cela affectera toutes les chaînes PoS en les forçant à se mettre en pause.

Eigenlayer dans BTC

En termes d’objectif, si Babylone est similaire à Eigenlayer, elle est loin d’être une simple « fork » d’Eigenlayer. Compte tenu de l’incapacité actuelle d’utiliser nativement DA sur la chaîne principale BTC, la présence de Babylon est assez importante. Ce protocole apporte non seulement de la sécurité aux chaînes PoS externes, mais est également crucial pour revitaliser l’écosystème BTC en interne.

Cas

d’utilisation Babylon présente de nombreux cas d’utilisation potentiels, dont certains ont déjà été réalisés ou pourraient avoir des opportunités de réalisation à l’avenir :

1. Réduction des périodes de Staking et renforcement de la sécurité : les chaînes PoS nécessitent généralement un consensus social (consensus au sein de la communauté, des opérateurs de nœuds et validateurs) pour empêcher les attaques à long portée. Ces attaques consistent à réécrire l’historique de la blockchain pour manipuler les enregistrements de transactions ou contrôler la chaîne. Les attaques à longue portée sont particulièrement graves dans les systèmes PoS car, contrairement au PoW, les systèmes PoS ne nécessitent pas de validateurs pour consommer des ressources de calcul importantes. Un attaquant peut réécrire l’histoire en contrôlant les clés des premiers jalonneurs. Pour assurer la stabilité et la sécurité du consensus du réseau blockchain, de longues périodes de jalonnement sont généralement nécessaires. Par exemple, Cosmos nécessite une période de déliaison de 21 jours. Cependant, avec Babylon, les événements historiques de la chaîne PoS peuvent être inclus dans le serveur d’horodatage BTC, en utilisant BTC comme source de confiance pour remplacer le consensus social. Cela peut réduire le temps de déliaison à un seul jour (équivalent à environ 100 blocs BTC). En outre, les chaînes PoS peuvent avoir une double sécurité grâce au jalonnement natif de jetons et au jalonnement BTC.

• Interopérabilité inter-chaînes : Grâce au protocole IBC, Babylon peut recevoir des données de points de contrôle de plusieurs chaînes PoS, ce qui permet l’interopérabilité cross-chain. Cette interopérabilité permet une communication et un partage de données transparents entre les différentes blockchains, améliorant ainsi l’efficacité et la fonctionnalité globales de l’écosystème blockchain.
• Intégration de l’écosystème BTC : La plupart des projets de l’écosystème BTC actuel, y compris Layer 2, LRT et DeFi, manquent de sécurité suffisante et reposent souvent sur des hypothèses de confiance tierces. Ces protocoles stockent également de grandes quantités de BTC dans leurs adresses. À l’avenir, Babylon pourrait développer des solutions hautement compatibles avec ces projets, créant des avantages mutuels et formant éventuellement un écosystème robuste similaire à Eigenlayer au sein d’Ethereum.
• Gestion des actifs inter-chaînes : Le protocole Babylon peut être utilisé pour la gestion sécurisée des actifs inter-chaînes. En ajoutant des horodatages aux transactions cross-chain, il garantit la sécurité et la transparence des transferts d’actifs entre différentes blockchains. Ce mécanisme permet d’éviter les doubles dépenses et autres attaques cross-chain.

La tour de Babel

L’histoire de la tour de Babel vient de la Bible, Genèse 11:1-9, et est un conte classique de la tentative de l’humanité de construire une tour pour atteindre les cieux, seulement pour être contrecarrée par Dieu. Cette histoire symbolise l’unité humaine et les objectifs communs. Le protocole Babylon vise à construire une tour similaire pour diverses chaînes PoS, les unissant sous un même toit. En termes de narration, il ne semble pas moins impressionnant qu’Eigenlayer, le défenseur d’Ethereum. Mais comment tient-il la route dans la pratique ?

À ce jour, le réseau de test Babylon a fourni des garanties de sécurité à 50 zones Cosmos via le protocole IBC. Au-delà de l’écosystème Cosmos, Babylon s’est intégré à certains protocoles LSD (Liquid Staking Produits dérivés), des protocoles d’interopérabilité omnichain et des protocoles d’écosystème Bitcoin. Cependant, en termes de jalonnement, Babylon est actuellement à la traîne par rapport à Eigenlayer, qui peut réutiliser le jalonnement et le LSD au sein de l’écosystème Ethereum. À long terme, cependant, la grande quantité de BTC dormant dans les portefeuilles et les protocoles n’a pas encore été complètement réveillée, ce qui ne représente que la partie émergée de l’iceberg de 1,3 billion de dollars. Babylon a besoin de former une symbiose positive avec l’ensemble de l’écosystème BTC.

La seule solution au dilemme de la Staking de Ponzi

Comme mentionné précédemment, Eigenlayer et Babylon se développent tous deux rapidement, et les tendances futures suggèrent qu’ils verrouilleront des quantités massives d’actifs blockchain de base. Même si ces protocoles eux-mêmes sont sécurisés, plusieurs couches de jalonnement pourraient-elles créer une spirale mortelle pour l’écosystème du jalonnement, provoquant un krach semblable à une autre hausse des taux d’intérêt par les États-Unis ? Le secteur actuel du staking a en effet connu une exubérance irrationnelle depuis la transition d’Ethereum vers le PoS et l’émergence d’Eigenlayer. Les projets attirent souvent les utilisateurs avec une TVL élevée grâce à des attentes massives en matière d’airdrop et à des rendements en couches. Un ETH peut passer par le jalonnement natif, le LSD et le LRT, empilant jusqu’à cinq ou six couches. Cet empilement augmente le risque, car un problème dans un protocole peut avoir un impact direct sur tous les protocoles impliqués, en particulier ceux qui se trouvent à la fin de la chaîne de jalonnement. L’écosystème BTC, avec ses nombreuses solutions centralisées, serait confronté à des risques encore plus grands s’il adoptait ce modèle.

Cependant, il est important de noter qu’Eigenlayer et Babylon visent fondamentalement à guider le volant d’inertie vers une véritable utilité, créant une demande réelle pour compenser les risques. Par conséquent, bien que ces protocoles de « sécurité partagée » puissent indirectement ou directement exacerber les mauvaises pratiques, ils représentent également le seul moyen d’échapper aux rendements de type Ponzi du jalonnement en couches. La question la plus urgente est maintenant de savoir si la logique commerciale des protocoles de « sécurité partagée » est vraiment viable.

La demande réelle est la clé

Dans le Web3, que ce soit pour les chaînes publiques ou les protocoles, la logique sous-jacente implique souvent matching acheteurs et vendeurs pour une demande particulière. Ceux qui le font bien peuvent « gagner le monde », car la technologie blockchain garantit que le processus de matching est équitable, réel et digne de confiance. Théoriquement, les protocoles de sécurité partagés peuvent compléter les écosystèmes de jalonnement et modulaires en plein essor. Cependant, l’offre dépassera-t-elle largement la demande ? Du côté de l’offre, il existe de nombreux projets et chaînes principales capables d’assurer une sécurité modulaire. Du côté de la demande, les chaînes PoS établies peuvent ne pas avoir besoin ou être réticentes à louer une telle sécurité pour sauver la face, tandis que les nouvelles chaînes PoS peuvent avoir du mal à payer les intérêts générés par de grandes quantités de BTC et d’ETH. Pour qu’Eigenlayer et Babylon forment une boucle commerciale fermée, les revenus générés doivent équilibrer l’intérêt généré par les jetons jalonnés dans le protocole. Même si cet équilibre est atteint et que les recettes dépassent largement les dépenses d’intérêts, cela pourrait toujours entraîner la ponction de ces nouvelles chaînes et protocoles PoS. Par conséquent, il sera crucial de trouver un équilibre entre le modèle économique, d’éviter les bulles alimentées par les anticipations de parachutage et de stimuler sainement l’offre et la demande.

À propos de YBB

YBB est un fonds web3 qui se consacre à l’identification de projets définissant le Web3 dans le but de créer un meilleur habitat en ligne pour tous les internautes. Fondé par un groupe de croyants de la blockchain qui participent activement à cette industrie depuis 2013, YBB est toujours prêt à aider les projets en phase de démarrage à passer de 0 à 1.Nous valorisons l’innovation, la passion autonome et les produits orientés vers l’utilisateur tout en reconnaissant le potentiel des cryptos et des applications blockchain.

Site web | Twi : @YBBCapital

Références

1. Explication détaillée de la façon dont Babylon profite à l’écosystème Cosmos avec la sécurité de Bitcoin : ChainCatcher Article
2. Compréhension approfondie d’Eigenlayer : Sortir Ethereum de la situation difficile de l’empilement ? Article de HaoTianCryptoInsight
3. Conversation avec le cofondateur de Babylon, Fisher Yu : Comment débloquer la liquidité de 21 millions de BTC grâce au jalonnement ? Article de ChainCatcher
4. Dette triangulaire ou inflation modérée : une perspective alternative sur le re-staking : Weixin Article
5. Un coup d’œil à ce que j’ai vu dans la crypto ces derniers temps : TheKnower Substack

Medium]. Tous les droits d’auteur appartiennent à l’auteur original [YBB]. S’il y a des objections à cette réimpression, veuillez contacter l’équipe Gate Learn, et ils la traiteront rapidement.

Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l’auteur et ne constituent pas un conseil en investissement.

Les traductions de l’article dans d’autres langues sont effectuées par l’équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.