元Arbitrumテクニカルアンバサダーが解説するArbitrumのコンポーネント構造（上）

2023.12.26

共有先

TechFlow厳選深潮セレクト

元Arbitrumテクニカルアンバサダーが解説するArbitrumのコンポーネント構造（上）

Arbitrumの動作メカニズムを1記事で解説。

2023.12.26 - 04:18:13

Web3業界の深掘り報道に専念し潮流を洞察

Arbitrumの動作メカニズムを1記事で解説。

執筆：ローベンベン、元Arbitrum テクニカルアンバサダー、ウェブ3貢献者

本稿は、Arbitrumの元テクニカルアンバサダーであり、スマートコントラクト自動監査企業Goplus Securityの元共同創業者であるローベンベンによる、Arbitrum Oneの技術解説である。

中国語圏におけるLayer2関連の資料や記事には、ArbitrumやOP Rollupに関する専門的な解説が不足している。本稿では、Arbitrumの動作メカニズムを科学的に紹介することで、この分野の空白を埋めようとするものである。Arbitrum自体の構造が非常に複雑なため、可能な限り簡略化してもなお1万字を超える長さとなり、上下2部に分けている。参考資料として保存・転送することを推奨する！

Rollup シーケンサーの概要

Rollupのスケーリング原理は次の2点に要約できる：

コスト最適化：大部分の計算およびストレージタスクをL1チェーン外、すなわちL2上に移管する。L2は、通常、単一サーバー（シーケンサー（Sequencer/Operator））上で動作するチェーンである。

シーケンサーは見た目上、中央集権的なサーバーに近く、「ブロックチェーン不可能三角」において「非中央集権性」を犠牲にしてTPSとコストの利点を得る。ユーザーは、イーサリアムよりもはるかに低いコストで、L2に取引処理を任せることができる。

セキュリティ保証：L2上の取引内容および取引後の状態は、イーサリアムL1に同期され、コントラクトによって状態遷移の有効性が検証される。同時に、イーサリアム上にはL2の履歴記録が保持されており、シーケンサーが永久にダウンしても、誰でもイーサリアム上の記録からL2全体の状態を復元できる。

根本的に、Rollupの安全性はイーサリアムに基づいている。シーケンサーが特定アカウントの秘密鍵を知らなければ、そのアカウント名義での取引を発行したり、資産残高を改ざんすることはできない（仮にそうしても、すぐに発覚する）。

シーケンサーはシステムの中核として中央集権的色合いを持つものの、成熟度の高いRollupソリューションでは、中央集権的なシーケンサーは取引の審査などのソフトな悪意行為や、悪意あるダウンのみを実行でき、理想的なRollupソリューションでは、それらを抑制する手段がある（例：強制出金やシーケンス証明などの抗審査メカニズム）。

（ループリングプロトコルがL1コントラクトソースコードに設定した、ユーザーが呼び出す強制出金関数）

Rollupシーケンサーの悪意行為を防ぐための状態検証方法は、詐欺証明（Fraud Proof）と有効性証明（Validity Proof）の2種類に分けられる。詐欺証明を使用するRollupソリューションはOP Rollup（Optimistic Rollup、OPR）と呼ばれ、一方歴史的経緯により、有効性証明を使用するRollupはZK Rollup（Zero-knowledge Proof Rollup、ZKR）と呼ばれることが多く、Validity Rollupとは呼ばれない。

Arbitrum Oneは典型的なOPRであり、L1にデプロイされたコントラクトは、提出されたデータを能動的に検証せず、楽観的に問題ないと見なす。もし提出データに誤りがあれば、L2の検証ノードが自発的に異議を唱える。

したがってOPRには暗黙の信頼前提がある：任意の時点で少なくとも1つの誠実なL2検証ノードが存在すること。ZKRのコントラクトは、暗号計算を通じて、シーケンサーが提出したデータを能動的かつ低コストで検証する。

（オプティミスティックRollupの動作方式）

（ZK Rollupの動作方式）

