元ArbitrumテクニカルアンバサダーがArbitrumのコンポーネント構成を解説（前編）

この記事は、Arbitrum の元技術アンバサダーであり、スマート コントラクト自動化監査会社 Goplus Security の元共同創設者である Luo Benben による Arbitrum One の技術的解釈です。

執筆者: Luo Benben、元 Arbitrum テクニカル アンバサダー、オタク Web3 寄稿者

**この記事は、Arbitrum の元技術アンバサダーであり、スマート コントラクト自動化監査会社 Goplus Security の元共同創設者である Luo Benben による Arbitrum One の技術的解釈です。 **

中国のレイヤー 2 に関連する記事や資料には、Arbitrum や OP Rollup の専門的な解釈が不足しているため、この記事は Arbitrum の操作メカニズムを普及させることでこの分野のギャップを埋めることを試みます。 Arbitrum 自体の構造が複雑すぎるため、極力簡略化しても全文は 10,000 ワードを超えますので、2 部に分けてまとめて参照することをお勧めします。 **

ロールアップ ソーターの簡単な説明

ロールアップ展開の原理は次の 2 つの点に要約できます。

**コストの最適化: ほとんどのコンピューティングおよびストレージ タスクを L1 チェーン、つまり L2 に転送します。 **L2 はほとんどが単一サーバー、つまりシーケンサー/オペレーター上で実行されるチェーンです。

ソーターは見た目も感触も集中型サーバーに近く、「ブロックチェーンの不可能な 3 つの側面」では、TPS とコストの利点と引き換えに「分散化」が放棄されています。ユーザーはイーサリアムの代わりに L2 にトランザクション命令を処理させることができ、コストはイーサリアムでの取引よりもはるかに低くなります。

(出典:BNBチェーン)

セキュリティ保証: **L2での取引内容と取引後のステータスはイーサリアムL1に同期され、コントラクトを通じてステータス遷移の正当性が検証されます。 **同時に、L2 の履歴記録はイーサリアム上に保持され、シーケンサーが永続的にダウンした場合でも、他の人がイーサリアム上の記録を通じて L2 状態全体を復元できます。

**基本的に、Rollup のセキュリティはイーサリアムに基づいています。 **シーケンサーがアカウントの秘密キーを知らない場合、アカウントの名前でトランザクションを開始したり、アカウントの資産残高を改ざんしたりすることはできません (たとえ改ざんしたとしても、すぐに発見されます)。

比較的成熟したロールアップ ソリューションでは、ソーターはシステム ハブとして集中管理されていますが、集中ソーターはトランザクション レビューや悪意のあるダウンタイムなどのソフトな悪動作のみを実装できます。しかし、理想的なロールアップ ソリューションでは、対応する手段が存在します。封じ込めのため（強制撤回や証拠の整理などの検閲耐性メカニズムなど）。

(Loopringプロトコルは、ユーザーが呼び出すL1上の契約ソースコードに強制退会機能を設定します)

ロールアップ シーケンサの悪事を防ぐための状態検証方法は、不正証明と有効性証明の 2 つのカテゴリに分類されます。不正証明を使用するロールアップ スキームは OP ロールアップ (オプティミスティック ロールアップ、OPR) と呼ばれますが、歴史的な問題のため、有効性証明を使用するロールアップ スキームは、多くの場合、有効性ロールアップではなく ZK ロールアップ** (ゼロ知識証明ロールアップ、ZKR) と呼ばれます。 。

Arbitrum One は典型的な OPR であり、L1 上でコントラクトを展開し、送信されたデータを積極的に検証することはなく、データに問題がないことが楽観的です。送信されたデータが正しくない場合、L2 検証ノードは積極的にチャレンジを開始します。

したがって、**OPR は信頼の仮定も意味します。つまり、常に少なくとも 1 つの正直な L2 検証ノードが存在します。 **ZKR の契約では、暗号計算を使用して、シーケンサーから送信されたデータを積極的かつコスト効率よく検証します。

