Tout le monde le veut, peu peuvent le manier

1.1 Le pays de l'opportunité : Bitcoin

(Source: companiesmarketcap)

Bitcoin, créé en 2008 par un développeur anonyme, est devenu un actif massif, se classant au 7e rang en termes de capitalisation boursière parmi toutes les classes d'actifs. Il est maintenant reconnu non seulement par les institutions financières, mais même par le président américain. Actuellement, la capitalisation boursière du Bitcoin est similaire à celle de l'argent. Compte tenu du fait que l'adoption du Bitcoin est encore relativement faible et que sa capitalisation boursière n'est que le dixième de celle de l'or, son potentiel de croissance future reste très prometteur.

Malgré la croissance immense du Bitcoin en tant qu'actif, il existe encore une lacune significative, à savoir son niveau d'utilisation. Des actifs traditionnels tels que les actions et les obligations peuvent être utilisés dans une large gamme de produits financiers, mais les applications financières du Bitcoin sont encore très limitées, tant sur le plan technique que pratique. À l'instar des premiers jours de la conquête de l'Ouest américain, le Bitcoin représente une terre d'opportunités inexploitées.

1.2 Tentatives d'utilisation de BTC

En raison de sa capitalisation boursière énorme, de nombreuses entreprises et protocoles ont cherché à tirer parti du Bitcoin pour créer du crédit supplémentaire. Les principales tentatives d'utilisation du BTC jusqu'à présent comprennent :

• Finance centralisée : Les institutions financières traditionnelles proposent divers produits financiers basés sur le Bitcoin. Le CME propose des contrats à terme et des options sur le Bitcoin, Coinbase offre des prêts adossés au BTC, et plusieurs institutions ont lancé des ETF basés sur le BTC pour les investisseurs.
• Ponte du gardien : Des services tels que WBTC et cbBTC enveloppent le BTC de manière centralisée, ce qui permet de l'utiliser sur d'autres réseaux. En déposant du BTC auprès de gardiens tels que BitGo ou Coinbase, les utilisateurs reçoivent une quantité équivalente de WBTC ou cbBTC émis sur le réseau Ethereum.
• Pontage sur chaîne : Pour éliminer la dépendance vis-à-vis des gardiens centralisés, divers protocoles ont tenté de relier de manière sécurisée le BTC à d'autres réseaux. Cependant, mettre en place un mécanisme de pontage BTC complètement sans confiance reste extrêmement difficile, car un certain niveau d'hypothèses de confiance est inévitable.
• Solutions de mise à l'échelle : Les efforts visant à utiliser BTC sur des sidechains et des solutions Bitcoin L2 ont récemment augmenté. Cependant, ces approches impliquent toujours des hypothèses de confiance supplémentaires. L'équipe des Taproot Wizards travaille à atténuer ce problème en utilisant OP_CAT.
• Stablecoins basés sur BTC: Des protocoles comme Yala et Avalon ont émergé, émettant des stablecoins adossés au BTC de manière similaire à MakerDAO. Cependant, ces solutions sont également confrontées au problème fondamental de nécessiter des hypothèses de confiance lors du pontage du BTC.

Examiner ces tentatives d'utilisation du BTC révèle un défi commun : il est difficile d'utiliser Bitcoin de manière native. L'une des plus grandes forces de Bitcoin est sa sécurité, mais si des hypothèses de confiance supplémentaires affaiblissent cette sécurité, cela crée une barrière d'entrée significative pour les détenteurs de BTC. C'est la principale raison pour laquelle le niveau d'utilisation de Bitcoin reste relativement faible.

1.3 Babylon: Utilisation native de BTC

C'est là@babylonlabs_iose concentre. Babylon permet aux détenteurs de BTC de miser leur Bitcoin nativement sur le réseau Bitcoin et de participer à la validation d'autres protocoles de PoS, en gagnant des récompenses supplémentaires.

Grâce à l'avantage d'utiliser BTC sans suppositions de confiance supplémentaires, Babylon a rapidement atteint plus de 5 milliards de dollars en TVL. Le TVL aurait pu être encore plus élevé s'il n'y avait pas de limites de mise en jeu sur BTC.