本稿では、オプティミスティックRollupのリーディングプロジェクトであるArbitrum Oneを深く紹介し、システム全体の各側面を網羅する。読了後には、ArbitrumおよびオプティミスティックRollup/OPRに対する深い理解が得られるだろう。

Arbitrumの主要コンポーネントと動作フロー

主要コントラクト：

Arbitrumの最も重要なコントラクトには、SequencerInbox、DelayedInbox、L1 Gateways、L2 Gateways、Outbox、RollupCore、Bridgeなどがある。以下で詳しく説明する。

シーケンサー（Sequencer）：

ユーザーからの取引を受け取り、順序付けを行い、結果を計算して迅速に（通常<1秒）ユーザーに領収書を返却する。ユーザーは数秒以内に自分の取引がL2に登録されたことを確認でき、Web2プラットフォームのような体験が得られる。

同時に、シーケンサーはイーサリアムチェーン外で最新のL2ブロックを即座に放送する。どのLayer2ノードでも非同期に受信可能である。ただし、この時点ではこれらのL2ブロックは最終確定性を持たず、シーケンサーによってロールバックされる可能性がある。

数分ごとに、シーケンサーは順序付けられたL2取引データを圧縮し、バッチ（Batch）として集約して、L1上のインボックスコントラクトSequencerInboxに提出する。これにより、データ可用性とRollupプロトコルの正常運営が保証される。一般に、L1に提出されたL2データはロールバック不可であり、最終確定性を持つ。

以上のプロセスから次のように要約できる：Layer2は独自のノードネットワークを持つが、そのノード数は少なく、一般的なパブリックチェーンで使われる合意プロトコルもないため、セキュリティは非常に弱く、イーサリアムに依存して、データ公開の信頼性と状態遷移の有効性を確保しなければならない。

Arbitrum Rollupプロトコル：

RollupチェーンのブロックRBlockの構造、チェーンの継続方法、RBlockの公開、および異議申し立てプロセスなどを定義する一連のコントラクト。ここで言うRollupチェーンは、一般的に理解されるLayer2台帳ではなく、Arbitrum Oneが詐欺証明メカニズムを実現するために独立して設けた抽象的な「チェーン状データ構造」であることに注意。

1つのRBlockは複数のL2ブロックの結果を含み、データも異なる。そのデータエンティティRBlockはRollupCoreの一連のコントラクト内に格納される。もしRBlockに問題があれば、Validatorは提出者に対して異議を唱える。

検証者（Validator）：

Arbitrumの検証者ノードは、実際にはLayer2フルノードの特殊なサブセットであり、現在はホワイトリストによるアクセス制限がある。

Validatorは、シーケンサーがSequencerInboxコントラクトに提出した取引バッチをもとに新しいRBlock（Rollupブロック、別名「主張 assertion」）を作成し、Rollupチェーンの現在状態を監視し、シーケンサーが提出した誤ったデータに対して異議を唱える。

能動的なValidatorは、事前にETHチェーン上で資産をステーキングする必要があり、これをStakerと呼ぶこともある。ステーキングしないLayer2ノードは、Rollupの動作状況を監視し、ユーザーに異常警報を送信することはできるが、ETHチェーン上でシーケンサーの誤ったデータに直接干渉することはできない。

異議申し立て：

基本手順は、多段階インタラクティブ分割、単一ステップ証明に要約できる。分割フェーズでは、異議のある取引データを双方が複数回にわたって交互に細分化し、最終的に問題のある個々のマシン命令まで分解して検証する。「多段階分割 - 単一ステップ証明」というパターンは、Arbitrum開発者が詐欺証明の中で最もガスを節約できる実装方法と見なしている。すべての工程はコントラクトによって管理されており、どちらの当事者も不正を行うことはできない。

異議期間：

