Les utilisateurs de Bitcoin ne devraient avoir besoin que de BTC sur Bitcoin pour forcer un retrait de leurs BTC de BOB vers Bitcoin. Nous travaillons sur une solution hybride : utiliser par défaut Ethereum en tant que DA tout en permettant aux utilisateurs de forcer l’inclusion de transactions sur BOB via une transaction spéciale sur Bitcoin. Nous sommes ravis de partager notre travail en cours dans cet article de blog.

tl;dr

• Les L2 devraient avoir la même résistance à la censure que les L1 sur lesquels ils sont basés
• Sur BOB, les utilisateurs peuvent déjà retirer de force leurs actifs de BOB vers Ethereum via une transaction Ethereum
• Pour son pont BitVM, BOB travaille à intégrer Bitcoin comme moyen pour les utilisateurs d'appliquer des transactions sur BOB
• Les utilisateurs de Bitcoin pourront retirer leur BTC de BOB sans avoir à envoyer une transaction à BOB

L'une des principales caractéristiques des L2 est que leur état doit progresser même lorsque le le séquenceur est hors ligne. Les L2 y parviennent en lisant et en écrivant leur état à partir d'une couche de disponibilité des données (DA) qui peut être mise à jour indépendamment du L2 en ligne. De cette façon, les utilisateurs peuvent forcer l'inclusion de leurs transactions même lorsque le séquenceur est hors ligne ou que le séquenceur n'accepte pas leurs transactions directement.

Pour le pont BitVM de BOB, cela pose un problème intéressant. BOB utilise actuellement des blobs Ethereum EIP-4844 comme couche DA. Les utilisateurs sur Ethereum peuvent facilement déclencher des retraits vers Bitcoin via le pont BitVM. Cependant, cela nécessite que les utilisateurs aient de l'ETH sur Ethereum.

Ce n'est pas assez bon pour nous : les utilisateurs de Bitcoin ne devraient avoir besoin que de BTC sur Bitcoin pour forcer un retrait de leur BTC de BOB vers Bitcoin. Nous travaillons sur une solution hybride : en optant par défaut pour Ethereum en tant que DA tout en permettant aux utilisateurs d'inclure de force des transactions sur BOB via une transaction spéciale sur Bitcoin. Nous sommes impatients de partager notre travail en cours dans ce billet de blog.

Un aperçu sur DA et la dérivation

Le processus de dérivationest assez important pour les L2 : l'état L2 entier de BOB doit être construit à partir de la couche L1 et de la couche DA. Cela permet aux L2 de bénéficier de la même résistance à la censure que la couche DA, dans notre cas, Ethereum.

Simplifié, dans les rollups (en particulier les chaînes OP Stack), nous avons deux types de données sur le L1:

• Transactions de dépôteffectuées sur le contrat "OptimismPortal". Ce sont les transactions effectuées par les utilisateurs sur Ethereum généralement pour déposer leurs actifs dans BOB. Ces transactions de dépôt peuvent également être utilisées pour exécuter d'autres transactions sur BOB.
• Lots soumis par le séquenceur (ou le lot opérationnel pour être plus précis) à partir des transactions L2. Il s'agit de toutes les transactions effectuées directement par les utilisateurs sur BOB et qui sont finalement incluses dans les blobs Ethereum.

Bitcoin en tant que couche DA

Si nous voulons Bitcoin en tant que couche DA, pourquoi ne pas passer complètement à l'utilisation de Bitcoin comme couche DA? La réponse est surtoutcoût. Bitcoin a très peu d'espace de stockage disponible (environ 4 Mo environ toutes les 10 minutes), et donc, le coût de stockage est élevé.

Cependant, dans notre cas, BOB peut toujours utiliser Ethereum comme sa couche DA "principale" où il publie l'ensemble de ses données de transaction, mais ajouter Bitcoin comme une couche de secours hautement résistante à la censure si Ethereum DA n'est pas disponible. Essentiellement, Ethereum devient la couche DA optimiste tandis que Bitcoin devient le dernier recours coûteux mais tolérant aux pannes.

Pipeline de dérivation hybride

