元ArbitrumテクニカルアンバサダーがArbitrumのコンポーネント構造を説明(パートI)

著者:Benben Luo、元Arbitrumテクニカルアンバサダー、オタクWeb3コントリビューター

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

中国圏のレイヤー2に関する記事や資料は、ArbitrumやOP Rollupの専門的な解釈を欠いているため、この記事では、Arbitrumの操作メカニズムを普及させることで、この分野のギャップを埋めようとしています。 Arbitrum自体の構造が複雑なため、全文は可能な限り単純化することを基本として10,000語を超えているため、2つの記事に分かれており、参考資料として収集して転送することをお勧めします。

ロールアップシーケンサーの簡単な説明

ロールアップ スケーリングの原則は、次の 2 つのポイントに要約できます。

コストの最適化: コンピューティングとストレージのタスクのほとんどを L1 オフチェーン、つまり L2 にオフロードします。 **L2 は、主に 1 つのサーバー、つまりシーケンサー/オペレーター上で動作するチェーンです。

シーケンサーは中央集権的なサーバーに近く、「Blockchain Impossible Three Times」でTPSとコスト優位性と引き換えに「分散化」を放棄しています。 ユーザーは、イーサリアムで取引するよりもはるかに低いコストで、イーサリアムの代わりにL2に取引命令を処理させることができます。

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

基本的に、Rollupsのセキュリティはイーサリアムに基づいています。 シーケンサーが口座の秘密鍵を知らない場合、その口座名義で取引を開始したり、その口座の資産残高を改ざんしたりすることはできません(たとえ知っていたとしても、すぐに認識されます)。

シーケンサーはシステムのバックボーンとして中央集権化されていますが、比較的成熟したロールアップスキームでは、中央集権的なシーケンサーはトランザクションレビューや悪意のあるダウンタイムなどのソフトな悪の振る舞いしか実装できませんが、理想的なロールアップスキームでは、それを抑制するための対応する手段(強制引き出しや注文証明などの検閲抵抗メカニズムなど)があります。

ロールアップシーケンサーが悪事にならないようにするための状態検証方法は、Fraud Proof と Validity Proof の 2 種類に分けられます。 不正証明を使用したロールアップは、OP ロールアップ (オプティミスティック ロールアップ、OPR) と呼ばれ、過去の荷物があるため、有効性の証明を使用するロールアップは、有効性ロールアップではなく ZK ロールアップ (ゼロ知識証明ロールアップ、ZKR) と呼ばれることがよくあります。

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

したがって、OPRは、常に少なくとも1つの誠実なL2バリデータノードが存在するという信頼の前提も意味します。 一方、ZKRの契約では、暗号を使用して、シーケンサーから送信されたデータを積極的かつ費用対効果の高い方法で検証します。

本記事では、オプティミスティック・ロールアップのリーディング・プロジェクトであるArbitrum Oneを、システム全体のあらゆる側面を網羅して詳細に紹介し、注意深く読めば、アービトラムとオプティミスティック・ロールアップ/OPRについて深く理解していただけると思います。

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

コア契約:

Arbitrumの最も重要な契約には、SequencerInbox、DelayedInbox、L1 Gateways、L2 Gateways、Outbox、RollupCore、Bridgeなどがあります。 これについては後で詳しく説明します。

シーケンサー：

ユーザートランザクションが受信およびソートされ、トランザクション結果が計算され、レシートがユーザーに迅速に返されます(通常は1<)。 ユーザーは、Web2プラットフォームのように、L2チェーン上のトランザクションを数秒で確認できることがよくあります。

同時に、シーケンサーはイーサリアムチェーンの下で最新のL2ブロックをリアルタイムでブロードキャストし、どのレイヤー2ノードでも非同期で受信することができます。 ただし、この時点では、これらの L2 ブロックはファイナライズされておらず、シーケンサーでロールバックできます。