Mais attendez, le langage de script de Bitcoin n'est pas complet, ce qui signifie qu'il ne peut pas facilement prendre en charge des contrats intelligents complexes. Alors, comment Babylon parvient-elle à réaliser cette fonctionnalité ? Dans cet article, nous explorerons les mécanismes spécifiques derrière le fonctionnement de Babylon.

2. Babylon

Tout comme la construction de la Tour de Babel, pouvons-nous jamais atteindre une véritable utilisation native de BTC ?

2.1 Aperçu de Babylon

La mission de Babylon est de mettre à l'échelle Bitcoin pour sécuriser le monde décentralisé. Bien qu'il soit largement connu comme un protocole de mise en jeu de BTC, Babylon propose également des services d'horodatage Bitcoin, formant une suite de protocoles de partage de sécurité BTC.

Babylon est composé de deux protocoles principaux:

• Horodatage Bitcoin : Cela permet aux chaînes PoS de vérifier leurs données de bloc sur le réseau Bitcoin. En procédant ainsi, les chaînes PoS peuvent atténuer les attaques à longue portée, réduire les périodes de désengagement de l'enjeu, protéger les transactions critiques et bénéficier de la résistance à la censure de Bitcoin au niveau du réseau.
• Bitcoin Staking: Cela permet aux détenteurs de BTC de bloquer leurs BTC nativement sur le réseau Bitcoin et de participer à la validation d'autres protocoles PoS, gagnant des récompenses supplémentaires dans le processus.

2.2 Architecture de Babylone

(Source: Babylon)

L'architecture fondamentale de Babylon est illustrée dans le diagramme ci-dessus, avec la Babylon Chain, construite sur le Cosmos SDK, au cœur du système. En plus de la Babylon Chain, plusieurs programmes périphériques facilitent le staking de BTC et la communication avec Bitcoin et d'autres zones consommateurs. Les zones consommateurs font référence aux chaînes PoS qui enregistrent des points de contrôle sur le réseau Bitcoin via Babylon.

La chaîne de Babylone se compose de différents modules qui exécutent des fonctions essentielles au sein de l'écosystème, y compris la gestion de l'ensemble de validateurs, le suivi des en-têtes de bloc Bitcoin, la soumission de points de contrôle au réseau Bitcoin, et la gestion de l'ensemble de fournisseurs de finalité actifs liés au staking de BTC. Pour référence, un fournisseur de finalité est similaire à un opérateur AVS dans EigenLayer, ce qui signifie qu'il participe à la validation d'autres protocoles PoS.

De plus, Babylon a mis en place plusieurs programmes de soutien pour faciliter la communication fluide entre le réseau Bitcoin et la chaîne Babylon :

• Vigilantes: Un ensemble de programmes qui agit comme un relais de données entre Bitcoin et Babylone.
• Moniteurs : un ensemble de programmes qui garantit la cohérence entre la chaîne de Babylone et le réseau Bitcoin.

Grâce à cet écosystème, Babylon permet à l'industrie de la cryptographie de tirer parti de la sécurité solide et de la liquidité profonde de Bitcoin. Maintenant, explorons plus en détail les deux fonctionnalités principales de Babylon : Bitcoin Timestamping et Bitcoin Staking.

3. Comment fonctionne l'horodatage Bitcoin

3.1 Pourquoi le désassemblage des mises est-il lent ?

Toute personne ayant mis en jeu des jetons auparavant saurait que le dégel nécessite généralement une période d'attente de 1 à 2 semaines. Pendant ce temps, les jetons ne peuvent pas être utilisés ni rapporter d'intérêts, ce qui entraîne des inefficacités. Mais pourquoi le dégel nécessite-t-il une période d'attente ? Pourquoi ne pas permettre des retraits instantanés ?

La raison la plus simple est la sécurité du réseau. Si le désenclavement était instantané, de grandes quantités de jetons pourraient être désenclavés en réponse aux fluctuations du marché, affaiblissant considérablement la sécurité du réseau. Cependant, au-delà de la sécurité, il y a une autre raison fondamentale : prévenir les attaques à longue portée.