La solution de base consiste à ajouter Bitcoin à BOB dans le cadre du pipeline de dérivation, de sorte que BOB (et spécifiquement le "nœud op") traite les entrées dans cet ordre :

1. Transactions de retrait forcé de Bitcoin (nouvellement ajoutées spécifiquement pour BOB)
2. Les dépôts Ethereum vers le contrat OptimismPortal (norme OP Stack) de BOB
3. Lots Ethereum depuis op-batcher (norme OP Stack)

Plongeons dans une solution possible pour encoder les transactions de retrait Bitcoin forcé dans le pipeline de dérivation BOB. Notez que cela est encore en cours de recherche, il est donc possible que des changements soient apportés.

Transactions forcées de retrait de Bitcoin

Nous aurons besoin de trois parties pour créer une transaction de retrait forcé :

1. Construisez la transaction de retrait forcé sur Bitcoin.
2. Stockez la transaction de retrait forcé sur Bitcoin dans les limites de taille de Bitcoin.
3. Gérer les frais de gaz pour la transaction de retrait forcé sur Bitcoin.

1. Construisez la transaction de retrait forcé

Une pile OPtransaction de dépôt a la structure suivante :

• bytes32 sourceHash: la source-hash, identifie de manière unique l'origine du dépôt.
• adresse de : L'adresse du compte de l'expéditeur.
• adresse à : L'adresse du compte du destinataire, ou l'adresse nulle (de longueur zéro) si la transaction déposée est une création de contrat.
• uint256 mint: La valeur de ETH à générer sur L2.
• value uint256: La valeur ETH à envoyer au compte du destinataire.
• uint64 gas: La limite de gaz pour la transaction L2.
• bool isSystemTx : Si vrai, la transaction n'interagit pas avec le pool de gaz bloc L2.
• données d'octets : Le calldata.

Une transaction de retrait forcé nécessite d'inclure la transaction de retrait encodée dans le champ de données de la transaction de dépôt. Cela est fait en créant la transaction sur BOB qui déclenche le retrait de BOB vers Bitcoin et fonctionnerait exactement de la même manière que si la transaction était envoyée depuis Ethereum.

Nous pouvons alors stocker une version (compressée) de la transaction de retrait forcé sur Bitcoin qui inclut toutes les données mentionnées ci-dessus.

2. Stockez la transaction de retrait forcé sur Bitcoin

Comme les données de la transaction de retrait forcé sont plus grandes que ce qui devrait normalement être stocké dans une sortie OP_RETURN, nous utiliserons probablement une Taprootsortie pour stocker les données.

Bien qu'il soit facile d'identifier une transaction de dépôt (qui peut inclure un retrait) sur Ethereum car elle est envoyée au contrat OptimismPortal de BOB, il n'est pas aussi facile d'identifier une transaction de retrait forcé sur Bitcoin.

Serialization des données : la transaction de retrait forcé est sérialisée à l'aide de scripts Taproot dans une structure « enveloppe ». Ceux-ci sont des noops sur le réseau Bitcoin et sont utilisés, par exemple, pour les ordinaux également. Nous ajustons la structure pour répondre à nos besoins.

Non défini
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/dévoilement en deux phases :
Comme pour les Ordinaux, les utilisateurs devront soumettre deux transactions à Bitcoin :

• Commit Transaction : Crée une sortie Taproot s'engageant à exécuter le script contenant le contenu de l'inscription. Cette transaction ne révèle pas encore les données et nous aurons besoin de la deuxième transaction pour que les nœuds complets BOB et les séquenceurs incluent la transaction de retrait.
• Révéler la transaction : dépense la sortie de la transaction d'engagement, révélant l'inscription on-chain, c'est-à-dire révélant la transaction de retrait de l'utilisateur pour inclusion dans BOB.

3. Gérer les frais de gaz pour la transaction de retrait forcé

C'est le problème le plus ouvert à ce jour, avec deux options actuellement à l'étude:

