Babylon : comment libérer la valeur de la sécurité du bitcoin ?
TechFlow SélectionTechFlow Sélection
Babylon : comment libérer la valeur de la sécurité du bitcoin ?
Eigenlayer et Babylon prennent progressivement de l'ampleur, et selon les tendances actuelles, les deux projets devraient à l'avenir verrouiller une quantité massive d'actifs fondamentaux de la blockchain.
Dédié à des analyses Web3 approfondiesAuteur : Zeke, chercheur chez YBB Capital
Préambule
À l’ère modulaire menée par Ethereum, le fait de s’appuyer sur une couche DA (disponibilité des données) pour fournir des services de sécurité n’a rien de nouveau. Toutefois, le concept actuel de « staking » apportant une sécurité partagée ouvre une nouvelle dimension à ce secteur modulaire : exploiter le potentiel de l’« or et argent numériques » afin d'offrir aux nombreux protocoles et blockchains la sécurité du Bitcoin ou d'Ethereum. Sur le plan narratif, cela paraît extrêmement ambitieux — libérant des milliers de milliards de dollars en liquidités tout en constituant un pilier clé de la voie future vers la mise à échelle. Prenons les récents exemples du protocole de staking Bitcoin Babylon et du protocole de restaking Ethereum EigenLayer, ayant respectivement levé 70 millions et 100 millions de dollars : il est clair que les grands fonds spéculatifs reconnaissent fortement cette trajectoire.
Pourtant, les critiques sont nombreuses. Si l’architecture modulaire représente bien l’étape ultime de la scalabilité, ces deux projets devant bloquer d'énormes quantités de BTC et ETH, peut-on véritablement faire confiance à leur propre sécurité ? L’accumulation frénétique de protocoles imbriqués tels que les LSD et LRT ne risque-t-elle pas de devenir le cygne noir du futur écosystème blockchain ? Leur logique commerciale est-elle viable ? Comme nous avons déjà analysé EigenLayer dans nos précédents articles, nous allons ici examiner principalement Babylon pour répondre à ces questions.
Étendre le consensus de sécurité
Parmi toutes les blockchains existantes, Bitcoin et Ethereum demeurent incontestablement les plus précieuses, grâce à leur sécurité éprouvée, leur haut niveau de décentralisation et leur consensus de valeur accumulés au fil des années — autant de caractéristiques rares qu’il est quasi impossible pour d’autres blockchains hétérogènes de reproduire. L’idée centrale de la modularité consiste justement à « louer » ces attributs aux demandeurs. Actuellement, deux grandes approches se distinguent :
● La première consiste à utiliser une blockchain de niveau 1 suffisamment sécurisée (généralement Ethereum) comme couche inférieure ou partie fonctionnelle pour les rollups. Cette solution offre une sécurité maximale et une légitimité reconnue, tout en bénéficiant des ressources de l’écosystème principal. Toutefois, elle présente des inconvénients en termes de débit et de coût pour certains rollups spécifiques (chaînes applicatives, chaînes de niche, etc.) ;
● La seconde vise à recréer une entité offrant une sécurité proche de Bitcoin ou Ethereum, mais avec de meilleures performances et coûts réduits. Par exemple, Celestia adopte une architecture purement dédiée à la disponibilité des données, réduit au minimum les exigences matérielles des nœuds et propose des frais de gaz bas, simplifiant ainsi radicalement son modèle afin de construire rapidement une couche DA suffisamment sécurisée, décentralisée et performante. Le revers de la médaille ? Il lui faudra du temps pour atteindre pleinement sécurité et décentralisation, sans parler de son manque de légitimité et de sa concurrence ouverte avec Ethereum, ce qui suscite une certaine hostilité au sein de la communauté Ethereum.
Dans cette dernière catégorie figurent également Babylon et EigenLayer, qui reprennent le principe fondamental du PoS (preuve d’enjeu) pour créer un service de sécurité partagée en tirant parti de la valeur des actifs Bitcoin ou Ethereum. Comparés aux deux premières approches, ils apparaissent comme des intermédiaires neutres. Leur avantage réside dans l’héritage de la légitimité et de la sécurité des blockchains principales, tout en créant davantage de valeur utilitaire pour leurs actifs natifs, avec une flexibilité accrue.
Le potentiel caché de l’or numérique
Quel que soit le mécanisme de consensus considéré, la sécurité d’une blockchain dépend largement de la quantité de ressources mobilisées. Les chaînes PoW nécessitent d’importants investissements matériels et énergétiques, tandis que les chaînes PoS reposent sur la valeur des actifs mis en jeu. Bitcoin bénéficie d’un gigantesque réseau de hachage PoW, ce qui en fait l’actif le plus sécurisé du monde blockchain. Pourtant, malgré une capitalisation boursière de 1,39 billion de dollars représentant près de la moitié de l’écosystème, ses cas d’usage restent limités à deux fonctions principales : les transferts et le paiement des frais de transaction.
En revanche, concernant l’autre moitié du paysage blockchain, notamment depuis la mise à jour Shanghai d’Ethereum vers le PoS, presque toutes les nouvelles blockchains utilisent désormais différentes variantes du PoS pour assurer leur consensus. Toutefois, en raison de leur incapacité à attirer suffisamment de capitaux pour le staking, leur niveau de sécurité reste incertain. Dans l’ère actuelle de modularité, bien que les zones Cosmos ou divers Layer 2 puissent compenser cela via des couches DA, elles perdent alors une partie de leur autonomie. Pour les anciennes blockchains PoS ou les consortiums, utiliser Ethereum ou Celestia comme couche DA est souvent irréaliste. C’est précisément là que Babylon intervient : en permettant de staker du BTC pour protéger les chaînes PoS. À l’instar de l’or physique soutenant historiquement la valeur des monnaies papier, le BTC pourrait parfaitement jouer ce rôle dans l’univers blockchain.
Du zéro à l’un
Libérer la valeur de l’« or numérique » a toujours été l’un des récits les plus vastes — et les plus difficiles à réaliser — du monde blockchain. Des sidechains, au réseau Lightning, aux ponts et jetons tokenisés, jusqu’aux runes ou aux Layer 2 Bitcoin, chaque tentative comporte invariablement des défauts structurels. Pour préserver l’intégrité de la sécurité Bitcoin, Babylon doit impérativement rejeter toute solution centralisée introduisant une hypothèse de confiance tierce. Parmi les alternatives subsistantes, les runes et le réseau Lightning (dont le développement est extrêmement lent) ne permettent aujourd’hui que l’émission d’actifs. Ainsi, Babylon doit concevoir sa propre « solution de mise à échelle », faisant passer le staking natif du Bitcoin de zéro à un.
Analysons brièvement les éléments exploitables du Bitcoin : 1. le modèle UTXO, 2. les horodatages, 3. les multiples méthodes de signature, 4. les opcodes de base. La réponse de Babylon consiste à tenir compte de la programmabilité limitée et de la faible capacité de traitement des données du Bitcoin. En suivant un principe minimaliste, seul le strict nécessaire pour exécuter un contrat de staking sera implémenté directement sur Bitcoin — c’est-à-dire le dépôt, la confiscation, la récompense et le retrait du BTC — tous gérés sur la chaîne principale. Une fois ce saut technologique accompli, les besoins complexes seront traités par une zone Cosmos. Reste néanmoins une question cruciale : comment enregistrer les données des chaînes PoS sur la chaîne principale ?
Staking distant (Remote Staking)
L’UTXO (Unspent Transaction Output), modèle transactionnel conçu par Satoshi Nakamoto pour Bitcoin, repose sur une logique extrêmement simple : une transaction implique simplement une entrée (input) et une sortie (output). Un UTXO correspond à la portion non dépensée d’un montant entrant. En réalité, le grand livre de Bitcoin est un ensemble d’UTXOs dont l’état est constamment suivi pour gérer la propriété et la circulation du BTC. Chaque transaction consomme des UTXOs existants et en crée de nouveaux. En raison de certaines propriétés extensibles inhérentes, l’UTXO est naturellement devenu le point de départ de nombreuses solutions natives de mise à échelle. Par exemple, le réseau Lightning utilise l’UTXO et les signatures multisignatures pour créer des canaux d’état et des mécanismes de pénalité, tandis que les inscriptions et runes associent des UTXOs pour créer des jetons semi-fongibles (SFT). Toutes reposent sur cet élément fondamental.
Babylon s’appuie donc également sur l’UTXO pour mettre en œuvre son contrat de staking (appelé « staking distant », où la sécurité du BTC est transmise à distance via une couche intermédiaire aux chaînes PoS), combinant astucieusement les opcodes existants. Ce processus peut être divisé en quatre étapes clés :
● Verrouillage des fonds
L’utilisateur envoie ses fonds vers une adresse contrôlée par une signature multisignature. Grâce à OP_CTV (OP_CHECKTEMPLATEVERIFY), qui permet de créer des modèles de transactions prédéfinis exécutables uniquement sous certaines conditions, le contrat garantit que ces fonds ne peuvent être dépensés que si ces conditions sont remplies. Une fois verrouillés, un nouvel UTXO est créé, attestant du dépôt du BTC.
● Vérification des conditions
L’opcode OP_CSV (OP_CHECKSEQUENCEVERIFY) permet d’imposer un verrouillage temporel relatif basé sur le numéro de séquence de la transaction, empêchant le retrait des fonds pendant une période définie. Associé à OP_CTV, cela permet de gérer le dépôt, le retrait (si la durée minimale de staking est respectée) et la confiscation (slashing) — en cas de comportement malveillant, l’UTXO verrouillé est dépensé vers une adresse inaccessible, similaire à une adresse noire.
● Mise à jour d’état
Chaque action de staking ou de retrait implique la création ou la consommation d’UTXOs. De nouveaux UTXOs sont générés lors de nouvelles transactions, tandis que les anciens sont marqués comme dépensés. Ainsi, chaque mouvement est fidèlement enregistré sur la blockchain, assurant transparence et sécurité.
● Distribution des收益
Selon le montant et la durée du staking, le contrat calcule les récompenses dues et les distribue via la création de nouveaux UTXOs. Ces gains peuvent ensuite être déverrouillés et dépensés une fois certaines conditions scriptées remplies.
Horodatage
Une fois le contrat de staking natif mis en place, il faut envisager l’enregistrement des événements historiques des chaînes externes. Dans le livre blanc de Satoshi, la blockchain Bitcoin introduit un concept d’horodatage soutenu par la preuve de travail (PoW), offrant un ordre temporel irréversible aux événements. Dans l’usage natif du Bitcoin, ces événements correspondent aux transactions enregistrées sur le grand livre. Aujourd’hui, pour renforcer la sécurité d’autres chaînes PoS, Bitcoin peut aussi servir à horodater des événements sur des blockchains externes. Chaque fois qu’un tel événement se produit, une transaction est envoyée aux mineurs, qui l’insèrent dans le registre Bitcoin, y ajoutant ainsi un horodatage. Ces horodatages peuvent aider à résoudre divers problèmes de sécurité. Le concept général consistant à horodater des événements d’une chaîne enfant sur une chaîne parente s’appelle « checkpointing », et les transactions associées sont appelées « transactions de checkpoint ». Plus précisément, les horodatages dans Bitcoin présentent les caractéristiques suivantes :
1. Format temporel : l’horodatage indique le nombre de secondes écoulées depuis le 1er janvier 1970 à 00:00:00 UTC, également appelé timestamp Unix ou temps POSIX ;
2. Fonction : il identifie l’instant de création du bloc, aide les nœuds à ordonner les blocs et participe au mécanisme d’ajustement de difficulté du réseau ;
3. Horodatage et ajustement de difficulté : tous les 2016 blocs (environ toutes les deux semaines), le réseau Bitcoin ajuste sa difficulté. L’horodatage joue ici un rôle crucial, car le réseau se base sur le temps total de génération des 2016 derniers blocs pour réguler la vitesse moyenne de création d’un bloc à environ 10 minutes ;
4. Vérification de validité : lorsqu’un nœud reçoit un nouveau bloc, il vérifie son horodatage. Celui-ci doit être supérieur à la médiane temporelle des blocs précédents et ne pas excéder de plus de 120 minutes l’heure du réseau (soit deux heures dans le futur).
Le serveur d’horodatage est une primitive définie par Babylon. Il permet aux blocs PoS d’obtenir un horodatage Bitcoin via les checkpoints Babylon, garantissant l’exactitude de la chronologie et empêchant la falsification. Situé au sommet de l’architecture Babylon, ce serveur constitue la source fondamentale de confiance du système.
L’architecture en trois couches de Babylon
Comme illustré ci-dessus, l’architecture globale de Babylon se divise en trois niveaux : Bitcoin (agissant comme serveur d’horodatage), Babylon (une zone Cosmos servant de couche intermédiaire) et la couche des chaînes PoS consommatrices. Babylon désigne ces deux dernières respectivement comme le « plan de contrôle » (Control Plane, soit Babylon lui-même) et le « plan de données » (Data Plane, soit les différentes chaînes PoS clientes).
Après avoir compris les bases de la décentralisation du protocole, examinons maintenant comment Babylon utilise une zone Cosmos pour relier les deux extrémités. Selon les explications détaillées du laboratoire Tse de Stanford sur Babylon1, ce dernier peut recevoir des flux de checkpoints provenant de plusieurs chaînes PoS, les agréger puis les publier sur Bitcoin. Grâce à la signature agrégée des validateurs Babylon, la taille des checkpoints est minimisée. Leur fréquence est contrôlée en permettant aux validateurs Babylon de modifier le checkpoint une seule fois par époque (epoch).
Les validateurs des différentes chaînes PoS téléchargent les blocs Babylon et vérifient si leurs propres checkpoints PoS sont inclus dans les blocs Babylon confirmés par Bitcoin. Cela leur permet de détecter toute divergence — par exemple, si un validateur Babylon crée un bloc indisponible et ment sur l’inclusion d’un checkpoint PoS dans un bloc non disponible. Les composants principaux du protocole sont les suivants :
● Checkpoints : Seul le dernier bloc de chaque époque Babylon est vérifié par Bitcoin. Un checkpoint comprend le hachage du bloc et une signature BLS agrégée unique, correspondant aux deux tiers des validateurs ayant signé la finalisation du bloc. Il inclut également le numéro d’époque. Les blocs PoS peuvent ainsi hériter du timestamp Bitcoin du bloc Babylon qui les checkpointe. Par exemple, les deux premiers blocs PoS sont checkpointés par un bloc Babylon, qui est lui-même horodaté par un bloc Bitcoin t_3. Ainsi, ces blocs PoS reçoivent l’horodatage t_3.
● Chaîne PoS canonique : En cas de fourchette sur une chaîne PoS, celle possédant l’horodatage le plus ancien est considérée comme la chaîne officielle. Si deux fourchettes ont le même horodatage, la priorité est donnée à celle dont le checkpoint PoS apparaît plus tôt sur Babylon.
● Règles de retrait : Pour retirer ses fonds, un validateur envoie une demande sur la chaîne PoS. Le bloc contenant cette demande est checkpointé par Babylon, puis par Bitcoin, et reçoit un horodatage t_1. Dès que le bloc Bitcoin t_1 atteint une profondeur k, le retrait est autorisé sur la chaîne PoS. Si un validateur ayant retiré sa mise lance ensuite une attaque à long terme, les blocs de la chaîne d’attaque ne pourront recevoir qu’un horodatage postérieur à t_1, car le bloc t_1 ne peut plus être annulé. En observant l’ordre des checkpoints sur Bitcoin, les clients PoS peuvent distinguer la chaîne valide de l’attaque et ignorer la seconde.
● Règles de slashing : Si un validateur ne retire pas sa mise après détection d’une attaque, il peut être puni en cas de double signature sur des blocs PoS conflictuels. Un validateur malveillant sait que s’il attend que le retrait soit approuvé avant de lancer une attaque, les clients verront immédiatement la vérité via Bitcoin. Il pourrait donc choisir de bifurquer la chaîne PoS au moment où un bloc reçoit un horodatage t_2, en coopérant avec des validateurs Babylon malveillants et des mineurs Bitcoin pour remplacer le bloc t_2 par un autre horodaté t_3. Pour les clients ultérieurs, cela ferait passer la chaîne canonique de la branche supérieure à la branche inférieure. Bien que l’attaque réussisse, les validateurs PoS malveillants se font slash car ils ont signé deux blocs contradictoires sans avoir encore retiré leur mise.
● Règle d’arrêt pour checkpoint PoS indisponible : Lorsqu’un validateur PoS observe un checkpoint PoS indisponible sur Babylon, il doit suspendre la chaîne PoS. Ici, un checkpoint PoS indisponible est le hachage signé par deux tiers des validateurs PoS, supposé correspondre à un bloc PoS invisible. Si les validateurs ne suspendent pas la chaîne, un attaquant pourrait révéler une chaîne d’attaque antérieurement cachée, modifiant ainsi la chaîne canonique dans la vision future des clients. En effet, les checkpoints de la chaîne fantôme apparaissent plus tôt sur Babylon. Cette règle explique pourquoi les checkpoints PoS doivent être signés par le comité de validation PoS. Sans ces signatures, n’importe quel attaquant pourrait envoyer un hachage arbitraire en affirmant qu’il correspond à un bloc PoS indisponible, forçant ainsi les validateurs à suspendre la chaîne. Créer une telle chaîne PoS est difficile : cela exige de compromettre au moins deux tiers des validateurs PoS, les amenant à signer un bloc sans partager les données. Mais dans l’attaque supposée ci-dessus, l’adversaire arrête la chaîne sans compromettre aucun validateur. Pour éviter cela, nous exigeons que les checkpoints PoS soient signés par deux tiers des validateurs. Ainsi, un checkpoint indisponible n’existera que si deux tiers des validateurs sont effectivement corrompus — ce qui est extrêmement improbable en raison du coût élevé. Cette attaque n’affecterait ni les autres chaînes PoS ni Babylon lui-même.
● Règle de suspension pour checkpoint Babylon indisponible : Les validateurs PoS et Babylon doivent suspendre leurs chaînes en cas de checkpoint Babylon indisponible sur Bitcoin. Un tel checkpoint est un hachage signé par deux tiers des validateurs Babylon, supposé lié à un bloc Babylon non observable. Si les validateurs Babylon ne suspendent pas leur chaîne, un attaquant pourrait révéler une ancienne chaîne Babylon cachée, changeant ainsi la chaîne canonique dans la vue future des clients. De même, si les validateurs PoS ne réagissent pas, l’attaquant pourrait révéler simultanément une chaîne PoS d’attaque et une chaîne Babylon cachée, altérant la chaîne PoS canonique. Car la chaîne Babylon sombre révélée plus tard porte un horodatage plus ancien sur Bitcoin et contient les checkpoints de la chaîne PoS d’attaque. Comme précédemment, cette règle justifie l’obligation de signer les checkpoints Babylon. Sans cela, tout adversaire pourrait envoyer un hachage faux. Les validateurs devraient alors attendre un checkpoint sans image contenant une chaîne Babylon ou PoS indisponible ! Créer une telle chaîne Babylon requiert de compromettre deux tiers de ses validateurs. Or, dans l’attaque supposée, l’attaquant fige toutes les chaînes sans compromettre un seul nœud. Pour l’empêcher, les checkpoints Babylon doivent être prouvés par signature agrégée — donc seulement si deux tiers des validateurs sont réellement compromises. En raison du coût élevé, une telle attaque sur la disponibilité des données est hautement improbable. Toutefois, dans des cas extrêmes, elle pourrait forcer l’arrêt de toutes les chaînes PoS.
EigenLayer pour Bitcoin
Bien que Babylon partage le même objectif qu’EigenLayer, il n’est en aucun cas un simple fork. Dans un contexte où la couche DA native du Bitcoin n’est pas utilisable directement, l’existence de Babylon est hautement pertinente. Au-delà de renforcer la sécurité des chaînes PoS externes, il joue un rôle vital dans la revitalisation de l’écosystème BTC lui-même.
Cas d’usage
Les cas d’usage potentiels de Babylon sont nombreux, parmi lesquels certains sont déjà réalisés ou envisageables à court terme :
1. Réduction de la période de staking et renforcement de la sécurité : les chaînes PoS exigent généralement un consensus social (entre la communauté, les opérateurs de nœuds et les validateurs) pour prévenir les attaques à long terme — tentatives de réécriture de l’historique visant à falsifier des transactions ou prendre le contrôle de la chaîne. Ces attaques sont particulièrement dangereuses dans les systèmes PoS, où les validateurs n’ont pas besoin de consommer massivement de ressources comme en PoW. Un attaquant contrôlant les clés privées anciennes peut réécrire l’historique. Pour maintenir la stabilité du consensus, les périodes de staking sont donc longues — par exemple 21 jours sur Cosmos. Avec Babylon, les événements historiques PoS peuvent être horodatés par Bitcoin, remplaçant ainsi le consensus social par la confiance en Bitcoin. Le délai de retrait peut alors être ramené à 1 jour (soit environ 100 blocs Bitcoin). La chaîne PoS bénéficie alors d’une double protection : son propre jeton natif et le BTC ;
2. Interopérabilité entre chaînes : via le protocole IBC, Babylon peut recevoir des données de checkpoint de multiples chaînes PoS, rendant possible l’interopérabilité. Cela permet une communication fluide et un partage de données sécurisé entre blockchains, améliorant l’efficacité globale de l’écosystème ;
3. Intégration à l’écosystème BTC : la plupart des projets actuels dans l’écosystème BTC manquent encore de sécurité robuste — qu’il s’agisse de Layer 2, de LRT ou de DeFi, beaucoup reposent sur des hypothèses de confiance tierces. Or, ces protocoles détiennent d’importantes quantités de BTC. À l’avenir, des synergies pourraient émerger entre eux et Babylon, créant un écosystème mutuellement nourricier, similaire à celui qu’EigenLayer développe sur Ethereum ;
4. Gestion d’actifs multi-chaînes : Babylon permet de sécuriser la gestion d’actifs entre chaînes. En horodatant les transactions inter-chaînes, il garantit sécurité et transparence lors du transfert d’actifs, aidant à prévenir les doubles dépenses et autres attaques cross-chain.
La tour de Babel
L’histoire de la tour de Babel provient du chapitre 11 de la Genèse dans la Bible. Elle raconte la tentative de l’humanité de construire une tour touchant le ciel, stoppée par Dieu. Ce mythe symbolise à la fois l’unité humaine et les ambitions communes. C’est aussi une métaphore implicite du projet Babylon, qui vise à construire une « tour de Babel » reliant et unifiant de nombreuses chaînes PoS. Narrativement, cela n’a rien à envier au récit d’EigenLayer, présenté comme le défenseur d’Ethereum. Mais quelle est la réalité ?
À ce jour, le réseau test de Babylon assure la sécurité de 50 zones Cosmos via le protocole IBC. En dehors de Cosmos, Babylon collabore avec plusieurs protocoles LSD (staking liquide), de compatibilité universelle et de l’écosystème Bitcoin pour intégration. En revanche, côté staking, comparé à EigenLayer qui peut réutiliser les mises et LSD existantes dans l’écosystème Ethereum, Babylon est encore en retard. Mais à long terme, les milliards de dollars de BTC endormis dans des portefeuilles et protocoles ne sont qu’à peine réveillés. Ce que nous voyons aujourd’hui n’est qu’un fragment de l’iceberg des 1,3 billion de dollars. Babylon doit encore développer une synergie positive avec l’ensemble de l’écosystème BTC.
La seule issue contre les pyramides imbriquées
Comme mentionné en introduction, EigenLayer et Babylon gagnent progressivement en maturité. Selon la tendance actuelle, ils finiront par bloquer d’immenses quantités d’actifs centraux blockchain. Même si leurs protocoles sont sécurisés, l’accumulation excessive de structures imbriquées ne risque-t-elle pas de plonger tout l’écosystème du staking dans une spirale mortelle, entraînant un effondrement comparable à une hausse drastique des taux américains ? Le secteur du staking traverse actuellement une phase prolongée de croissance irrationnelle, depuis le passage d’Ethereum au PoS et l’émergence d’EigenLayer. Pour attirer plus de TVL, les projets promettent souvent des airdrops élevés et des rendements cumulés via des imbrications successives. Un seul ETH peut ainsi être réutilisé 5 à 6 fois, du staking natif au LSD, puis au LRT. Cette accumulation de risques est inévitable : une défaillance dans un protocole impacte automatiquement tous les autres participants, surtout ceux situés en bout de chaîne. Or, l’écosystème BTC regorge déjà de solutions centralisées. Reproduire aveuglément ce modèle ne ferait qu’aggraver les risques. Toutefois, il est essentiel de souligner que EigenLayer et Babylon cherchent à transformer la roue du staking vers une utilité réelle. Ils créent une offre et une demande authentiques pour contrer ces dérives. Ainsi, bien que les protocoles de « sécurité partagée » aient indirectement encouragé ces abus, ils constituent la seule voie pour sortir du piège des rendements pyramidals. La question centrale devient alors : la logique commerciale de ces protocoles est-elle économiquement viable ?
La clé : une offre et une demande réelles
Dans Web3, qu’il s’agisse de blockchains ou de protocoles, la logique fondamentale repose souvent sur la mise en relation d’offreurs et de demandeurs. Ceux qui réussissent cette médiation dominent le marché. La blockchain elle-même garantit que cette médiation soit juste, authentique et fiable. Théoriquement, les protocoles de sécurité partagée pourraient compléter harmonieusement l’écosystème florissant du staking et de la modularité. Mais en y regardant de plus près, l’offre ne risque-t-elle pas de largement dépasser la demande ? D’un côté, de nombreux projets et blockchains peuvent fournir une sécurité modulaire. De l’autre, les anciennes chaînes PoS n’auront peut-être pas besoin — ou par fierté refuseront — de louer une telle sécurité. Quant aux nouvelles chaînes PoS, pourront-elles vraiment payer les intérêts générés par des milliards de BTC et ETH ? Pour que le modèle économique d’EigenLayer ou Babylon soit viable, leurs revenus doivent au minimum couvrir les intérêts dus aux jetons misés. Et même si ces revenus dépassent largement les coûts, cela pourrait entraîner un « vampirisme » préjudiciable aux nouvelles chaînes et protocoles. Ainsi, trouver un équilibre économique, éviter les bulles basées sur les attentes d’airdrops, et stimuler durablement l’offre et la demande restera l’enjeu crucial.
Références
1. Analyse complète : Comment Babylon permet à l’écosystème Cosmos de bénéficier de la sécurité du Bitcoin : https://www.chaincatcher.com/article/2079486
2. Comprendre EigenLayer : Ethereum peut-il échapper au piège des imbrications ? : https://haotiancryptoinsight.substack.com/p/eigenlayer?utm_source=publication-search
3. Entretien avec Fisher Yu, cofondateur de Babylon : Comment libérer la liquidité de 21 millions de BTC via le staking ? : https://www.chaincatcher.com/article/2120653
4. Dettes croisées ou inflation modérée : une autre perspective sur le restaking : https://mp.weixin.qq.com/s/dMc_WzndAZXRjnEgD2hcew
5. A look at what I've been seeing in crypto lately : https://theknower.substack.com/p/a-look-at-what-ive-been-seeing-in
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
@YBBCapital