OP Rollupの「楽観的（optimistic）」性質により、各RBlockがチェーンに提出された後、コントラクトは能動的に検証せず、検証者に誤りを立証するための時間枠を予約しておく。この時間枠を異議期間と呼び、Arbitrum Oneメインネットでは1週間である。異議期間終了後、そのRBlockは最終的に承認され、RBlock内のL2からL1へのメッセージ（公式ブリッジによる出金操作など）が解放される。

ArbOS、Geth、WAVM：

Arbitrumが採用する仮想マシンはAVMと呼ばれ、GethとArbOSの2つの部分からなる。Gethはイーサリアムで最もよく使われるクライアントソフトウェアであり、Arbitrumはそれを軽量に改造している。ArbOSはL2に関連するすべての特別機能を担当し、ネットワークリソース管理、L2ブロック生成、EVMとの協働などを行う。両者の組み合わせをネイティブAVM、すなわちArbitrumが採用する仮想マシンとみなす。WAVMは、AVMのコードをWasmにコンパイルした結果である。Arbitrumのチャレンジプロセスにおいて、最後の「単一ステップ証明」が検証するのはWAVM命令である。

ここまでの各コンポーネント間の関係と動作フローを以下の図で示す：

L2取引ライフサイクル

L2取引の処理フローは以下の通り：

1.ユーザーがシーケンサーに取引命令を送信する。

2.シーケンサーは、未処理の取引に対してデジタル署名などのデータ検証を行い、無効な取引を除外し、順序付けと計算を行う。

3.シーケンサーは取引領収書をユーザーに送信する（通常非常に高速）。しかし、これはイーサリアムチェーン外での「前処理」であり、Soft Finalityの状態であり、信頼性は高くない。ただし、シーケンサーを信頼するユーザー（大多数）にとっては、取引が完了し、ロールバックされることはないという楽観的な見方ができる。

4.シーケンサーは前処理済みの取引元データを高度に圧縮し、バッチ（Batch）としてパッケージ化する。

5.一定時間ごと（データ量、ETHの混雑状況などに影響される）、シーケンサーはL1上のSequencer Inboxコントラクトに取引バッチを公開する。この時点で、取引は最終性（Hard Finality）を持っていると見なせる。

Sequencer Inboxコントラクト

コントラクトはシーケンサーが提出する取引バッチを受け取り、データ可用性を保証する。詳細に見ると、SequencerInboxのバッチデータはLayer2の取引入力情報を完全に記録しており、シーケンサーが永久にダウンしても、誰でもバッチ記録からLayer2の現在状態を復元でき、故障または脱走したシーケンサーを引き継げる。

物理的な比喩で言えば、私たちが見るL2は、SequencerInboxのバッチの投影であり、光源はSTFである。光源STFは簡単に変化しないため、影の形はバッチという物体によってのみ決まる。

Sequencer Inboxコントラクトは「ファストボックス」とも呼ばれ、シーケンサーがすでに前処理済みの取引を専用に提出するものであり、提出はシーケンサーのみが行える。対照的に「スローボックス」Delayer Inboxもあり、その機能は後述する。

Validatorは常にSequencerInboxコントラクトを監視しており、シーケンサーがこのコントラクトにバッチを公開するたびに、オンチェーンイベントが発生し、Validatorはこのイベントを検知するとバッチデータをダウンロードして、ローカルで実行した後、ETHチェーン上のRollupプロトコルコントラクトにRBlockを提出する。

Arbitrumのbridgeコントラクトには累算器（accumulator）というパラメータがあり、新しく提出されたL2バッチ、およびスローボックスに新しく受け取った取引数と情報を記録する。

（シーケンサーがSequencerInboxに不断にバッチを提出）

（バッチの具体的な情報。dataフィールドがバッチデータに対応。このデータはサイズが大きいため、スクリーンショットでは完全に表示されていない）

SequencerInboxコントラクトには2つの主要関数がある：

addSequencerL2BatchFromOrigin()、シーケンサーは毎回この関数を呼び出してSequencerInboxコントラクトにバッチデータを提出する。