数分ごとに、シーケンサーはソートされた L2 トランザクション データを圧縮し、バッチに集約し、レイヤー 1 の受信トレイ コントラクト SequencerInbox に送信して、データの可用性とロールアップ プロトコルの動作を確保します。 一般に、レイヤ 1 に送信された L2 データはロールバックできず、ファイナライズできます。

上記のプロセスから、Layer2は独自のノードネットワークを持っていますが、これらのノードの数は少なく、パブリックチェーンで使用されるコンセンサスプロトコルは一般的にないため、セキュリティは非常に貧弱であり、データリリースの信頼性と状態遷移の有効性を確保するためにイーサリアムに接続する必要があります。

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

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

RBlock には複数の L2 ブロックの結果を含めることができ、データも大きく異なり、そのデータ エンティティ RBlock は RollupCore の一連のコントラクトに格納されます。 RBlock に問題がある場合、バリデーターはその RBlock のコミッターにチャレンジします。

バリデーター：

Arbitrumのバリデータノードは、実際にはレイヤー2フルノードの特別なサブセットであり、現在は許可リストにアクセスできます。

バリデーターは、シーケンサーから SequencerInbox コントラクトに送信されたトランザクションのバッチに基づいて新しい RBlock (ロールアップ ブロック、アサーションとも呼ばれます) を作成し、現在のロールアップ チェーンの状態を監視して、シーケンサーによって送信された誤ったデータにチャレンジします。

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

挑戦：

基本的なステップは、マルチラウンドのインタラクティブなセグメンテーションとシングルステップの証明として要約できます。 セグメンテーションセッションでは、両当事者は、問題のあるステップのオペレーションコード命令が分解されて検証されるまで、問題のあるトランザクションデータのターンベースの細分化を複数回実行するように求められます。 「マルチラウンドセグメンテーション - シングルステッププルーフ」のパラダイムは、Arbitrumの開発者によって、不正プルーフの最もガス効率の高い実装であると考えられています。 すべてが契約管理下にあり、当事者が不正行為を行うことはできません。

チャレンジ期間:

OP Rollupの楽観的な性質により、各RBlockがチェーンに送信された後、コントラクトはそれを積極的にチェックせず、バリデーターが改ざんする時間枠を残します。 この時間枠はチャレンジ期間で、Arbitrum One Mainnetでは1週間です。 チャレンジ期間が終了すると、RBlockがファイナライズされ、ブロック内のL2からL1への対応するメッセージ(公式ブリッジを介して実行される引き出し操作など)を解放できます。

ArbOS、ゲス、WAVM:

Arbitrum で使用される仮想マシンは AVM と呼ばれ、Geth と ArbOS の 2 つの部分で構成されています。 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のバッチデータはレイヤー2のトランザクション入力情報を完全に記録し、シーケンサーが永久にダウンした場合でも、誰でもバッチレコードに基づいてレイヤー2の現在の状態を復元し、故障した/ラグプルシーケンサーを置き換えることができます。

物理的には、L2 として表示されるのは SequencerInbox のバッチの投影にすぎず、光源は STF です。 光源STFは変化しにくいため、影の形状はオブジェクトとして作用するバッチのみで決まる。

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

バリデーターは常にSequencerInboxコントラクトをリッスンし、シーケンサーがコントラクトにバッチをリリースするたびにオンチェーンイベントをスローし、このイベントを聞いた後、バリデータをダウンロードし、ローカル実行後、ETHチェーン上のRollupプロトコルコントラクトにRBlockを解放します。

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

SequencerInbox コントラクトには、主に次の 2 つの機能があります。

シーケンサーが毎回呼び出してバッチデータをシーケンサーイノックスコントラクトに送信するOrigin()からシーケンサーL2Batchを追加します。

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

どちらの関数も bridge.enqueueSequencerMessage() を呼び出して、ブリッジ コントラクトのアキュムレータ パラメータ accumulator を更新します。

ガス料金