(楽観的ロールアップ演算法)

(ZKロールアップ動作モード)

この記事では、オプティミスティック ロールアップの主要プロジェクトである Arbitrum One について、システム全体のあらゆる側面を網羅して詳しく紹介します。注意深く読んだ後は、Arbitrum とオプティミスティック ロールアップ/OPR について深く理解できるようになります。

Arbitrum のコアコンポーネントとワークフロー

コア契約:

Arbitrum の最も重要な契約には、**SequencerInbox、DelayedInbox、L1 ゲートウェイ、L2 ゲートウェイ、Outbox、RollupCore、Bridge などが含まれます。 **詳細は後ほどご紹介します。

シーケンサー：

ユーザートランザクションを受信して並べ替え、トランザクション結果を計算し、レシートを迅速に (通常は 1 秒未満) ユーザーに返します。多くの場合、ユーザーは自分のトランザクションが数秒以内に L2 にリストされるのを確認でき、そのエクスペリエンスは Web2 プラットフォームとまったく同じです。

同時に、シーケンサーは最新の L2 ブロックをイーサリアム チェーンの直下にブロードキャストし、任意のレイヤー 2 ノードがそれを非同期で受信できます。ただし、現時点では、これらの L2 ブロックは最終的なものではなく、シーケンサーによってロールバックされる可能性があります。

数分ごとに、シーケンサーはソートされた L2 トランザクション データを圧縮し、バッチに集約して、レイヤー 1 の受信ボックス コントラクト SequencerInbox に送信して、データの可用性とロールアップ プロトコルの動作を保証します。一般に、Layer1 に送信された L2 データはロールバックできず、最終的なデータになる可能性があります。

上記のプロセスから次のように要約できます。 **Layer2 には独自のノード ネットワークがありますが、これらのノードの数はまばらであり、一般にパブリック チェーンで一般的に使用されるコンセンサス プロトコルがないため、セキュリティが非常に低く、保証する必要があります。イーサリアム依存によるデータ公開の信頼性と状態遷移の有効性。 **

アービトラムロールアッププロトコル:

ロールアップ チェーンのブロック RBlock の構造、チェーンの継続方法、RBlock の解放、およびチャレンジ モード プロセスを定義する一連のコントラクト。 **ここで言及するロールアップチェーンは、誰もが理解しているレイヤー2台帳ではなく、不正防止メカニズムを実装するためにArbitrum Oneが独自に設定した抽象的な「チェーン状のデータ構造」であることに注意してください。 **

1 つの RBlock には複数の L2 ブロックの結果を含めることができ、データも大きく異なります。そのデータ エンティティ RBlock は、RollupCore の一連のコントラクトに保存されます。 RBlock に問題がある場合、Validator は RBlock の送信者に異議を申し立てます。

バリデータ:

Arbitrum のバリデーター ノードは、実際にはレイヤー 2 フル ノードの特別なサブセットであり、現在ホワイトリスト アクセスを持っています。

Validator は、シーケンサーによって SequencerInbox コントラクトに送信されたトランザクション バッチに基づいて新しい RBlock (ロールアップ ブロック、アサーションとも呼ばれる) を作成し、** 現在のロールアップ チェーンのステータスを監視し、シーケンサー。間違ったデータで挑戦してください。 **

アクティブなバリデーターは、事前に ETH チェーン上に資産を担保する必要があります。ステーカーとも呼ばれます。誓約していないレイヤー 2 ノードもロールアップの実行ダイナミクスを監視し、異常なアラームをユーザーに送信できますが、ETH チェーン上のシーケンサーによって送信されたエラー データに直接介入することはできません。

チャレンジ：