• Définissez le gaz à 0 pour la transaction de retrait forcé sur Bitcoin et déduisez les frais de gaz du solde ETH de l'utilisateur sur BOB. De cette façon, seuls les utilisateurs qui ont de l'ETH sur BOB peuvent forcer les retraits. Cependant, ce n'est pas une bonne option car cela nécessiterait aux utilisateurs d'avoir de l'ETH sur BOB pour forcer les retraits, c'est-à-dire que les utilisateurs qui ont du BTC sur Bitcoin ne peuvent pas forcer les retraits.
• Les utilisateurs paient des frais de gaz en BTC sur Bitcoin. Le réseau BOB aurait besoin d'avoir une adresse sur Bitcoin qui peut recevoir du BTC et échangerait efficacement le BTC reçu par l'utilisateur en ETH sur BOB pour payer les coûts de gaz de la partie L1 ainsi que les coûts d'exécution. Cette option est probablement utilisée en Passerelle BOBet en définissant l'adresse EVM de BOB DAO comme bénéficiaire du BTC.

Nous expérimentons également avec plus d'idées, alors restez à l'écoute pour plus de mises à jour !

Mettre tout ensemble

N'importe qui peut déterminer l'état de BOB en ne faisant que vérifier les données sur Bitcoin et Ethereum :

1. Lire toutes les transactions de retrait de Bitcoin. Celles-ci sont encodées sous la forme de deux transactions pour chaque retrait, c'est-à-dire une transaction de validation et une transaction de révélation. C'est là l'ajout que nous apportons à la pile OP et à l'amélioration du pipeline de dérivation.
2. Lisez toutes les transactions effectuées vers le contrat OptimismPortal de BOB sur Ethereum. Cela fait déjà partie du pipeline de dérivation de la pile OP standard.
3. Lisez toutes les transactions effectuées directement sur BOB et intégrées dans des lots sur Ethereum. Il est important de noter que les nœuds complets ne lisent pas directement à partir du séquenceur pour recevoir des transactions confirmées, mais ils lisent à partir des blocs Ethereum. Cela fait déjà partie du pipeline de dérivation de la pile OP standard.

Défis techniques

Consistance des données : Bien qu'il soit important de garantir la consistance des données entre les chaînes Ethereum et Bitcoin, la simple présence des données de transaction sur les deux chaînes ne garantit pas leur validité. Les transactions doivent représenter des transitions d'état valides selon la fonction de transition d'état du rollup pour être considérées comme légitimes. La solution nécessite la mise en œuvre d'une logique de validation à l'intérieur de l'op-node (ou d'autres implémentations de couche de consensus) qui vérifie d'abord si une transaction entraîne un changement d'état valide avant de l'accepter.

Preuves de fraude et validité: Le système de preuve de fraude pour BitVM et Ethereum doit être amélioré pour gérer les données des deux chaînes, ce qui pourrait rendre la résolution des litiges plus complexe. Pour remédier à cela, nous devons prendre en compte avec précision les transactions possibles de Bitcoin et Ethereum en tant que partie du pont BitVM et du règlement de BOB sur Ethereum.

Augmentation du stockage: De plus, 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 de Bitcoin et Ethereum. Cependant, nous pourrions atténuer cela en exigeant que les transactions BOB effectuées sur Bitcoin soient incluses dans des blocs Ethereum avec une référence aux derniers blocs Bitcoin. De cette façon, les nœuds n'ont besoin de synchroniser que les blocs Bitcoin récents.

Étapes suivantes

Nous sommes ravis de repousser les limites des rollups hybrides combinant la sécurité de Bitcoin avec l'innovation d'Ethereum. Dans ce problème concret, nous sommes intéressés à associer la résistance à la censure des transactions de Bitcoin avec la pile rollup de BOB. Nous mettrons à jour ce billet de blog avec plus d'informations au fur et à mesure de nos progrès.

Avertissement :

1. Cet article est repris de [gateBOB]. Tous les droits d'auteur appartiennent à l'auteur original [Dominik Harz]. S'il y a des objections à cette réimpression, veuillez contacter le Porte d’apprentissageéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité de responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas des conseils en matière d'investissement.
3. L'équipe Gate Learn a traduit l'article dans d'autres langues. La copie, la distribution ou le plagiat des articles traduits est interdit sauf mention contraire.