明らかに、DoS 攻撃、シーケンサー L2 自体のランニング コスト、および L1 でデータを送信するオーバーヘッドのために、L2 トランザクションを無料にすることはできません。 ユーザーがレイヤー 2 ネットワーク内でトランザクションを開始すると、ガス料金は次のように構成されます。

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

レイヤ2リソースの占有によりユーザーが負担するコストは、システムの安定稼働を確保できる最大ガス/秒数(Arbitrum Oneは現在700万個)に設定されています。 L1とL2の両方のガスガイド価格はArbOSによって追跡および調整されており、当面の間、ここで計算式は繰り返されません。

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

楽観的な不正防止

要約すると、L2 は実際には、Fastbox のシーケンサーによって送信されたトランザクションのバッチ入力の投影にすぎません。

Transaction Inputs -> STF -> State Outputs。 入力が決定され、STFが一定になり、出力も決定され、不正防止とArbitrum Rollupプロトコルのシステムは、出力の状態のルートをRBlock(別名アサーション)の形でL1に公開し、それを楽観的に証明するシステムです。

L1 には、シーケンサーによってパブリッシュされた入力データと、バリデーターによってパブリッシュされた出力ステートがあります。 詳しく見てみましょう、レイヤー2の状態をオンチェーンで公開する必要がありますか?

入力が出力を完全に決定し、入力データが公開されているため、出力状態の送信は冗長に見えますが、この考え方は、L1-L2システム間で実際に状態解決が必要であること、つまり、L1方向のL2の提案された動作であり、状態の証明が必要であるという事実を無視しています。

ロールアップを構築する場合、中核となるアイデアの 1 つは、L1 が L2 の状態を認識せず、L2 シーケンサーがすべてのトランザクションの入力データを公開するのを助けるだけで、L2 の状態を計算する責任を負わないことを意味する L1 の高コストを回避するために、ほとんどのコンピューティングとストレージを L2 に配置することです。

出金動作は、基本的に、L2から与えられたクロスチェーンインタラクションメッセージに従って、L1コントラクトから対応する資金のロックを解除したり、ユーザーのL1アカウントに送金したり、その他のことを完了させたりすることです。

この時点で、レイヤー 1 コントラクトは、レイヤー 2 の状態はどうなっているか、また、クロスすると主張する資産を実際に所有していることをどのように証明できるかを尋ねます。 このとき、ユーザーは対応するマークルプルーフなどを提供する必要があります。

そのため、出金機能のないロールアップを構築すれば、理論的にはL1に状態を同期させないことも可能であり、不正防止などのプルーフ・オブ・ステート・システムは不要になります(他の問題を引き起こす可能性はありますが)。 しかし、実際には、これは明らかに実現不可能です。

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

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

ZK Proofはシンプルで、小さなProofを検証するだけでよく、Proofの背後で実際に多くのトランザクションを実行する必要がないため、ZKRにはこの問題はありません。 したがって、ZKRは楽観的ではなく、リリース状態は毎回Verfierコントラクトによって数学的に検証されます。

不正証明はゼロ知識証明ほど簡潔ではありませんが、Arbitrumは「マルチラウンド分割-単一ステップ証明」のターンバイターンインタラクションプロセスを使用しており、最終的には1つの仮想マシンのオペレーションコードのみを証明する必要があり、コストは比較的低くなります。

ロールアップ プロトコル

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

Rollup プロトコルのコア コントラクトは RollupProxy.sol で、データ構造の一貫性を確保するためにまれなデュアル プロキシ構造を使用しており、1 つのプロキシは RollupUserLogic.sol と RollupAdminLogic.sol の 2 つの実装に対応しており、Scan などのツールではうまく解析できません。

さらに、チャレンジを管理するための ChallengeManager.sol コントラクトと、不正の証拠を判断するための OneStepProver シリーズのコントラクトがあります。

RollupProxy では、さまざまなバリデーターによって送信された一連の RBlock (別名アサーション) が記録されます (次の図の正方形は、緑 - 確認済み、青 - 未確認、黄色 - 改ざん済み)。

