tl;dr

  • L2は、ベースとなるL1と同じ検閲耐性を持つべきである。
  • BOBでは、ユーザーはすでにイーサリアム取引を通じてBOBからイーサリアムに資産を強制的に引き出すことができます。
  • BOBはBitVMブリッジにおいて、ユーザーがBOB上で取引を実行する方法としてビットコインの統合に取り組んでいる。
  • ビットコインユーザーは、BOBにトランザクションを送信することなく、BOBからBTCを引き出すことができるようになります。

‍

L2の核となる特性の1つは、シーケンサーがオフラインであっても、そのステートが進行する必要があることだ。L2は、L2のオンライン状態とは無関係に更新できるデータ・アベイラビリティ・レイヤー（DA）から状態を読み書きすることでこれを実現する。こうすることで、ユーザーはシーケンサーがオフラインのときでも、あるいはシーケンサーが直接トランザクションを受け入れないときでも、自分のトランザクションを強制的に取り込むことができる。

BOBのBitVMブリッジにとって、これは興味深い問題を引き起こす。BOBは現在、イーサリアムEIP-4844ブロブをDAレイヤーとして使用している。イーサリアム上のユーザーは、BitVMブリッジを介してビットコインに戻る引き出しを簡単にトリガーすることができます。しかし、そのためにはユーザーがイーサリアム上にETHを持っている必要がある。

これでは不十分だ：Bitcoinユーザーは、BOBからBitcoinにBTCを強制的に引き出すために、Bitcoin上でBTCを必要とするだけでよいはずです。私たちはハイブリッドのソリューションに取り組んでいます：DAとしてイーサリアムをデフォルトにする一方で、ユーザーはビットコイン上の特別なトランザクションを介してBOB上のトランザクションを強制的に含めることができます。このブログ記事で進行中の作業を共有できることを嬉しく思います。

‍

DAと導出の背景

BOBのL2ステート全体は、L1とDAレイヤーから構築される必要がある。これにより、L2はDAレイヤー（我々の場合はイーサリアム）と同じ検閲耐性を享受できる。

単純化すると、ロールアップ（特にOPスタックチェーン）では、L1上に2種類のデータがある：

  • 預金取引OptimismPortal」コントラクトに対して行われる。これは通常、イーサリアム上のユーザーが資産をBOBに預けるために行う取引である。これらの入金トランザクションは、BOB上で他のトランザクションを実行するために使用することもできる。
  • L2トランザクションからシーケンサー（正確にはオペバッチャー）によって提出されたバッチ。これらには、BOB上のユーザーによって直接行われたすべてのトランザクションが含まれ、最終的にイーサリアムのブロブに戻される。

‍

DAレイヤーとしてのビットコイン

ビットコインをDAレイヤーとして使いたいのであれば、なぜビットコインを完全にDAレイヤーとして使うことに完全に切り替えないのか？答えはほとんどコストだ。ビットコインは利用可能なストレージが非常に少ない（およそ10分ごとに4MB程度）ため、ストレージコストが高い。

しかし、我々のケースでは、BOBはイーサリアムを "メイン "DAレイヤーとして使用することができ、そこではトランザクションデータ全体をポストするが、イーサリアムDAが利用できない場合は、高度に検閲に強いフォールバックレイヤーとしてビットコインを追加する。基本的に、イーサリアムは楽観的なDAレイヤーとなり、ビットコインは高価だがフォールトトレラントな最後の手段となる。

‍

ハイブリッド派生パイプライン

基本的な解決策は、派生パイプラインの一部としてBOBにビットコインを追加し、BOB（特に "op-node"）がこの順序で入力を処理するようにすることである：

  1. ビットコインの強制引き出し取引（BOBのために新たに追加された）
  2. BOBのOptimismPortal契約（OPスタック標準）へのイーサリアム入金
  3. op-batcher（OPスタック標準）からのイーサリアムバッチ

ビットコイン強制引き出しトランザクションをBOB派生パイプラインにエンコードする可能性のある解決策に飛び込もう。これはまだ研究中であり、変更が可能であることに留意されたい。

‍

ビットコイン強制出金取引

強制引き出し取引を行うには3つのパーツが必要である：

  1. ビットコインの強制引き出し取引を構築する。
  2. ビットコインのサイズ制限内でビットコインに強制引き出しトランザクションを保存します。
  3. ビットコインの強制引き出し取引のガス代を処理する。

‍

1.強制引き出し取引の構築

OPスタックの預託トランザクションは以下の構造を持つ：

  • bytes32 sourceHash: 預託元を一意に識別するソースハッシュ。
  • address from: 送信者アカウントのアドレス。
  • アドレス：または、預託されたトランザクションがコントラクト作成の場合は、NULL（長さゼロ）のアドレス。
  • uint256 mint：L2でミントするETHの値。
  • uint256 値：受信者アカウントに送信するETH値。
  • uint64 gas：L2トランザクションのガスリミット。
  • bool isSystemTx：trueの場合、トランザクションはL2ブロックガスプールと相互作用しない。
  • バイトのデータ：calldata。

強制出金トランザクションでは、入金トランザクションのデータフィールドにエンコードされた出金トランザクションを含める必要がある。これは、BOB から Bitcoin への引き出しをトリガーするトランザクションを BOB 上で作成することで行われ、トランザクションがイーサリアムから送信された場合と全く同じように機能する。