Attaque à Longue Portée 3.2

(Source: AP)

Une attaque à longue portée fait référence à une attaque dans laquelle des validateurs malveillants créent une nouvelle fourchette à partir de blocs passés, tentant de remplacer la chaîne canonique actuelle. Si la chaîne fourchue malveillante devient aussi longue ou plus longue que la chaîne canonique, les nouveaux nœuds rejoignant le réseau peuvent être confus quant à la chaîne légitime, ce qui peut entraîner des problèmes potentiels. Mais attendez, est-ce même possible ?

Dans un réseau PoW, une attaque à longue portée est presque impossible. Pour rattraper la chaîne canonique actuelle, les attaquants devraient recréer de nouveaux blocs du passé tout en dépassant la puissance de calcul du réseau existant, ce qui est pratiquement irréalisable.

De même, dans un réseau PoS fonctionnant correctement, cette attaque est également impossible. Créer une nouvelle fourchette nécessiterait que des validateurs malveillants signent plusieurs blocs conflictuels, ce qui est considéré comme une double signature, une violation du protocole entraînant des pénalités de slashing.

Cependant, et si le retrait était autorisé immédiatement?

Contrairement aux réseaux PoW, les réseaux PoS n'ont pas besoin d'une puissance de calcul massive pour générer des blocs. Cela signifie que si des validateurs malveillants retirent leurs actifs de la chaîne existante, puis créent une nouvelle chaîne fourchue à partir d'un bloc passé où leurs clés de validateur étaient encore valides, ils pourraient potentiellement rattraper la chaîne canonique actuelle. Dans ce scénario, les nouveaux nœuds rejoignant le réseau pourraient avoir du mal à déterminer quelle chaîne est la légitime, ce qui entraînerait une confusion potentielle et des risques de sécurité.

(Source: Babylon)

Si une attaque à longue portée réussit, des validateurs malveillants peuvent exploiter des mécanismes de pont pour voler des fonds. Par exemple, supposons qu'un attaquant malveillant nommé John transfère 1M de jetons RUG de la chaîne RugPull à Osmosis et les échange contre des jetons OSMO. Ce transfert se fait via IBC, qui fonctionne en verrouillant les jetons RUG d'origine sur la chaîne RugPull tout en émettant une quantité équivalente de jetons RUG sur la chaîne Osmosis.

(Source: Babylon)

Si nous supposons que John exécute avec succès une attaque à longue distance sur la chaîne RugPull, il peut malicieusement omettre la transaction qui a verrouillé les jetons RUG pour les envoyer à la chaîne Osmosis dans la nouvelle chaîne forkée. En conséquence, John acquerrait efficacement des jetons OSMO gratuitement.

Pour prévenir les attaques à longue portée, une période de déliaison des enjeux d'une certaine durée est nécessaire. Les acteurs malveillants ne peuvent pas exécuter une attaque à longue portée pendant la période de déliaison (s'ils tentent, ils seront confrontés à des pénalités de réduction). De plus, pendant cette période, les participants du réseau peuvent parvenir à un consensus social sur la chaîne canonique. Par conséquent, même si une attaque à longue portée se produit ultérieurement, il est peu probable que la chaîne fourchue malveillante soit acceptée par le réseau.

3.3 Réduisons le temps de déliaison de participation avec BTC Timestamping

La période de déliaison des enjeux est une méthode efficace pour prévenir les attaques à longue portée, mais elle présente certains inconvénients.

Le premier problème est qu'il repose sur un consensus social pour contrer les attaques. Bien que la communication hors chaîne entre les participants sur une période suffisamment longue puisse jouer un rôle crucial, ce n'est pas une solution infaillible à 100 %.

Le deuxième problème est que, comme mentionné précédemment, une période de déverrouillage plus longue affecte négativement l'expérience utilisateur et la liquidité.

