Based Booster Rollup の詳細な分析: 背景、実践、展望
原作者：jolestar（X： @jolestar ）
数人の友人がBased Rollupについて主にセキュリティの観点から話しているのを見かけましたが、L1とL2の関係とアプリケーションの構築の観点からBased Booster Rollupについての私の見解を話したいと思います。
Based Rollup のアイデアは実際には非常に単純です。つまり、ユーザーが L2 トランザクションを L1 に直接送信し、L1 がそれらを並べ替えてパッケージ化します。ただし、L1 はトランザクションの正当性を検証せず、トランザクションの順序と可用性を保証するだけです。 L2 は純粋なエグゼキューターであり、L1 にパッケージ化された L2 トランザクションを実行します。これに見覚えがあるでしょうか？これって碑文モードじゃないの？はい、碑文のインデクサーはここでは L2 として理解できます。この観点については、「碑文はバグですか、機能ですか」という記事で述べました。
Booster Rollup は別の観点から始まります。L2 のコントラクトを通じて L1 のステータスを直接読み取るにはどうすればよいでしょうか?このアイデアは実際には複雑ではありません。Based Rollup は既に L1 で L2 トランザクションを実行しているので、L1 トランザクションも実行するのはどうでしょうか。このように、L1 と L2 の状態は大きな状態ツリー内にあり、L2 のコントラクトは L1 の状態を直接読み取ることができます。
そのため、taiko のように、Based Rollup と Booster Rollup を組み合わせた Based Booster Rollup (BBR) と呼ばれるプロジェクトもあります。
BBRの背景
BBRは、提案以来市場の注目を集めてきましたが、その主な背景は、現在主流のイーサリアムのL2ソリューションによる断片化問題、L1とL2間の断片化、およびL2間の断片化です。現在の L2 ソリューションが提供する機能は、開発者とユーザーの両方の観点から見ても、依然として Oracle に依存しており、資産をブリッジする必要があり、ウォレットはネットワークを切り替える必要があるという点で、Alt-L1 とあまり変わりません。この分離は、L1 と L2 の間の結合がそれほど緊密ではないことも引き起こしており、L2 はいつでもコンセンサス メカニズムを追加して、Alt-L1、つまり「自立した王」になることができ、開発者とユーザーは基本的には同じになります。無関心。現在の主なバインディング関係は、EF の正統性に関する制限から来ています。L2 は L1 を DA として使用しなければなりませんが、明らかにこの制限は強力ではありません。
では、現在のすべての L2 ソリューションをベースド ロールアップ ソリューションに置き換えれば、問題は解決されるのでしょうか? Optimism や Arbitrum が飛び出してきて、Based Rollup に変更するのは簡単ではないですか、と言うでしょう。現在、主要な L2 ソリューションでは、L2 がシーケンサーを直接削除し、Based Rollup を通じてトランザクションを L1 に送信できるようにしています。
しかし、これで断片化の問題は解決できるでしょうか?できません。 Arb と Op は両方ともトランザクションをリアルタイムで L1 に送信し、L1 によってパッケージ化およびソートされますが、それぞれが独自のトランザクションのみを認識するため、依然として分離されています。この時点で、Based Rollup の断片化問題を解決する鍵は、L2 間で共有できるトランザクションまたはデータを持つことであり、このデータ形式には以下が必要であることを誰もが理解する必要があります。
これは、L1 で定義されたプラットフォームおよび実装に依存しない形式である必要があります。 L2 アカウントと仮想マシンはそれぞれ異なり、それぞれのトランザクションを直接共有することはできません。
これには L2 間の合意が必要であり、複数の L2 によってサポートされます。
したがって、プロトコルを最初に設計する必要があり、プロトコルに必要なデータのみがチェーン上に保存され、異なる L2 実装がサポートされます。しかし、これら 2 つの点を達成することは実際には非常に困難です。まず、イーサリアム エコシステムの開発者は一般にスマート コントラクトを通じてプロトコルを設計し、データ形式に直接基づいてプロトコルを設計する習慣がありません。この方向での主な試みは、前回碑文がホットだったときの Ethscriptions でした。 2 番目の点はより難しく、検証には練習と時間が必要です。
BBR から BBSR へ、スタッカブル L2
データ共有の問題について話した後は、ユーザー エクスペリエンスの問題について話しましょう。明らかに、すべてのトランザクションがユーザーによって直接 L1 に送信される場合、ガスであろうと確認時間であろうと、エクスペリエンスは L1 を使用する場合と同様になります。そこで、Based Rollup の事前確認プロトコルを設計し始めた人もいますが、事前確認プロトコルが本当に機能する場合、すべてのトランザクションは最初に事前確認プロトコルを通過する必要があります。それはシーケンサーではないでしょうか。この話をするのは時間の無駄でしょうか？
この矛盾の理由は、誰もがいくつかのトランザクション タイプを混同しているためです。
ユーザーによって直接 L1 に送信され、L1 によって実行および検証されるトランザクションは、L1 トランザクションです。
ユーザーは直接 L1 にサブミットしますが、L1 は L2 間の共有プロトコルのデータ トランザクション (L1.5 トランザクションと呼ぶことができます) を直接検証して実行することはありません。
ユーザーによって L2 シーケンサーに直接送信され、シーケンサーによって事前確認および実行される、特定の L2 固有のトランザクション。
Based Rollup は 1 と 2 にのみ関連します。3 は Sequencer Rollup の現在の作業方法です。この 2 つは完全に組み合わせることができます。
そのようなロールアップ プランがある場合:
シーケンサは、すべての L1 (L1.5 を含む) トランザクションを自動的に同期し、L1 で指定された順序で実行します。
Sequencer は L2 トランザクションを同時に受信し、L1 トランザクションと合わせてソートして実行します。
1によりBasedとBoosterを実装し、2によりユーザーエクスペリエンスを損なうことなくL2トランザクションの高速確認を実現します。先ほどの命名法に従うとBBSR（Based Booster Sequencer Rollup）と呼ぶべきなのですが、ちょっと長くてわかりにくいのでStackable L2、スタックドL2と呼んでいます。その名の通りL2がスタックされています。 L1 には、L2 には L1 のすべてのトランザクションとステータスが含まれます。これは@RoochNetworkのソリューションです。
L2トランザクションのDAを確保するにはどうすればよいですか?ロールアップかロールアウトか?
上記の解決策が採用された場合、L2 が自身のトランザクションをパッケージ化して L1 に再度送信するのは少し奇妙です。L2 は、自身のトランザクションをパッケージ化した L1 トランザクションを読み取って再実行するためです。自身の出力も自身の入力になります。したがって、Rooch の解決策は、ロールアップではなくロールアウトです。 L1 ブロック スペースは長期的には非常に貴重であるため、L1 スペースを占有する複数の L2 トランザクションは「インボリューション」モデルであり、L1 スペースは L1 および L1.5 トランザクション用に予約され、L2 アプリケーション レベルのトランザクションはより安価なブロック スペースを追求する必要があります。 「アウトソーシング」による新しいブロックスペースの拡大は、業界全体のエコシステムの発展にも利益をもたらします。
ビットコインエコシステムのBBSR/スタッカブルL2プラクティス
これまでの説明はすべてイーサリアムの観点からのものであり、Rooch はビットコインの最初の BBSR またはスタッカブル L2 プラクティスです。ビットコインの生態学的違いについて話しましょう。
ビットコイン L2 にはチューリング完全なスマート コントラクトはなく、ベースド ロールアップ モードが実際に利点となります。 Based Rollup ではトランザクションの実行と検証に L1 が必要ないため、Permission Less と DA を確保するだけで済みます。これにより、ビットコイン エコシステムのプロジェクトは、カラー コインであろうと、その後の RGB、Taproot Assets、Ordinals Inscription、Atomics、Runs など、昔からのデータ構造に基づいてプロトコルの設計を開始する必要がありました。これは、CSV (クライアント側検証) プロトコルの一般的な概念に含めることができ、それらのトランザクションはすべて典型的な L1.5 トランザクションです。 Ethereum エコシステム内のプロジェクトが Based L2 を実装し、複数の L2 間で共有されるプロトコルを設計したい場合、通常は上記のプロトコルと同様になります。
Rooch を例として、ビットコインの BBSR の動作モードを説明しましょう。
ユーザーは、L1 および L1.5 トランザクションをビットコインに直接送信します。プロトコルはパブリックであるため、入り口はどのアプリケーションでも可能です。
Rooch はすべての L1 トランザクションを同期し、その中で UTXO を処理し、追加のプロトコル情報が含まれているかどうかを確認し、対応する Move モジュールを使用してそれを処理します。たとえば、Inscription として識別されたトランザクションは ord モジュールによって処理され、バビロン ステーキングのトランザクションは bbn モジュールによって処理されます。
ユーザーは、L2 トランザクションを Rooch の Sequencer ノードに直接送信して処理します。上記 3 つのトランザクションの実行結果により完全な状態ツリーが生成され、アプリケーション コントラクトは L1 および L1.5 トランザクションによって生成された状態を最大限に活用できます。
このモードのアプリケーションは 2 つのトランザクションを設計できます。1 つはパブリック プロトコル トランザクション (L1 上のベース部分)、もう 1 つはアプリケーション トランザクション (シーケンサーによってソート) であり、この 2 つはブースター モードを通じて相互に連携して Permission Less を保証します。ユーザーエクスペリエンスも確保しながら。
前述したように、パブリック プロトコルの設計には、検証して合意に達するための時間と実践が必要です。Rooch が提供できるのは、非常に便利な実験環境です。ビットコインで新しいアプリケーションや資産プロトコルを設計したい場合は、After を定義するだけで済みます。プロトコル形式を決定し、それを処理するために対応する Move コントラクト モジュールをデプロイすると、アプリケーション シナリオを構築して実験できます。
もちろん、ビットコインのエコシステムには、この過程でいくつかの課題もあります。
ビットコインの元の設計には、この DA シナリオ向けに拡張する十分な余地が残されていなかったため、データがビットコインに書き込まれる形式は、Witness を介した OP_RETURN 埋め込みデータなど、以前のさまざまなプロトコルが探求しようとしていた方向性の 1 つです。署名があっても、現在、標準化されたソリューションが不足しています。
ビットコインのエコシステムは、チェーンに埋め込まれたデータの価値について広範な合意に達していません。これは、ビットコインのエコシステムが世界的な公共データバスとして注目すべきであるという前回の記事以来、私が求めてきた方向性でもあります。データバス）の値。
グローバルパブリックデータバスとしてのL1の価値
DeFiの夏以来、暗号分野全体がDeFiの外での新しい応用を模索してきた。ビットコインの碑文ブームであれ、最近のBased Rollupの議論であれ、それはデータバスとしてのL1の価値の再発見として理解できます。分散システムの観点から見ると、システム間の分離はデータ バスを通じて実現でき、システム間の分離はパーミッションレスを達成するための重要な前提条件の 1 つです。たとえば、暗号エコシステムの分散型取引所は、ブロックチェーンのデータバスを最大限に活用して、従来の金融システムでは直接実現することが困難な「分散型」ドッキングを実現します。より複雑なアプリケーションをサポートしたい場合は、単純な転送トランザクションをアプリケーション プロトコル トランザクションにアップグレードするだけで、アプリケーション レベルのアクセス許可をより少なく実現できます。この方法は、既存のアプリケーションへの侵入が最も少なくなります。
この記事では、主にエコロジーとアプリケーションの観点から BBR について説明します。BBR モードのセキュリティと、BBR モードにおける L1、L1.5、および L2 状態の相互運用性については、後の記事で詳しく説明します。以下に、私の歴史的な記事やコメンテーターによるさまざまな角度からのBased Rollupの説明を含む、いくつかの関連リンクを添付します。
関連リンク:
1. スタッカブル L2 — 新しいブロックチェーン拡張ソリューションhttps://rooch.network/zh-CN/blog/stackable-l2
2. ビットコインのレイヤー 2 はどうすればよいですか? https://x.com/jolestar/status/1717358817992995120ビットコインのL1のステータスやデータをどのように活用するかという最初の計画をL2から設計しました。コメントで友人がBoosterの計画について言及し、最終的にBoosterの計画になりました。実際に採用されています。
3. その碑文はバグですか、それとも機能ですか? https://x.com/jolestar/status/1732711942563959185では、L1 と L2 のインセンティブの互換性の問題を含め、L2 がどのように構築されるかという観点から碑文の価値が説明されています。
4. 減算理論に基づくベースロールアップについて議論する @kerne l1 983 https://web3 caff.com/zh/archives/108241
5. ベースロールアップに関する @jason_chen 998 の記事https://x.com/jason_chen998/status/1799692331635048697
6. ベースのロールアップトラック調査レポートhttps://research.web3 caff.com/zh/archives/22719
IOS
Android