forceInclusion()、この関数は誰でも呼び出せ、抗審査取引を実現する。この関数の動作方法については、後述のDelayed Inboxコントラクトの項で詳しく説明する。

上記2つの関数はいずれもbridge.enqueueSequencerMessage()を呼び出し、bridgeコントラクト内の累算器パラメータaccumulatorを更新する。

Gas価格設定

明らかに、L2の取引は無料ではありえない。DoS攻撃が発生するためであり、またシーケンサー自身のL2運営コストやL1へのデータ提出にも費用がかかる。ユーザーがLayer2ネットワーク内で取引を開始する際、gas料金の構造は以下の通り：

L1リソース使用によるデータ公開コスト、主にシーケンサーが提出するバッチ（各バッチには多数のユーザー取引が含まれる）から発生し、コストは最終的に取引発信者たちで均等に分担される。データ公開に伴う手数料の価格設定アルゴリズムは動的であり、シーケンサーは最近の損益状況、バッチサイズ、現在のイーサリアムgas価格に基づいて価格を設定する。

ユーザーがL2リソースを使用することによるコスト、システムの安定稼働を保証できるように、毎秒処理可能なgasの上限を設定している（現在Arbitrum Oneは700万gas）。L1およびL2のgas指標価格はArbOSが追跡・調整しており、式はここでは省略する。

具体的なgas価格の計算プロセスは比較的複雑だが、ユーザーはこれらの詳細を意識する必要はなく、Rollup取引手数料がETHメインネットよりもはるかに安いことを明確に感じ取れる。

オプティミスティック詐欺証明

前述の内容を振り返ると、L2は実際にはシーケンサーがファストボックスに提出した取引入力バッチの投影にすぎず、つまり：

取引入力 → STF → 状態出力。入力が確定し、STFが不変であれば、出力結果も確定する。そして、詐欺証明およびArbitrum Rollupプロトコルというシステムは、出力の状態ルートをRBlock（＝主張）の形式でL1に公開し、それを楽観的に証明する仕組みである。

L1上にはシーケンサーが公開した入力データと、検証者が公開した出力状態がある。さらに深く考えてみよう。L2の状態をオンチェーンに公開する必要があるだろうか？

入力が完全に結果を決定し、入力データは公開されているため、出力結果—状態を再提出するのは冗長ではないか？しかし、この考え方はL1-L2の2つのシステム間に実際には状態決済が必要であることを無視している。つまりL2からL1への出金行為には、状態の証明が必要である。

Rollupを構築する際の最も核心的な思想は、大部分の計算とストレージをL2に移してL1の高額な費用を回避することである。つまり、L1はL2の状態を知らない。L1はただL2シーケンサーが全取引入力を公開するのを支援するだけであり、L2の状態を計算する責任はない。

出金行為は本質的に、L2が提供するクロスチェーンメッセージに従い、L1のコントラクトから対応する資金を解放し、ユーザーのL1アカウントに移動させたり他の処理を行ったりすることである。

このときL1のコントラクトは問う：あなたのL2上の状態はどうなっているのか、本当に宣言した資産を跨いで持ち出せるという証拠はあるのか。このときユーザーは対応するMerkle Proofなどを提示しなければならない。

したがって、出金機能を持たないRollupを構築すれば、理論的にはL1に状態同期を行わず、詐欺証明などの状態証明システムも不要になる（ただし他の問題を引き起こす可能性がある）。しかし、現実の応用においては明らかに不可能である。

いわゆる楽観的証明とは、L1に提出された出力状態が正しいかどうかをコントラクトが検証せず、楽観的にすべて正確だと見なすことを指す。楽観的証明システムは、任意の時点で少なくとも1人の誠実なValidatorが存在すると仮定しており、誤った状態があれば、詐欺証明を通じて異議を唱える。

このような設計の利点は、L1に公開される各RBlockを能動的に検証する必要がなく、ガスの浪費を避けることができる点にある。実際、OPRの場合、すべての主張を検証することは非現実的である。各RBlockは1つ以上のL2ブロックを含んでおり、L1上で各取引を再実行するのは、L1上でL2取引を直接実行するのと同じであり、これではLayer2のスケーリング意義が失われる。