Babylon introduit une solution appelée Bitcoin Timestamping, qui permet aux chaînes PoS de réduire considérablement les périodes de déstake à seulement quelques heures. Cela permet aux chaînes PoS d'enregistrer les données de bloc de chaîne canonique sur le réseau Bitcoin.

Avec le timestamping, même si des validateurs malveillants tentent une attaque à long terme et affirment que leur chaîne forkée est la chaîne canonique, leur attaque ne réussira pas—car les données de la chaîne canonique originale sont déjà enregistrées de manière sécurisée sur le réseau Bitcoin. Tant que la sécurité de Bitcoin reste intacte, l'attaque est garantie d'échouer. Cette approche éliminant le besoin de consensus social permet une réduction drastique de la période de déliaison requise.

(Source: Babylon)

Ici, Bitcoin Timestamping est enregistré en utilisant le code OP_RETURN dans le réseau Bitcoin. OP_RETURN est une instruction qui permet de stocker jusqu'à 80 octets de données arbitraires sur le réseau Bitcoin. Contrairement aux transactions Bitcoin régulières, OP_RETURN ne peut pas être utilisé pour des transferts de fonds et ne génère pas de UTXOs.

Une considération clé est de savoir si toutes les chaînes PoS peuvent créer directement des points de contrôle sur le réseau Bitcoin. Les blocs Bitcoin sont de petite taille, ont un temps de blocage de 10 minutes, et OP_RETURN ne peut stocker qu'un maximum de 80 octets de données. Si de nombreuses chaînes PoS devaient envoyer fréquemment des transactions de pointage, le réseau Bitcoin ne serait pas en mesure de gérer la charge.

Pour résoudre ce problème, Babylon introduit la Babylon Chain, qui agrège les checkpoints de plusieurs chaînes PoS via IBC, puis soumet un seul checkpoint agrégé au réseau Bitcoin.

Un élément clé de ce processus est le Relayer Vigilante, une entité responsable de la lecture des points de contrôle à partir d'un nœud de Babylone, de les empaqueter dans des transactions OP_RETURN, puis de les soumettre au réseau Bitcoin. Le système nécessite au moins un Relayer Vigilante honnête et actif pour fonctionner correctement.

(Source: Babylon)

L'horodatage BTC se déroule comme suit : les chaînes PoS soumettent des points de contrôle contenant des informations de bloc à la chaîne Babylon. La chaîne Babylon soumet ensuite un point de contrôle des blocs Babylon au réseau Bitcoin au dernier bloc de chaque époque.

(Source: Babylon)

Même si une attaque à longue portée se produit, le point de contrôle de la chaîne forkée malveillante aura toujours une horodatage postérieur à celui du point de contrôle de la chaîne canonique. Cela signifie que les participants du réseau peuvent simplement vérifier le point de contrôle du réseau Bitcoin pour identifier facilement les forks malveillants. Cette approche éliminant le besoin de consensus social, la période de déliaison de mise peut être réduite de plusieurs semaines à quelques heures seulement.

3.4 Plus rapide que le désaveu rapide

Le Bitcoin Timestamping de Babylon fait bien plus que simplement améliorer l'UX et l'efficacité de la liquidité en réduisant les périodes de déconsignation des chaînes PoS — il offre également divers avantages supplémentaires.

3.4.1 Finalité lente pour les transactions importantes

En adoptant une finalité lente grâce à Babylon, les chaînes PoS peuvent atteindre un niveau de sécurité comparable à Bitcoin. Lorsqu'un bloc PoS contenant une transaction spécifique est horodaté sur le réseau Bitcoin et confirmé par six blocs Bitcoin, la transaction devient irréversible tant que la sécurité de Bitcoin reste intacte.

Ce mécanisme est utile pour le traitement des transactions de grande valeur, telles que des achats immobiliers, où une sécurité absolue est nécessaire. De plus, pour les nouvelles zones Cosmos lancées, qui peuvent avoir une sécurité plus faible, la mise en œuvre d'une finalité lente peut fournir une couche supplémentaire de protection pour le traitement sécurisé des transactions.

3.4.2 Résistance à la censure au niveau du Bitcoin