基本的な手順は、複数回のインタラクティブなセグメンテーションと単一ステップの証明として要約できます。セグメント化プロセスでは、挑戦者はまず、問題のあるオペレーション コード命令を分解して検証を行うまで、問題のあるトランザクション データに対して複数回のセグメント化を実行します。 「**マルチラウンド細分割シングルステップ証明」のパラダイムは、Arbitrum 開発者によって、不正証明の最もガスを節約する実装であると考えられています。 **すべての側面は契約の管理下にあり、いかなる当事者も不正行為を行うことはできません。

チャレンジ期間:

OP Rollup の楽観的な性質により、各 RBlock がチェーンに送信された後、コントラクトは積極的にチェックされず、検証者が改ざんするためのウィンドウ期間が残ります。 この期間はチャレンジ期間であり、Arbitrum One メイン ネットワークでは 1 週間です。チャレンジ期間が終了すると、RBlock が最終的に確認され、 ブロックで L2 から L1 に渡された対応するメッセージ (公式ブリッジを介して実行される引き出し操作など) を解放できます。

ArbOS、Geth、WAVM：

Arbitrum で使用される仮想マシンは AVM と呼ばれ、これには Geth と ArbOS が含まれます。 **Geth はイーサリアムで最も一般的に使用されているクライアント ソフトウェアであり、Arbitrum はこれに軽量の変更を加えました。 **ArbOS は、ネットワーク リソース管理、L2 ブロックの生成、EVM との連携など、L2 関連のすべての特殊機能を担当します。この 2 つの組み合わせを、Arbitrum で使用される仮想マシンであるネイティブ AVM とみなします。 WAVM は、AVM コードを Wasm にコンパイルした結果です。 **Arbitrum チャレンジ プロセスでは、最後の「シングルステップ証明」で WAVM 命令を検証します。 **

ここで、次の図を使用して、上記のコンポーネント間の関係とワークフローを表すことができます。

L2 トランザクションのライフサイクル

L2 トランザクションの処理フローは次のとおりです。

1. ユーザーは取引指示をシーケンサーに送信します。

2. 仕分け機は、電子署名などのデータに加工する取引を検証し、無効な取引を排除し、仕分けや計算を行います。

3. シーケンサーはトランザクション受領書をユーザーに送信します (通常は非常に高速です) ** しかし、これは ETH チェーンの下でシーケンサーによって実行される単なる「前処理」です。これはソフト ファイナリティの状態にあり、信頼できません。 **。しかし、シーケンサーを信頼するユーザー (ほとんどのユーザー) は、トランザクションが完了し、ロールバックされないと楽観的に考えることができます。

4. ソーターは、前処理された元のトランザクション データを高度に圧縮し、それをバッチにカプセル化します。

**5. 時々 (データ量や ETH の混雑などの要因の影響を受けて)、シーケンサーはトランザクション バッチを L1 のシーケンサー インボックス コントラクトに発行します。 **この時点で、トランザクションにはハードファイナリティがあると考えられます。

シーケンサー受信箱契約

コントラクトは、データの可用性を確保するために、シーケンサーによって送信されたトランザクション バッチを受け取ります。詳しく見てみると、SequencerInbox のバッチ データには、Layer2 のトランザクション入力情報が完全に記録されています。**シーケンサーが永続的にダウンしている場合でも、誰でもバッチ レコードに基づいて Layer2 の現在の状態を復元し、障害が発生した/実行中のシーケンサーを置き換えることができます。 。 **

物理的な方法で理解すると、私たちが見ている L2 は SequencerInbox 内のバッチの投影にすぎず、光源は STF です。光源 STF は変化しにくいため、影の形状はオブジェクトとなるバッチによってのみ決まります。

**Sequencer Inbox コントラクトは、高速ボックスとも呼ばれます。シーケンサーは特に前処理されたトランザクションをそれに送信し、シーケンサーのみがそれにデータを送信できます。 **対応する高速ボックスは低速ボックス遅延受信ボックスであり、その機能については後続のプロセスで説明します。

