Disponibilité mixte des données, analyse de la fonction de retrait forcé BitVM sur BOB
TechFlow SélectionTechFlow Sélection
Disponibilité mixte des données, analyse de la fonction de retrait forcé BitVM sur BOB
BOB a publié pour la première fois sur son blog officiel la « fonction de retrait forcé BitVM », marquant une avancée concrète et significative pour la première fois chez un Layer2 BTC concernant la fonction spécifique de « retrait forcé ».
Dédié à des analyses Web3 approfondiesRésumé :
-
Les Layer2 devraient posséder une résistance à la censure équivalente à celle des blockchains publiques Layer1 sur lesquelles elles reposent ;
-
Sur BOB, les utilisateurs peuvent déjà forcer le retrait de leurs actifs depuis BOB vers Ethereum via une transaction sur Ethereum ;
-
Pour le pont BitVM, BOB travaille à intégrer le réseau Bitcoin comme moyen pour les utilisateurs d'exécuter des transactions sur BOB ;
-
Les utilisateurs Bitcoin peuvent retirer leurs actifs BTC depuis BOB sans avoir besoin d'envoyer de transaction vers BOB.
Le 4 février 2025, le projet Layer2 hybride BOB a publié publiquement pour la première fois sur son blog officiel la fonctionnalité « Retrait forcé BitVM », marquant une avancée concrète majeure dans la mise en œuvre du mécanisme de « retrait forcé » pour les Layer2 BTC. Cet événement revêt une importance primordiale pour l'écosystème Bitcoin et pour l'industrie dans son ensemble.
Vitalik a souligné que la capacité des utilisateurs à retirer facilement leurs actifs d'une Layer2 vers une Layer1 constitue un indicateur de sécurité essentiel. La fonctionnalité de « retrait forcé » est pour une Layer2 ce qu'une sortie de secours est dans le monde réel : cruciale en cas d'urgence. Dans l'écosystème des plateformes Layer2 Ethereum, qui gèrent des actifs s'élevant à des dizaines de milliards de dollars, la capacité de retirer en toute sécurité ses actifs vers la Layer1 est devenue une infrastructure indispensable.
Pour les blockchains Layer2 utilisant le protocole EVM, des solutions bien établies de retrait forcé et de capsule d'évacuation existent déjà sur le marché afin d’assurer aux utilisateurs un retrait sécurisé et rapide vers la Layer1. Examinons maintenant comment BOB met en œuvre cette fonctionnalité de retrait forcé pour les Layer2 BTC grâce à ce blog.
L’une des propriétés fondamentales des Layer2 est que leurs transitions d’état doivent continuer même si le séquenceur est hors ligne. Les Layer2 atteignent cet objectif en lisant et écrivant leur état via une couche de disponibilité des données (DA), pouvant être mise à jour indépendamment de la Layer2. Ainsi, même si le séquenceur tombe en panne ou refuse les transactions des utilisateurs, ces derniers peuvent imposer l’exécution de leurs transactions. En effet, si le séquenceur rejette systématiquement les transactions ou subit une panne prolongée, cela peut entraîner de lourdes pertes financières.
Par exemple, lors d’un incident de downtime sur Solana, certains utilisateurs n’ont pas pu renflouer leurs positions face à un risque de liquidation, exposant ainsi des millions de dollars d’actifs au danger. De tels scénarios de refus de service ont des conséquences économiques non négligeables.
Concernant le pont BitVM de BOB, une question intéressante se pose. Actuellement, BOB utilise les blobs EIP-4844 d’Ethereum comme couche DA. Bien que les utilisateurs d’Ethereum puissent facilement retirer leurs actifs via le pont BitVM vers le réseau Bitcoin, cette opération exige qu’ils détiennent des ETH sur Ethereum pour payer les frais de gaz.
Cela nuit encore à l’expérience utilisateur. Idéalement, un utilisateur Bitcoin ne devrait avoir besoin que de BTC sur le réseau Bitcoin pour retirer ses BTC depuis BOB. BOB étudie donc une solution hybride : utiliser par défaut Ethereum comme couche DA, tout en permettant aux utilisateurs d’imposer l’inclusion de leurs transactions sur BOB via des transactions spéciales sur Bitcoin.
Disponibilité des données (DA) et contexte de la dérivation
Le processus de dérivation est crucial pour les blockchains Layer2 : tout l’état de la Layer2 de BOB doit être reconstruit à partir de la Layer1 et de la couche DA. Cela permet à la Layer2 de bénéficier de la même résistance à la censure que la couche DA (dans ce cas, Ethereum).
En termes simples, dans les rollups (en particulier ceux utilisant OP Stack), nous avons deux types de données sur la Layer1 :
-
Les transactions de dépôt envoyées au contrat « OptimismPortal ». Ce sont des transactions effectuées par les utilisateurs sur Ethereum, généralement pour déposer des actifs sur BOB. Ces dépôts peuvent aussi servir à exécuter d'autres transactions sur BOB.
-
Les lots soumis par le séquenceur (ou plus précisément par l’op-batcher) à partir du traitement des transactions Layer2. Ils incluent toutes les transactions directement effectuées sur BOB et finissent par être inclus dans les blobs Ethereum.
Bitcoin comme couche DA
Si l’on souhaite utiliser Bitcoin comme couche DA, pourquoi ne pas basculer complètement ? La principale raison réside dans le coût. L’espace de stockage disponible sur Bitcoin est très limité (environ 4 Mo toutes les 10 minutes), rendant le stockage coûteux.
Toutefois, dans ce cas précis, BOB pourrait continuer à utiliser Ethereum comme couche DA « principale » pour publier l’intégralité de ses données transactionnelles, tout en ajoutant Bitcoin comme couche de secours hautement résistante à la censure en cas d’indisponibilité d’Ethereum. En pratique, Ethereum deviendrait alors la couche DA optimiste, tandis que Bitcoin servirait de solution de dernier recours, coûteuse mais tolérante aux pannes.
Pipeline de dérivation hybride
La solution de base consiste à intégrer Bitcoin au pipeline de dérivation de BOB, afin que BOB (notamment le « op-node ») traite les entrées selon l’ordre suivant :
-
Transactions de retrait forcé sur Bitcoin (ajoutées spécifiquement pour BOB) ;
-
Dépôts sur le contrat OptimismPortal de BOB sur Ethereum (standard OP Stack) ;
-
Lots provenant de l’op-batcher sur Ethereum (standard OP Stack).
Une solution envisageable serait d’encoder les transactions de retrait forcé Bitcoin dans le pipeline de dérivation de BOB. Toutefois, cette approche est encore en cours d’étude et pourrait évoluer.
Transaction de retrait forcé Bitcoin
Trois éléments sont nécessaires à BOB pour créer une transaction de retrait forcé :
-
Construire une transaction de retrait forcé sur Bitcoin.
-
Stocker la transaction de retrait forcé dans la limite de taille d’un bloc Bitcoin.
-
Gérer les frais de gaz associés à la transaction de retrait forcé Bitcoin.
1. Construction de la transaction de retrait forcé sur Bitcoin
La transaction de dépôt OP Stack suit la structure suivante :
-
bytes32 sourceHash : hachage source, identifiant de manière unique l’origine du dépôt.
-
address from : adresse du compte expéditeur.
-
address to : adresse du compte destinataire, vide (adresse de longueur nulle) si la transaction correspond à la création d’un contrat.
-
uint256 mint : valeur ETH frappée sur la L2.
-
uint256 value : valeur ETH envoyée au compte destinataire.
-
uint64 gas : limite de gaz pour la transaction L2.
-
bool isSystemTx : si vrai, la transaction n’interagit pas avec le pool de gaz du bloc L2.
-
bytes data : données d’appel.
La transaction de retrait forcé doit inclure la transaction de retrait encodée dans le champ « data » de la transaction de dépôt. Cela se fait en créant sur BOB une transaction qui déclenche un retrait vers Bitcoin, fonctionnant exactement comme une transaction envoyée depuis Ethereum.
Nous pouvons ensuite stocker sur Bitcoin une version (compressée) de cette transaction de retrait forcé, incluant toutes les données ci-dessus.
2. Stockage de la transaction de retrait forcé sur Bitcoin
Comme les données de la transaction de retrait forcé dépassent généralement la taille maximale recommandée pour OP_RETURN, BOB pourrait utiliser une sortie Taproot pour stocker les données.
Alors qu’il est facile d’identifier une transaction de dépôt sur Ethereum (qui peut inclure un retrait), car elle est envoyée au contrat OptimismPortal de BOB, identifier une transaction de retrait forcé sur Bitcoin est plus complexe.
Sérialisation des données : les transactions de retrait forcé sont sérialisées via un script Taproot intégré dans une structure dite « enveloppe ». Ces éléments sont des noop sur le réseau Bitcoin, similaires à ceux utilisés par les ordinaux. Nous adaptons cette structure à nos besoins.
Unset
OP_FALSE OP_IF
OP_PUSH "bob"
OP_1
OP_PUSH "transaction"
OP_0
OP_PUSH $WITHDRAWAL_TRANSACTION_DATA
OP_ENDIF
Schéma de validation en deux étapes :
À l’instar des ordinaux, l’utilisateur doit envoyer deux transactions sur Bitcoin :
-
Transaction de validation (commit) : crée une sortie Taproot qui s’engage à contenir le script avec les données d’inscription. Cette transaction ne révèle pas encore les données ; une deuxième transaction de la part du nœud complet BOB ou du séquenceur est nécessaire pour inclure la transaction de retrait.
-
Transaction de révélation (reveal) : dépense la sortie de la transaction de validation, révélant ainsi l’inscription sur la chaîne, c’est-à-dire exposant la transaction de retrait de l’utilisateur pour inclusion dans BOB.
3. Gestion des frais de gaz pour la transaction de retrait forcé Bitcoin
Concernant les frais de gaz, BOB envisage actuellement deux options :
-
Fixer les frais de gaz de la transaction de retrait forcé Bitcoin à 0 et déduire les frais du solde ETH de l’utilisateur sur BOB. Seuls les utilisateurs disposant d’ETH sur BOB pourraient alors forcer un retrait. Ce n’est toutefois pas idéal, car cela oblige l’utilisateur à détenir ETH sur BOB pour initier un retrait, excluant ainsi ceux qui ne possèdent que du BTC sur Bitcoin.
-
Les frais de gaz sont payés par l’utilisateur en BTC sur Bitcoin. Le réseau BOB doit disposer sur Bitcoin d’une adresse capable de recevoir des BTC, puis convertir efficacement ces BTC reçus en ETH sur BOB afin de couvrir les coûts de gaz sur la Layer1 ainsi que les frais d’exécution. Cette option pourrait être implémentée en utilisant le BOB Gateway et en définissant l’adresse EVM du DAO BOB comme destinataire des BTC.
Conclusion
Quiconque peut déterminer l’état de BOB simplement en consultant les données présentes sur Bitcoin et Ethereum :
- Lire toutes les transactions de retrait sur Bitcoin. Chaque retrait est encodé comme deux transactions : une transaction de validation et une transaction de révélation. Il s’agit d’une extension de notre implémentation OP Stack, renforçant ainsi notre pipeline de dérivation.
- Lire toutes les transactions envoyées au contrat OptimismPortal de BOB sur Ethereum. Cela fait déjà partie du pipeline de dérivation OP Stack standard.
- Lire toutes les transactions effectuées directement sur BOB et intégrées sous forme de lots sur Ethereum. Il est important de noter que les nœuds complets ne lisent pas directement les transactions confirmées depuis le séquenceur, mais depuis les blobs Ethereum. Cela fait déjà partie du pipeline de dérivation OP Stack standard.
Défis techniques
Cohérence des données : bien qu’il soit essentiel d’assurer la cohérence des données entre Ethereum et Bitcoin, la simple présence des données sur les deux chaînes ne garantit pas leur validité. Pour être considérées comme légitimes, les transactions doivent représenter une transition d’état valide selon la fonction de transition d’état du rollup. La solution doit donc intégrer une logique de vérification au sein de l’op-node (ou d’une autre implémentation de couche de consensus), qui valide préalablement chaque transaction avant son acceptation.
Preuves de fraude et validité : les systèmes de preuve de fraude de BitVM et d’Ethereum doivent tous deux être améliorés pour traiter les données provenant des deux chaînes, ce qui pourrait complexifier le processus de résolution des litiges. Pour y remédier, BOB doit correctement comptabiliser les transactions potentielles provenant de Bitcoin et d’Ethereum dans le cadre du pont BitVM et du règlement sur Ethereum.
Augmentation du stockage : en outre, les nœuds BOB du réseau font face à des exigences accrues en matière de stockage et de bande passante, car ils doivent traiter et stocker des données provenant à la fois de Bitcoin et d’Ethereum. Cependant, ce problème peut être atténué en exigeant que les transactions BOB sur Bitcoin soient incluses dans les blobs Ethereum et fassent référence au dernier bloc Bitcoin. Ainsi, les nœuds n’ont besoin de synchroniser que les blocs Bitcoin les plus récents.
La présentation publique par BOB de la fonctionnalité de « retrait forcé » sur les Layer2 BTC représente une avancée majeure pour le modèle hybride de Layer2 combinant la sécurité de Bitcoin à l’innovation d’Ethereum. Sur ce point spécifique, BOB associe la résistance à la censure de Bitcoin à sa stack rollup, assurant ainsi la sécurité des actifs des utilisateurs même dans des conditions extrêmes.
À propos de BOB (Build on Bitcoin)
BOB (Build on Bitcoin) est un réseau Layer-2 hybride qui combine les atouts de Bitcoin et d’Ethereum, visant à devenir la « maison du DeFi BTC ». Son modèle Hybride L2 unique fusionne les forces des deux écosystèmes : la sécurité et le capital BTC inutilisé de Bitcoin, ainsi que l’innovation DeFi et la polyvalence d’Ethereum. En positionnant le BTC comme pilier d’un nouveau système financier décentralisé, BOB permet de débloquer de nouveaux cas d’usage et des milliers de milliards de liquidités BTC. Grâce au protocole BitVM, BOB hérite parfaitement de la sécurité du réseau Bitcoin et établit des ponts minimisant la confiance entre BOB, Bitcoin, Ethereum et d’autres réseaux L1. Ainsi, la Layer2 hybride n’a pas besoin de ponts inter-chaînes tiers pour assurer l’interopérabilité, centralisant aisément la liquidité autour du réseau Bitcoin plutôt que de la disperser entre différentes chaînes.
BOB bénéficie du soutien d’investisseurs institutionnels de premier plan tels que Castle Island Ventures, Coinbase Ventures, Ledger Cathay Ventures et IOSG.
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
@build_on_bob