L'estampillage temporel de Bitcoin peut également aider à restaurer la vivacité en cas d'attaque de censure sur une chaîne de PoS. Pour remédier à cela, Babylon introduit un concept spécial appelé mode rollup.

Dans une chaîne PoS traditionnelle, au moins deux tiers (2/3) des validateurs doivent être honnêtes pour maintenir la résistance à la censure. Cependant, avec le mode rollup de Babylon, seulement la moitié (1/2) des validateurs doivent être honnêtes pour atteindre la résistance à la censure, améliorant significativement la résilience de la chaîne contre les attaques.

(Source: Babylon)

Si un utilisateur de la chaîne PoS estime qu'une transaction spécifique est censurée, il peut soumettre une plainte de censure (la section rouge dans le diagramme) à la chaîne Babylon, lançant le processus d'entrée en mode rollup. La plainte de censure contient le hachage de la transaction censurée.

Si, après six confirmations de bloc Bitcoin, la transaction censurée suspectée n'a toujours pas été incluse dans la chaîne PoS, les validateurs honnêtes soumettront leurs vues de la chaîne PoS à Babylon. Si, après six confirmations de blocs Bitcoin supplémentaires, aucun point de contrôle lié à la transaction censurée n'est détecté dans aucun bloc Bitcoin, les validateurs honnêtes et les utilisateurs entreront en mode rollup.

En mode rollup, tout validateur peut proposer un ensemble de transactions PoS, et si les validateurs détenant au moins la moitié (1/2) de l'enjeu total signent l'ensemble, la transaction sera finalisée sur le réseau Bitcoin, empêchant ainsi efficacement la censure.

4. Comment fonctionne le jalonnement de Bitcoin

4.1 Aperçu du Staking Bitcoin

L'horodatage Bitcoin permet aux chaînes PoS de tirer parti de la sécurité de Bitcoin pour réduire les périodes de déliaison des enjeux et renforcer la résistance à la censure, mais cela n'utilise que partiellement la sécurité de Bitcoin.

Au-delà de la gestion des horodatages de Bitcoin, Babylon introduit le Bitcoin Staking, qui met en œuvre nativement le staking de BTC en utilisant le langage de script de Bitcoin. Cela permet à d'autres protocoles de preuve d'enjeu de bénéficier de la sécurité cryptéconomique des BTC mis en jeu. Le protocole de staking est conçu comme un plug-in modulaire, ce qui le rend facilement adaptable à divers protocoles de consensus de preuve d'enjeu.

Pour les détenteurs de BTC, le Bitcoin Staking de Babylon est une opportunité d'investissement attrayante car ils peuvent miser du BTC au niveau de sécurité du Bitcoin sans avoir à compter sur des entités externes, tout en gagnant des récompenses de protocoles externes.

Définissons quelques termes clés :

• Les protocoles qui tirent parti de la sécurité cryptéconomique du BTC misé via le jalonnement de Bitcoin de Babylon sont appelés BSN (Bitcoin Secured Networks) - analogues à @eigenlayerLe concept de services validés activement (AVS) de ‘s.
• Les entités qui reçoivent du BTC délégué des stakers et participent à la validation des BSN sont appelées fournisseurs de finalité, similaires aux opérateurs AVS d'EigenLayer.

Mais attendez—contrairement à Ethereum, le réseau Bitcoin n'est pas Turing-complet, ce qui rend difficile la mise en œuvre de contrats de participation complexes. Alors comment Babylon y parvient-elle ?

Explorons les détails avec un exemple du blog de Babylon.

4.2 Comment le contrat de mise en jeu est mis en œuvre

4.2.1 Verrouillage

// Contrat V0 : ajout d'une condition de verrouillage à l'UTXO de mise en jeu d'Alice

condition-1 (verrouillage): time_lock = 1000 & alice_public_key

