tl;dr

  • Les L2 devraient avoir la même résistance à la censure que les L1 sur lesquelles elles sont basées.
  • 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 à l'intégration de Bitcoin comme moyen pour les utilisateurs d'exécuter des transactions sur BOB.
  • Les utilisateurs de Bitcoin pourront retirer leur BTC de BOB sans avoir à envoyer une transaction à BOB.

‍

L'une des principales propriétés des L2 est que leur état doit progresser même lorsque 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 fait que le L2 soit en ligne. Ainsi, les utilisateurs peuvent forcer l'inclusion de leurs transactions même lorsque le séquenceur n'est pas en ligne ou que le séquenceur n'accepte pas directement leurs transactions.

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 d'Ethereum peuvent facilement déclencher des retraits vers Bitcoin via le pont BitVM. Cependant, les utilisateurs doivent disposer d'ETH sur Ethereum.

Cela ne nous suffit pas : 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 : utiliser par défaut Ethereum comme 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 ce billet de blog.

‍

Historique de l'AD et de la dérivation

Le processus de dérivation est très important pour les L2 : l'ensemble de l'état L2 de BOB doit être construit à partir de la 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.

De manière simplifiée, dans les rollups (en particulier les chaînes OP Stack), nous avons deux types de données sur le L1 :

  • Les opérations de dépôt effectuées sur le contrat "OptimismPortal". Il s'agit des transactions effectuées par les utilisateurs sur Ethereum pour déposer leurs avoirs dans la 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 op-batcher pour être plus précis) à partir des transactions L2. Ceux-ci comprennent toutes les transactions effectuées directement par les utilisateurs sur BOB et sont finalement réintégrés dans les blobs Ethereum.

‍

Bitcoin comme couche DA

Si nous voulons utiliser Bitcoin comme couche DA, pourquoi ne pas passer complètement à l'utilisation de Bitcoin comme couche DA ? La réponse est principalement une question de coût. Bitcoin dispose de très peu de mémoire (environ 4 Mo toutes les 10 minutes), et le coût de stockage est donc élevé.

Toutefois, dans notre cas, BOB peut toujours utiliser Ethereum comme couche DA "principale" où elle publie l'ensemble de ses données de transaction, mais ajouter Bitcoin comme couche de repli hautement résistante à la censure si la couche DA Ethereum n'est pas disponible. Essentiellement, Ethereum devient la couche d'AD 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 le bitcoin à BOB dans le pipeline de dérivation, de sorte que BOB (et en particulier le "op-node") traite les entrées dans cet ordre :

  1. Opérations de retrait forcé de bitcoins (nouvellement ajoutées spécifiquement pour BOB)
  2. Dépôts d'Ethereum dans le contrat OptimismPortal de BOB (OP Stack standard)
  3. Lots Ethereum de op-batcher (standard OP Stack)

Voyons maintenant une solution possible pour encoder les transactions de retrait forcé de Bitcoin dans le pipeline de dérivation BOB. Notez que cette solution est encore en cours de recherche, et que des changements sont donc possibles.

‍

Transactions de retrait forcé de Bitcoin

Nous aurons besoin de trois éléments pour créer une opération de retrait forcé :

  1. Construire la transaction de retrait forcé sur Bitcoin.
  2. Stocker la transaction de retrait forcé sur Bitcoin dans les limites de la taille de Bitcoin.
  3. Prise en charge des frais de gaz pour la transaction de retrait forcé sur Bitcoin.

‍

1. Construire l'opération de retrait forcé

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

  • bytes32 sourceHash : le code source, qui identifie de manière unique l'origine du dépôt.
  • adresse de : l'adresse du compte de l'expéditeur.
  • address to : L'adresse du compte destinataire, ou l'adresse nulle (longueur nulle) si la transaction déposée est une création de contrat.
  • uint256 mint : La valeur de l'ETH à frapper sur L2.
  • valeur uint256 : La valeur de l'ETH à envoyer au compte du destinataire.
  • uint64 gas : La limite de gaz pour la transaction L2.
  • bool isSystemTx : Si elle est vraie, la transaction n'interagit pas avec le pool de gaz de bloc L2.
  • octets de données : Les données d'appel.

Une transaction de retrait forcé nécessite d'inclure la transaction de retrait codée dans le champ de données de la transaction de dépôt. Cela se 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 comprend toutes les données ci-dessus.