ZKRにはこの問題は存在しない。なぜならZK証明は簡潔性を持っており、背後にある多数の取引に対応する非常に小さな証明を検証するだけでよく、証明に対応する多くの取引を実際に実行する必要がないからである。そのためZKRは楽観的ではなく、状態を公開するたびにVerifierコントラクトが数学的に検証を行う。

詐欺証明はゼロ知識証明ほど高い簡潔性を持たないが、Arbitrumは「多段分割 - 単一ステップ証明」という交互式プロセスを用いることで、最終的に証明が必要なのは単一の仮想マシン命令コードだけになり、コストが比較的小さい。

Rollupプロトコル

まず、異議申し立てと証明の入口を見てみよう。つまり、Rollupプロトコルがどのように動作するかを確認する。

Rollupプロトコルの中心コントラクトはRollupProxy.solである。データ構造を一致させる前提で、実装が2つある珍しい二重プロキシ構造を採用しており、1つのプロキシが2つの実装RollupUserLogic.solおよびRollupAdminLogic.solに対応している。Scanなどのツールではまだうまく解析できない。

他にChallengeManager.solコントラクトが異議管理を担当し、OneStepProverシリーズコントラクトが詐欺証明を判定する。

RollupProxyでは、異なるValidatorが提出した一連のRBlock（＝主張）を記録している。下図の四角：緑色－確認済み、青色－未確認、黄色－偽であることが証明済み。

RBlockには、直前のRBlock以降の1つ以上のL2ブロック実行後の最終状態が含まれている。これらのRBlockは形状上、形式的なRollupチェーンを形成している（L2台帳自体とは区別する）。楽観的な場合、このRollupチェーンにはフォークがないはずだ。フォークがあるということは、Validatorが互いに矛盾するRollupブロックを提出したことを意味する。

主張を提出または支持するには、検証者がまずその主張に対して一定量のETHをステーキングし、Stakerとなる必要がある。こうすることで、異議申し立て／詐欺証明が発生した際に敗者のステークが没収され、検証者の誠実な行動を経済的に保障する基盤となる。

図の右下にある111番の青ブロックは最終的に偽であることが証明される。なぜならその親ブロックである104番ブロックが誤っている（黄色）からである。

さらに、検証者Aが106番Rollupブロックを提出したが、Bが同意せず、これに異議を唱えた。

Bが異議を唱えた後、ChallengeManagerコントラクトが異議手順の細分化プロセスを検証する：

1. 細分化は双方が交互に行うプロセスであり、一方が特定のRollupブロックに含まれる履歴データを分割し、他方がどのデータ断片に問題があるかを指摘する。二分法（実際はN/K）のように範囲を徐々に狭めていくプロセスである。

2. その後、どの取引と結果に問題があるかをさらに特定し、さらにその取引の中で論争のあるマシン命令まで細分化する。

3. ChallengeManagerコントラクトは、元データを細分化した後に生じる『データ断片』が有効かどうかをチェックするだけである。

4. 挑戦者と被挑戦者が異議のあるマシン命令を特定した後、挑戦者はoneStepProveExecution()を呼び出して単一ステップ詐欺証明を送信し、このマシン命令の実行結果に問題があることを証明する。

単一ステップ証明

単一ステップ証明は、Arbitrumの詐欺証明の核心である。単一ステップ証明が具体的に何を証明しているかを見てみよう。

まずWAVMを理解する必要がある。Wasm Arbitrum Virtual Machineは、ArbOSモジュールとGeth（イーサリアムクライアント）コアモジュールを共同でコンパイルした仮想マシンである。L2とL1には多くの違いがあるため、元のGethコアは軽量に修正され、ArbOSと協調して動作しなければならない。

したがって、L2の状態遷移は実際にはArbOS＋Gethコアの共同作業によるものである。