Supposons qu'Alice mise en jeu du BTC et agisse également en tant que fournisseur de finalité. Pour mettre en œuvre la mise en jeu du BTC, un mécanisme de verrouillage du BTC est requis. Cela est réalisé en définissant l'une des conditions de dépense de UTXO de telle sorte que seule Alice (la propriétaire du BTC) puisse retirer les fonds après une certaine période de temps (time_lock = 1000) en utilisant sa clé publique alice.

4.2.2 Slash

// Contrat V1: ajout de pénalités naïves

condition-1 (verrouillage): time_lock = 1000 & alice_public_key; OU

condition-2 (slashing): alice_eots_public_key

Un des éléments essentiels qui doit être mis en œuvre dans le staking est le slashing. Si une action malveillante se produit, un mécanisme d'incitation peut être appliqué en brûlant les BTC mis en jeu. Pour ce faire, une deuxième condition de dépense de UTXO est définie afin que le slashing puisse se produire si quelqu'un détient la clé EOTS d'Alice.

Ici, EOTS (Extractable One-Time Signature) est une signature implémentée à l'aide de signatures Schnorr, qui a été introduite après la mise à niveau de Taproot de Bitcoin. En termes simples, il s'agit d'un algorithme qui garantit que si un acteur malveillant double-signe deux blocs différents à la même hauteur en utilisant la même clé, sa clé secrète est révélée publiquement.

En examinant cela de plus près, une signature Schnorr se compose d'une clé privée x, d'une clé publique P=xG et d'un nonce aléatoire k. Le processus de signature est le suivant: un nonce aléatoire k est généré et la valeur publique R=kG est calculée à partir du nonce. Ensuite, une valeur de hachage e est calculée à partir du message M et de R, et la valeur de signature s est calculée en fonction du nonce et de e, où s = k + ex. La signature finale de Schnorr se compose de (s, R).

L'idée principale de l'EOTS est que si la même clé est utilisée deux fois pour signer, la clé privée est exposée. Si Alice signe deux messages différents en utilisant le même nonce k, alors la première signature est s1= k + e_1x et la deuxième signature est s2= k + e_2x. Étant donné que s1, s2, e1, e2 sont publiquement connus, n'importe qui peut résoudre la clé privée x d'Alice en utilisant l'équation x=(s1 - s2)/(e1 - e2).

En utilisant ce mécanisme, si Alice signe malicieusement deux messages différents en utilisant la même clé EOTS lors du processus de validation de BSN, toute personne qui détecte cela peut extraire la clé secrète EOTS d'Alice. Une fois la clé secrète EOTS révélée, l'attaquant peut soit voler les BTC mis en jeu par Alice, soit brûler les BTC mis en jeu par Alice en guise de pénalité.

4.2.3 Application de la combustion

// Contrat V2

condition-1 (verrouillage): time_lock = 1000 & alice_public_key; OU

condition-2 (slashing): alice_eots_public_key & covenant_committee_quorum

// Transaction de réduction V0

entrées :

• input-1 : l'UTXO de mise en jeu, dépensé en utilisant la condition-2 ci-dessus

sorties :

• output-1: value = 0.99 Bitcoin, owner = 0000...0000

// Pré-approbation V0: application de la combustion

// Le comité du pacte pré-signe la transaction de réduction ci-dessus comme pré-approuvé

Puisque nous avons déjà discuté des conditions dans lesquelles le slashing se produit, examinons maintenant comment le slashing est effectivement appliqué. Appliquer le slashing est crucial car, si Alice se livre à un comportement malveillant, elle pourrait tenter de retirer ses BTC avant que quelqu'un ne détecte la faute, n'extraie sa clé secrète EOTS et ne brûle ses BTC.

Pour éviter cela, le slashing doit être mis en œuvre de manière à transférer de force le BTC vers une adresse de combustion prédéfinie (0000... 0000). Pour y parvenir, la deuxième condition de dépense de l’UTXO comprend un quorum du Comité de l’Alliance. Le Comité du Pacte est chargé de vérifier la légitimité de l’ampérisation. En intégrant un schéma multi-signature (M-of-N), le système garantit qu’Alice ne peut pas retirer unilatéralement ses BTC dans son propre portefeuille avant que le slashing ne soit exécuté.