バリデーターは常に SequencerInbox コントラクトを監視します。**シーケンサーがバッチをコントラクトにリリースするたびに、オンチェーン イベントがスローされます。バリデーターはこのイベントの発生をリッスンした後、バッチ データをダウンロードして実行します。最後に、ETH チェーン上のロールアップ プロトコル コントラクトに RBlock を発行します。

Arbitrum のブリッジ コントラクトにはアキュムレータと呼ばれるパラメータがあり、新しく送信された L2 バッチ、および低速受信トレイで新しく受信したトランザクションの数と情報を記録します。

(シーケンサーは連続的にバッチを SequencerInbox に送信します)

• *

(バッチ固有の情報。データ フィールドはバッチ データに対応します。データのこの部分は非常に大きいため、スクリーンショットは完全には表示されません)

SequencerInbox コントラクトには 2 つの主要な機能があります:

Origin() からシーケンサー L2Batch を追加します。 シーケンサーはバッチ データをシーケンサー Inox コントラクトに送信するたびにこの関数を呼び出します。

force Inclusion(), この関数は誰でも呼び出すことができ、検閲耐性のあるトランザクションを実装するために使用されます。この機能がどのように有効になるかについては、後で遅延受信トレイ契約について説明するときに詳しく説明します。

上記 2 つの関数は、bridge.enqueueSequencerMessage() を呼び出して、ブリッジ コントラクト内のアキュムレータ パラメータ アキュムレータを更新します。

ガス価格

もちろん、DoS 攻撃につながるため、L2 トランザクションを無料にすることはできません。また、ソーター L2 自体の運用コストがかかり、L1 でデータを送信するためのオーバーヘッドも発生します。ユーザーがレイヤー 2 ネットワーク内でトランザクションを開始する場合、ガス料金体系は次のとおりです:

レイヤー 1 リソースの占有によって発生するデータ公開コストは、主にソーターによって送信されたバッチから発生し (各バッチには多くのユーザー トランザクションが含まれます)、コストは最終的にトランザクション開始者によって均等に負担されます。データリリースによって生成される料金価格設定アルゴリズムは動的であり、ソーターは最近の損益状況、バッチサイズ、および現在のイーサリアムガス価格に基づいて価格を設定します。

レイヤー 2 リソースの占有によりユーザーが負担するコスト は、システムの安定した動作を確保するために 1 秒あたりに処理できるガス制限を設定します (現在の Arbitrum One は 700 万です)。 L1 と L2 のガスガイド価格は ArbOS によって追跡および調整されるため、ここでは計算式については当面説明しません。

特定のガス価格の計算プロセスは比較的複雑ですが、ユーザーはこれらの詳細を認識する必要はなく、ロールアップ取引手数料がETHメインネットよりもはるかに安いことをはっきりと感じることができます。

楽観的な詐欺の証拠

上記を思い出すと、L2 は実際には、高速ボックス内のソーターによって送信されたトランザクション入力バッチの単なる投影です。つまり、次のようになります。

トランザクション入力 -> STF -> 状態出力。入力は決定され、STF は変更されないため、出力結果も決定されます。**不正防止および Arbitrum Rollup プロトコルのシステムは、出力状態ルートを RBlock (別名アサーション) の形式で L1 に公開します。楽観的な証明のためのシステム。 **

L1 には、シーケンサーによって公開された入力データと検証器によって公開された出力ステータスがあります。よく考えてみましょう。レイヤー 2 のステータスをチェーンに公開する必要がありますか?

入力によって出力がすでに完全に決定され、入力データが公開されているため、出力結果の送信 (状態) は冗長に思えますか?しかし、この考えは、2 つのシステム L1-L2 間の状態解決の実際の必要性を無視しています。つまり、L2 から L1 への離脱動作には状態の証明が必要です。

Rollup を構築するときの中心的なアイデアの 1 つは、L1 の高コストを回避するために、コンピューティングとストレージの大部分を L2 に配置することです。これは、L1 が L2 のステータスを認識せず、L2 のみを支援することを意味します。シーケンサーは入力データをパブリッシュします。すべてのトランザクションの管理を行いますが、L2 の状態を計算する責任はありません。