‍

2. Enregistrer la transaction de retrait forcé sur Bitcoin

Comme les données relatives à l'opération de retrait forcé sont plus volumineuses que ce qui devrait être stocké dans une sortie OP_RETURN, nous utiliserons probablement une sortie Taproot pour stocker les données .

S'il est 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.

Sérialisation des données: La transaction de retrait forcé est sérialisée à l'aide de scripts Taproot dans une structure "enveloppe". Il s'agit de noops sur le réseau Bitcoin et ils sont également utilisés, par exemple, pour les Ordinals. Nous adaptons la structure à 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 d'engagement/révélation à deux phases :

Comme pour les Ordinals, les utilisateurs devront soumettre deux transactions à Bitcoin :

  • Commit Transaction : Crée une sortie Taproot qui s'engage dans 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 les nœuds complets BOB et les séquenceurs afin d'inclure la transaction de retrait.
  • Reveal Transaction (Révéler la transaction) : Dépense le résultat de l'opération de validation, révélant l'inscription sur la chaîne, c'est-à-dire révélant l'opération de retrait de l'utilisateur pour l'inclure dans le BOB.

‍

3. Traiter les coûts du gaz pour la transaction de retrait forcé

Il s'agit du problème le plus ouvert à ce jour, deux options étant actuellement à l'étude :

  • Fixer le gaz à 0 pour la transaction de retrait forcé sur Bitcoin et déduire les coûts du gaz du solde d'ETH de l'utilisateur sur la BOB. Ainsi, seuls les utilisateurs disposant d'ETH sur la BOB peuvent effectuer des retraits forcés. Cette solution n'est toutefois pas idéale, car elle exige que les utilisateurs disposent d'ETH sur la BOB pour forcer les retraits, ce qui signifie que les utilisateurs qui disposent de BTC sur Bitcoin ne peuvent pas forcer les retraits.
  • Le gaz est payé par les utilisateurs en BTC sur Bitcoin. Le réseau BOB devrait avoir une adresse sur Bitcoin qui peut recevoir des BTC et échangerait effectivement les BTC reçus par l'utilisateur en ETH sur BOB pour payer la partie L1 des coûts du gaz plus les coûts d'exécution. Cette option est possible en utilisant BOB Gateway et en définissant l'adresse EVM de la DAO BOB comme destinataire des BTC.

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

‍

La mise en place de l'ensemble

N'importe qui peut déterminer l'état de BOB en vérifiant simplement les données sur le Bitcoin et l'Ethereum :

  1. Lire toutes les transactions de retrait de Bitcoin. Celles-ci sont codé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'ajout que nous faisons à la pile OP et où nous améliorons le pipeline de dérivation.
  2. Lire toutes les transactions effectuées sur le contrat OptimismPortal de BOB sur Ethereum. Cela fait déjà partie du pipeline de dérivation standard de la pile OP.
  3. Lire 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 le séquenceur pour recevoir les transactions confirmées, mais qu'ils lisent les blobs Ethereum. Cela fait déjà partie du pipeline standard de dérivation de la pile OP.

‍

Défis techniques

Cohérence des données: Bien qu'il soit important de garantir la cohérence des données entre les chaînes Ethereum et Bitcoin, la simple présence de 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 consiste à mettre en œuvre une logique de validation à l'intérieur de l'op-node (ou d'autres implémentations de la 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 traiter les données des deux chaînes, ce qui pourrait rendre la résolution des litiges plus complexe. Pour y remédier, nous devons prendre en compte avec précision les transactions possibles entre Bitcoin et Ethereum dans le cadre du pont BitVM et du règlement de la BOB sur Ethereum.

Augmentation du stockage: En outre, les nœuds BOB du réseau doivent faire face à des besoins accrus en matière de stockage et de bande passante puisqu'ils doivent traiter et stocker des données provenant de Bitcoin et d'Ethereum. Toutefois, nous pourrions atténuer ce problème en exigeant que les transactions BOB effectuées sur Bitcoin soient incluses dans les blobs Ethereum avec une référence aux derniers blocs Bitcoin. De cette manière, les nœuds n'ont qu'à synchroniser les blocs Bitcoin récents.

‍

Prochaines étapes

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

‍