RBlock には、最後の RBlock 以降の実行後の 1 つ以上の L2 ブロックの最終状態が含まれます。 これらのRBlockは、形態学的に正式なロールアップチェーンを形成します(L2台帳自体は異なることに注意してください)。 楽観的なシナリオでは、フォークがあるということは、競合するロールアップブロックを送信したバリデーターがいることを意味するため、このロールアップチェーンをフォークすべきではありません。

アサーションを行ったり、アサーションに同意したりするには、バリデーターはまずアサーションに一定量のETHを賭け、ステーカーになる必要があります。 このようにして、異議申し立て/不正証明の場合、敗者の担保が削減され、バリデーターの誠実な行動を保証するための経済的基盤となります。

画像の右下隅にある青色のブロック111は、その親ブロック104がブロック間違っている(黄色)ので、最終的に反証されるであろう。

さらに、バリデータAはロールアップブロック106を提案しますが、Bはこれに反対し、異議を唱えます。

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

1. セグメンテーションは、2 つの当事者が交代で対話するプロセスであり、一方の当事者がロールアップ ブロックに含まれる履歴データをセグメント化し、もう一方の当事者がデータ フラグメントのどの部分に問題があるかを指摘します。 範囲を徐々に狭める二分法(実際にはN / K)プロセスに似ています。

2. その後、どのトランザクションと結果に問題があるかを引き続き特定し、そのトランザクションで争われているマシンインストラクションにさらに細分化することができます。

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

4. チャレンジャーとチャレンジされた側は、チャレンジ対象のマシンインストラクションを見つけると、oneStepProveution()を呼び出し、マシンインストラクションの実行結果に問題があることを証明するために、シングルステップの不正証明を送信します。

ワンステッププルーフ

シングルステップ証明は、Arbitrum全体の不正証明の中核をなすものです。 ステッププルーフが何を証明するかを見てみましょう。

これには、ArbOSモジュールとGeth(イーサリアムクライアント)コアモジュールからコンパイルされた仮想マシンであるWAVM(Wasm Arbitrum Virtual Machine)の理解が必要です。 L2 は多くの点で L1 とは大きく異なるため、オリジナルの Geth コアを軽く変更して ArbOS で動作させる必要がありました。

つまり、L2での状態遷移は、実はArbOS+Geth Coreに共通する機能なのです。

ArbitrumのNode Client(Sequencer、Validator、Full Nodeなど)は、上記のArbOS+Geth Coreで処理したプログラムを、Nodeホストで直接処理できるネイティブマシンコード(x86/ARM/PC/Macなど)にコンパイルします。

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

主な理由は、ワンステップの不正防止を検証するコントラクトは、イーサリアムスマートコントラクトを使用して、特定の命令セットを処理できる仮想マシンVMをシミュレートし、WASMをコントラクトに実装しやすいためです。

ただし、WASMはネイティブマシンコードよりもわずかに遅いため、WAVMは、不正の証拠が生成および検証された場合にのみ、Arbitrumのノード/コントラクトによって使用されます。

これまでの相互作用のセグメンテーションの後、シングルステップ証明は最終的にWAVM命令セットのシングルステップ命令であることが証明されました。

次のコードでわかるように、OneStepProofEntryは、まず証明する命令の演算コードがどのカテゴリに属するかを判断し、次にMem、Mathなどの対応する証明者を呼び出し、ステップバイステップの命令を証明者コントラクトに渡します。

afterHash の最終結果は ChallengeManager に返され、ハッシュが Rollup ブロックに記録されたハッシュと一致しない場合、チャレンジは成功します。 一貫性がある場合は、ロールアップブロックに記録された命令の実行結果に問題がなく、チャレンジが失敗したことを意味します。

次の記事では、Arbitrumとレイヤー2とレイヤー1の間のクロスチェーンインタラクション/ブリッジング機能を処理するコントラクトモジュールを分析し、真のレイヤー2が検閲に強い方法をさらに明らかにします。