**引き出し動作は基本的に、L2 によって与えられたクロスチェーン メッセージに従い、L1 契約から対応する資金のロックを解除し、それをユーザーの L1 アカウントに転送するか、その他の作業を完了することです。 **

この時点で、Layer1 のコントラクトは次のことを尋ねます: **Layer2 でのあなたのステータスは何ですか、また、譲渡すると宣言した資産を実際に所有していることをどのように証明するか。このとき、ユーザーは対応するマークルプルーフなどを提供する必要があります。 **

したがって、引き出し機能を持たないRollupを構築すれば、状態をL1に同期させないことも理論的には可能であり、不正証明などの状態証明システムも必要ありません（別の問題が生じる可能性はありますが）。しかし、実際のアプリケーションでは、これは明らかに実現不可能です。

いわゆる楽観的証明では、コントラクトは L1 に送信された出力ステータスが正しいかどうかをチェックせず、すべてが正確であると楽観的に信じます。 **楽観的な証明システムは、常に少なくとも 1 人の誠実なバリデーターが存在することを前提としています。不正な状態が発生した場合は、不正証明によって異議が申し立てられます。 **

この設計の利点は、ガスの無駄を避けるために、L1 に発行されたすべての RBlock を積極的に検証する必要がないことです。実際、OPR の場合、各 Rblock には 1 つ以上の L2 ブロックが含まれており、各トランザクションは L1 で再実行する必要があるため、すべてのアサーションを検証することは非現実的です。L1 で L2 トランザクションを直接実行するのと何ら変わりはありません。レイヤ2拡張の意味。

ZKR では、ZK Proof がシンプルで非常に小さな Proof を検証するだけで済み、Proof に対応する多数のトランザクションを実際に実行する必要がないため、この問題は発生しません。したがって、ZKR は楽観的に動作するわけではなく、ステータスがリリースされるたびに、数学的検証のための Verfier 契約が発生します。

**不正行為の証明はゼロ知識証明ほど簡潔にはできませんが、Arbitrum では「マルチラウンド、分割、シングルステップの証明」ターンベースのインタラクティブ プロセスが採用されており、最終的に証明する必要があるのは 1 台の仮想マシンのみです。オペレーションコードを使用するため、コストは比較的小さくなります。 **

ロールアッププロトコル

まず、チャレンジを開始し証明を開始するためのエントリ ポイントであるロールアップ プロトコルがどのように機能するかを見てみましょう。

**Rollup プロトコルのコア コントラクトは RollupProxy.sol です **一貫したデータ構造を保証する条件の下で、珍しいデュアル エージェント構造が使用されています 1 つのエージェントが RollupUserLogic.sol と RollupAdminLogic.sol の 2 つの実装に対応します。 Scan It などはまだ十分に解析できません。

また、チャレンジの管理を担当する **ChallengeManager.sol コントラクトと、不正行為の証明を決定するための OneStepProver シリーズのコントラクトもあります。 **

(写真出典：L2BEAT公式サイト)

RollupProxy では、さまざまな Validator によって送信された一連の RBlock (別名アサーション) が記録されます。これは、以下の図のボックスです: 緑 - 確認済み、青 - 未確認、黄色 - 不正です。

**RBlock には、最後の RBlock 以降の 1 つ以上の L2 ブロックの実行後の最終状態が含まれます。 **これらの RBlock は正式なロールアップ チェーンを形成します (L2 レジャー自体は異なることに注意してください)。楽観的な状況では、このロールアップ チェーンにはフォークがないはずです。フォークとは、バリデーターが競合するロールアップ ブロックを送信したことを意味するためです。

アサーションを提案または同意するには、検証者はまずそのアサーションに対して一定量の ETH をステーキングし、ステーカーになる必要があります。このように、異議・不正証明が発生した場合、敗者の担保は没収され、検証者の誠実な行動を確保するための経済的基盤となります。