そして、上記のすべてのデータを含む強制引き出しトランザクションの（圧縮された）バージョンをビットコインに保存することができる。

‍

2.ビットコインに強制引き出しトランザクションを保存する。

強制引き出しトランザクションのデータは、通常OP_RETURN出力に格納されるべきデータよりも大きいため、データを格納するためにTaproot出力を使用することになるでしょう。

BOBのOptimismPortalコントラクトに送信されるため、イーサリアムの入金取引（出金を含む可能性がある）を特定するのは簡単だが、ビットコインの強制出金取引を特定するのはそれほど簡単ではない。

データのシリアライズ：強制引き出しトランザクションは、「エンベロープ」構造内のTaprootスクリプトを使用してシリアライズされる。これはビットコインネットワーク上のヌープであり、例えばオーディナルにも使用される。我々のニーズに合わせて構造を調整する。

アンセット

OP_FALSE OP_IF

 OP_PUSH "bob"

 OP_1

 OP_PUSH "トランザクション"

 OP_0

 op_push $withdrawal_transaction_data

OP_ENDIF

二相コミット/リビール方式：

オーディナルと同様、ユーザーはビットコインに2つのトランザクションを提出しなければならない：

  • コミットトランザクション：碑文の内容を含むスクリプトにコミットするTaproot出力を作成する。このトランザクションはまだデータを明らかにしていないので、BOBフルノードとシーケンサーには、引き出しトランザクションを含む2番目のトランザクションが必要になる。
  • トランザクションの公開：コミット・トランザクションからの出力を消費し、チェーン上の記名を明らかにする。つまり、BOBに含めるためにユーザーの引き出しトランザクションを明らかにする。

‍

3.強制引き出し取引におけるガス料金の取り扱い

これはまだ最も未解決の問題で、現在2つの選択肢が検討されている：

  • Bitcoin上の強制引き出しトランザクションのgasを0に設定し、BOB上のユーザーのETH残高からgasコストを差し引く。そうすれば、BOBにETHを持っているユーザーだけが強制引き出しができる。しかしこれは、強制引き出しを行うにはBOB上でETHを持っている必要があるため、良い選択肢とは言えません。つまり、Bitcoin上でBTCを持っているユーザーは強制引き出しを行うことができません。
  • ガスはビットコイン上のBTCでユーザーが支払う。BOBネットワークは、BTCを受け取ることができるBitcoin上のアドレスを持つ必要があり、事実上、ユーザーが受け取ったBTCをBOB上のETHに交換し、ガスコストのL1部分と実行コストを支払うことになる。このオプションは、BOBゲートウェイを使用し、BOB DAOのEVMアドレスをBTCの受取人に設定することで可能となる。

さらにいろいろなアイデアを試しているので、続報をお楽しみに！

‍

すべてをまとめる

ビットコインとイーサリアムのデータをチェックするだけで、誰でもBOBの状態を判断できる：

  1. ビットコインからすべての引き出しトランザクションを読み取る。これらは引き出しごとに2つのトランザクション、すなわち1つのコミットと1つの公開トランザクションとしてエンコードされる。これがOPスタックへの追加であり、派生パイプラインを強化する部分である。
  2. イーサリアム上のBOBのOptimismPortalコントラクトに対して行われたすべてのトランザクションを読み取る。これはすでに標準的なOPスタック派生パイプラインの一部である。
  3. BOB上で直接行われ、イーサリアム上のバッチの一部として統合されたすべてのトランザクションを読み取る。重要なのは、フルノードは確認されたトランザクションを受け取るためにシーケンサーから直接読み取るのではなく、イーサリアムのブロブから読み取ることである。これはすでに標準的なOPスタック派生パイプラインの一部である。

‍

技術的課題

データの一貫性：イーサリアムチェーンとビットコインチェーン間のデータの一貫性を確保することは重要であるが、両チェーン上に取引データが存在するだけでは正当性は保証されない。トランザクションが正当とみなされるためには、ロールアップの状態遷移関数に従って有効な状態遷移を表す必要がある。解決策としては、まずトランザクションが有効な状態変化をもたらすかどうかを検証する検証ロジックをop-node（または他のコンセンサスレイヤーの実装）内部に実装してから、それを受け入れる必要がある。

不正証明と有効性：BitVMとイーサリアム両方の不正証明システムは、両方のチェーンからのデータを扱うために強化される必要があり、これは紛争解決をより複雑にする可能性がある。これに対処するためには、BitVMブリッジとBOBのイーサリアム上での決済の一部として、ビットコインとイーサリアムからの可能なトランザクションを正確に考慮する必要がある。

ストレージの増加：さらに、ネットワーク内のBOBノードは、ビットコインとイーサリアムからのデータを処理して保存する必要があるため、ストレージと帯域幅の要件が増加する。しかし、ビットコインで行われたBOBトランザクションは、最新のビットコインブロックを参照してイーサリアムのブロブに含める必要があることを要求することで、これを軽減することができる。そうすれば、ノードは最近のビットコインブロックを同期するだけでよい。

‍

次のステップ

私たちは、ビットコインのセキュリティとイーサリアムの革新性を組み合わせたハイブリッド・ロールアップのフロンティアを押し広げることに興奮しています。この具体的な問題では、ビットコインのトランザクションの検閲耐性をBOBのロールアップスタックと組み合わせることに興味があります。進捗があり次第、このブログ記事を更新していきます。

‍