L'avantage de cette approche est que, tant qu'Alice se comporte de manière honnête, sa signature EOTS n'est jamais exposée, ce qui signifie que le Covenant Committee ne peut pas saisir ses fonds. Par conséquent, Alice n'a pas besoin de faire confiance au Covenant Committee, car ils ne peuvent pas agir contre elle à moins qu'elle ne se livre à un comportement malveillant.

4.2.4 Safe Delegation

// Contrat V3 : activation de la délégation sécurisée

condition-1 (verrouillage): time_lock = 1000 & alice_public_key; OU

condition-2 (slashing): alice_public_key & validator_eots_public_key & covenant_committee_quorum

// Transaction de réduction V0

entrées :

• input-1 : le staking UTXO, dépensé en utilisant la condition-2 ci-dessus

sorties:

• output-1: value = 0.99 Bitcoin, owner = 0000...0000

// Pré-approbation V1

// Alice pré-signe la transaction de réduction en tant qu'approbation préalable.

Le comité du pacte pré-signe la réduction du tx en tant que pré-approbation.

Alice peut directement miser BTC et participer à la validation d'autres protocoles PoS en tant que fournisseur de finalité. Cependant, la plupart des utilisateurs choisiront de déléguer leur mise en jeu de BTC.

Pour mettre en œuvre cela, l'ajout de la clé EOTS du validateur à la deuxième condition garantit que si le validateur se livre à un comportement malveillant, les BTC d'Alice peuvent être brûlés. Cependant, le problème ici est que si le validateur collabore avec le comité du covenant, ils pourraient voler les BTC d'Alice, obligeant Alice à faire confiance au validateur.

Une solution simple à ce problème consiste également à inclure la clé publique d'Alice dans la deuxième condition. Ainsi, brûler du BTC nécessiterait également la signature d'Alice, empêchant le vol non autorisé de BTC.

Pour ce faire, Alice pré-signe une transaction indiquant que "si une réduction survient, BTC doit être envoyé à une adresse de burn." Dans ce cas, si le validateur agit de manière malveillante et que sa clé EOTS est exposée, et si le comité de covenant exécute une multi-signature, les BTC seront envoyés à l'adresse de burn, appliquant ainsi le processus de réduction.

4.2.5 Prévention des attaques malveillantes grâce à l’application du slashing atomique

/ Contrat V3

condition-1 (verrouillage): time_lock = 1000 & alice_public_key; OU

condition-2 (slashing): alice_public_key & validator_eots_public_key & covenant_committee_quorum

// Slashing transaction V0

entrées :

• input-1 : l'UTXO de mise en jeu, dépensé en utilisant la condition-2 ci-dessus

sorties :

• output-1: value = 0.99 Bitcoin, owner = 0000...0000

// Pré-approbation V2: application de l'atomique slashing lors de la délégation

La pré-approbation d’Alice est une signature d’adaptateur du slashing tx

// elle a été générée à l'aide de la clé publique EOTS du validateur.

Le comité de la convention pré-signe la réduction de la tx comme pré-approuvé.

Que se passe-t-il si un validateur malveillant cible uniquement des validateurs spécifiques pour être pénalisés? Pour prévenir cela, Babylone introduit des signatures d'adaptateur.

Alice chiffre sa signature en utilisant la clé publique EOTS du validateur comme une signature d'adaptateur. Si le validateur tente de pénaliser uniquement Alice, il doit utiliser sa clé privée EOTS. En raison de la nature des signatures d'adaptateur, cela entraînerait l'exposition de la clé privée EOTS du validateur, supprimant tout incitatif pour les validateurs à se livrer à un comportement malveillant.

4.2.6 Mise en œuvre de l’élimination partielle

// Contrat V3

condition-1 (verrouillage): time_lock = 1000 & alice_public_key; OU

Condition-2 (Slashing) : alice_public_key & validator_eots_public_key & covenant_committee_quorum

// Transaction de déflation V1 : activation de la déflation partielle

entrées :

• input-1 : l'UTXO de mise en jeu, dépensé en utilisant la condition-2 ci-dessus