図の右下隅にある青いブロック No.111 は、親ブロック No.104 が間違っている (黄色) ため、最終的に改ざんされます。

**さらに、検証者AはロールアップブロックNo.106を提案しましたが、Bはこれに同意せず異議を唱えました。 **

B がチャレンジを開始した後、ChallengeManager コントラクトはチャレンジ ステップの内訳を検証する責任があります。

1. セグメンテーションは、双方が交互に対話するプロセスであり、一方が特定のロールアップ ブロックに含まれる履歴データをセグメント化し、もう一方がデータ断片のどの部分に問題があるかを指摘します。継続的かつ徐々に範囲を狭める二分法 (実際には N/K) に似たプロセス。

2. その後、引き続き問題のあるトランザクションと結果を特定し、それをトランザクション内の係争中の機械命令にさらに細分化することができます。

3. ChallengeManager コントラクトは、元のデータを分割した後に生成された「データ フラグメント」が有効かどうかのみをチェックします。

4. 挑戦者と挑戦者が挑戦すべき機械命令を見つけた後、挑戦者は oneStepProveution() を呼び出し、この機械命令の実行結果に問題があることを証明するためにシングルステップの不正証明を送信します。 **

シングルステップ証明

シングルステップ証明は、Arbitrum の不正証明の中核です。単一ステップ証明が具体的に何を証明するかを見てみましょう。

これには、まず WAVM (**Wasm Arbitrum Virtual Machine) について理解する必要があります。これは、ArbOS モジュールと Geth (Ethereum クライアント) コア モジュールによってコンパイルされた仮想マシンです。 **L2 は L1 とは完全に異なるため、元の Geth コアを軽く変更して ArbOS で動作させる必要があります。

したがって、L2 上の状態遷移は実際には ArbOS + Geth Core の共同作業になります。

Arbitrum のノード クライアント (シーケンサー、バリデーター、フル ノードなど) は、上記の ArbOS+Geth Core 処理プログラムを、ノード ホスト (x86/ARM/PC/Mac/など) が直接処理できるネイティブ マシン コードにコンパイルします。

コンパイル後に得られるターゲット言語を Wasm に変更すると、検証者が不正証明を生成するときに使用する WAVM が取得され、シングルステップ証明を検証するコントラクトも WAVM 仮想マシンの機能をシミュレートします。

**では、なぜ不正証明を生成するときに Wasm バイトコードにコンパイルする必要があるのでしょうか? **主な理由は、シングルステップの不正防止のコントラクトを検証するには、イーサリアム スマート コントラクトを使用して、特定の命令セットを処理できる仮想マシン VM をシミュレートする必要があり、WASM はシミュレーションの実装が簡単であるためです。契約上。

ただし、WASM はネイティブ マシン コードよりも実行速度がわずかに遅いため、Arbitrum のノード/コントラクトは不正証明の生成および検証時にのみ WAVM を使用します。

**インタラクティブなサブディビジョンの前回のラウンドの後、シングルステップ証明により、最終的に WAVM 命令セット内のシングルステップ命令が証明されます。 **

以下のコードに見られるように、OneStepProofEntry はまず、証明される命令のオペレーション コードがどのカテゴリに属しているかを判断し、次に Mem、Math などの対応する証明者を呼び出してシングルステップ命令を渡す必要があります。証明者契約。

最終結果の afterHash が ChallengeManager に返され、そのハッシュが Rollup Block に記録された命令操作後のハッシュと一致しない場合、チャレンジは成功となります。一致していれば、Rollup Blockに記録された本コマンドの実行結果に問題はなく、チャレンジが失敗したことを意味します。

次の記事では、Arbitrum と、Layer2 と Layer1 の間のクロスチェーン メッセージ/ブリッジ機能を処理するコントラクト モジュールを分析し、真の Layer2 が検閲耐性をどのように達成すべきかをさらに明確にします。