sorties :

• output-1: value = 0.09 Bitcoin, owner = 0000...0000

• output-2: value = 0.9 Bitcoin,

conditions:

• condition-1: time_lock = 500 & alice_public_key

// Pré-approbation V2

// La pré-approbation d'Alice est une signature d'adaptateur de la transaction de réduction

qu’elle a générée à l’aide de la clé publique EOTS du validateur.

// Le comité de la convention pré-signe la transaction de réduction comme son pré-approbation.

Mais ne pensez-vous pas que brûler tous les bitcoins en cas de slashing est trop extrême ? Pour résoudre ce problème, seule une partie du bitcoin (par exemple, brûler seulement 10 % tout en restituant les 90 % restants après une certaine période) peut être brûlée. Cela peut être mis en œuvre en divisant les sorties de la transaction de slashing en deux, comme décrit ci-dessus.

4.2.7 Restaking Plus!

// Contrat V4: Activation du restaking

condition-1 (verrouillage): time_lock = 1000 & alice_public_key; OU

condition-2 (slashing): alice_public_key & any signature from list[validator_eots_public_key] & covenant_committee_quorum

Le BTC délégué d'Alice peut participer à la validation de plusieurs protocoles PoS, et pas seulement à un seul. Si un validateur participe à la validation de différents protocoles PoS en utilisant la même clé EOTS, toute fuite à un endroit pourrait affecter les autres systèmes. Par conséquent, les fournisseurs de finalité de Babylon doivent utiliser des clés EOTS différentes pour différents systèmes PoS, et une liste de clés EOTS est introduite dans la deuxième condition.

4.3 Résumé

Contrairement aux réseaux PoS tels qu'Ethereum ou Solana, le réseau Bitcoin fonctionne sur PoW, donc le concept de mise en jeu n'existe pas intrinsèquement. Cependant, Babylon a mis en œuvre le verrouillage, la réduction et les fonctionnalités de délégation du BTC nécessaires à la mise en jeu grâce aux caractéristiques des UTXO, au langage de script de Bitcoin et à divers algorithmes de signature. Cela permet aux détenteurs de BTC de gagner des profits supplémentaires de manière native en utilisant le BTC, sans avoir besoin de ponts ou de services de garde.

5. Libérer le potentiel du BTC dans le monde décentralisé

Mis à part le Lightning Network, aucun autre protocole n'hérite pleinement de la sécurité du réseau Bitcoin. Cependant, tout comme le réseau Bitcoin, la fonctionnalité du Lightning Network est assez limitée, et il est trop précieux de renoncer à la sécurité robuste et à la liquidité massive du Bitcoin.

Babylon a permis l'utilisation de la sécurité de Bitcoin de deux manières différentes grâce à l'horodatage Bitcoin et au jalonnement Bitcoin. Le premier utilise Bitcoin comme serveur d'horodatage pour éviter les annulations de transaction ou les forks malveillants, tandis que le second exploite la liquidité puissante du BTC en tant que sécurité cryptonumérique, permettant aux détenteurs de BTC de gagner des profits supplémentaires de manière native.

Actuellement, environ 55 000 BTC sont déposés à Babylone, ce qui est même avec un plafond de dépôt fixé par Babylone. Environ 3,9 % de l’offre totale d’ETH est remisée sur EigenLayer. Compte tenu de cela, même si les détenteurs de BTC peuvent être prudents quant à l’utilisation de BTC, le potentiel de croissance de Babylon, avec seulement environ 0,2 % de l’offre totale de BTC actuellement mise en jeu, vaut la peine d’être pris en compte.

Démenti:

1. Cet article est reproduit de [100y.eth]. Tous les droits d'auteur appartiennent à l'auteur original [100y.eth]. If there are objections to this reprint, please contact the Gate Apprendre équipe, et ils s’en occuperont rapidement.
2. Clause de non-responsabilité : 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. L’équipe de Gate Learn fait des traductions de l’article dans d’autres langues. La copie, la distribution ou le plagiat des articles traduits sont interdits, sauf mention contraire.