元アービットラム技術大使がアービットラムのコンポーネント構造を説明（上）

著者：Benny Luo（元Arbitrumテクニカルアンバサダー、Geek Web3寄稿者）

この記事は、Arbitrumの元テクニカルアンバサダーであり、スマートコントラクトの自動監査会社であるGoplus Securityの元共同設立者であるBenny LuoによるArbitrum Oneの技術解説です。

中国のコミュニティでは、ArbitrumやOP Rollupについて専門的な理解を提供する記事やレイヤー2に関する情報が不足しているため、この記事ではArbitrumの動作の仕組みを説明することで、この分野のギャップを埋めようとしています。

ロールアップ・ソーターの概要

ロールアップ展開の原理は以下のようにまとめられます。

コストの最適化:計算とストレージのタスクの大部分をL1チェーン、つまりL2に移す。L2はほとんどの場合、シーケンサー/オペレーターという1台のサーバーで動作するチェーンです。

シーケンサーは外見上は中央集権的なサーバーに近く、「トリプルコア」とは言い難いブロックチェーン」において、TPSとコストの優位性のために「分散化」をあきらめている。

(Source: BNBチェーン）

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

Fundamentally, Rollup's security is based on Ether.シーケンサーは、そのアカウントの秘密鍵を知らずにアカウントの名前でトランザクションを開始することはできませんし、そのアカウントの資産の残高を改ざんすることもできません（改ざんしたとしても、すぐに検出されるでしょう）。

システムのハブとしてのシーケンサーが枢機卿の要素を持つ一方で、より成熟したロールアップシナリオでは、集中化されたシーケンサーは、トランザクションの検閲や悪意のあるダウンタイムなどのソフトな悪行を犯すことしかできませんが、理想的なロールアップシナリオでは、これを抑制する適切なマニュアルがあります（例えば、強制的な引き出しやプルーフオブシーケンスなどの検閲に強いメカニズム）。

(L1 上のロードマークプロトコル)">（L1上のコントラクトソースコードにロードマークプロトコルが設定し、ユーザが呼び出す強制離脱関数）

そして、ロールアップシーケンサの不正行為を防止するための状態検証方法は、「不正証明」と「有効性証明」の2つに分けられる。不正証明(Fraud Proof)を用いたロールアップ方式は、OPロールアップ(Optimistic Rollup, OPR)と呼ばれ、妥当性証明(Validity Proof)を用いたロールアップは、歴史的な経緯もあり、妥当性証明ロールアップ(Validity Proof Rollup)ではなく、ZKロールアップ(Zero-knowledge Proof Rollup, ZKR)と呼ばれることが多い。Rollup.

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

したがって、OPRには暗黙の信頼前提もある。その代わり、ZKRの契約は暗号計算によってシーケンサーから提出されたデータを積極的かつ安価に検証する。

(Optimistic)ロールアップモード）

(ZK Rollup operation)

本記事では、楽天ロールアップの代表的なアイテムである「アービットラム・ワン」について、システム全体を網羅しながら詳しく紹介していきます。楽観的ロールアップ/OPRstrong>SequencerInbox、DelayedInbox、L1 Gateways、L2 Gateways、Outbox、RollupCore、Bridgeなどがあります。詳細は後ほど。

シーケンサー：

ユーザートランザクションを受け取り、ソートし、結果を計算し、素早く（通常<1s）ユーザーに返します。ユーザーは、自分の取引が数秒以内にL2にアップリンクされるのを見ることが多く、その体験はまさにWeb2プラットフォームのようです。

また、シーケンサーは生成された最新のL2ブロックを即座にイーサチェーンにブロードキャストします。しかしこの時点では、これらの L2 ブロックは最終的なものではなく、シーケンサーによってロールバックされる可能性があります。

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

以上のプロセスから要約すると、レイヤー2には独自のノードネットワークがあるが、その数はまばらで、パブリックチェーンで一般的に使われているコンセンサスプロトコルを持っていないため、セキュリティは低い。レイヤー2には独自のノードネットワークがあるが、これらのノードの数はまばらで、一般的にパブリックチェーンで使用されているコンセンサスプロトコルを持っていないため、セキュリティは非常に低く、データリリースの信頼性と状態遷移の有効性を確保するためにイーサに頼らざるを得ない。

Arbitrum Rollup Protocol:

ロールアップチェーンのRブロックの構造、チェーンの継続、Rブロックのリリース、チャレンジモードプロセスを定義する一連のコントラクト。コントラクト。ここでいうロールアップチェーンとは、レイヤー2の台帳ではなく、アービトラム・ワンが不正証明メカニズムを実装するために独自に設定した抽象化された「チェーンデータ構造」であることに注意。

Rブロックは、全く異なるデータを持つ複数のLayer2ブロックの結果を含むことができ、そのデータエンティティであるRブロックは、一連のRollupCoreコントラクトに格納されます。RBlockに問題がある場合、ValidatorはRBlockの送信者に挑戦する。

Validator:

ArbitrumのValidatorノードは、実際にはLayer2のフルノードの特別なサブセットであり、現在ホワイトリストに登録されています。

Validator は、シーケンサーによってSequencerInboxコントラクトに提出されたトランザクションのバッチに基づいて、新しいRBlockを作成します(Rollupブロック、⾔言アサーションとしても知られている)、そしてシーケンサーによって提出されたエラーデータに挑戦するためにRollupチェーンの現在の状態を監視する。

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

課題：

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

チャレンジ期間：

OPロールアップの楽観的な楽観的な性質のため、契約は各RBlockがチェーンに提出された後、積極的にチェックしない。この期間がチャレンジ期間であり、Arbitrum Oneグリッドでは1週間である。チャレンジ期間が終了すると、RBlockは最終的に検証され、L2からL1に渡されたブロック内の対応するメッセージ（公式ブリッジ経由で行われた引き出しなど）が解放されます。

ArbOS, Geth, WAVM:

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

ここで、上記のコンポーネントとワークフローの関係を以下の図で表すことができます:

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

L2 トランザクションは次のように処理されます:

1. ユーザーはシーケンサーにトランザクション命令を送信します。

2. シーケンサはまず、保留中のトランザクションをデジタル署名と他のデータに検証し、無効なトランザクションを排除し、ソートと演算を実行する。

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

4. シーケンサーは前処理されたトランザクションから生データを取り出し、高度に圧縮し、バッチにカプセル化する。

5. たまに（データ量やETHの混雑などに応じて）、シーケンサーはトランザクションバッチをL1上のシーケンサーインボックスコントラクトにリリースします。 この時点で、トランザクションはハードファイナリティを持つとみなされます。ハードファイナリティ。

Sequencer Inbox Contract

コントラクトはシーケンサーから提出されたトランザクションのバッチを受け取り、データの可用性を確保する。さらに深く見ると、SequencerInbox のバッチデータは Layer2 のトランザクション入力の完全な記録を保持し、たとえシーケンサーが永久にダウンしても、バッチ記録に基づいて誰でも Layer2 の現在の状態を復元し、故障/暴走したシーケンサーから引き継ぐことができます。

物理的に言えば、Layer2として見えているのはSequencerInbox内のバッチの投影に過ぎず、光源はSTFです。 光源であるSTFは簡単には変化しないので、影の形はオブジェクトとして機能するバッチによってのみ決定されます。

シーケンサー・インボックス・コントラクトはファストボックスとして知られ、シーケンサーが前処理済みのトランザクションを提出する専用で、シーケンサーだけがデータを提出できます。ファスト・ボックスと対になるのがスロー・ボックス、ディレイヤー・インボックスで、その機能は次のフローで説明する。

Validatorは常にSequencerInboxコントラクトをリッスンし、シーケンサーがそのコントラクトにバッチを発行するたびに、オンチェーンイベントがスローされ、Validatorがこのイベントの発生をリッスンすると、バッチデータをダウンロードし、ローカルで実行し、ETHチェーンに送信します。

Arbitrumのブリッジ契約にはaccumulatorというパラメータがあります。バッチと同様に、Slow Inboxで受信した新しいトランザクションとメッセージの数です。

(シーケンサーがSequencerInboxにバッチを送信し続ける)

（バッチ固有の情報、データフィールドはバッチデータに対応し、データサイズのこの部分は非常に大きく、スクリーンショットはすべてを表示しませんでした）

SequencerInbox

add Sequencer L2Batch From Origin(),これはシーケンサーがSequencer Inoxコントラクトにバッチデータを送信するたびに呼び出すものです。

force Inclusion(),この関数は、検閲に強いトランザクションを実装するために誰でも呼び出すことができます。この関数が有効になる方法については、後でDelayed Inbox契約について話すときに詳しく説明する。

これらの関数はどちらもbridge.enqueueSequencerMessage()を呼び出し、ブリッジ契約内のアキュムレーター・パラメーターaccumulatorを更新します。h3>

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

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

Layer 2リソースのためにユーザーが負担するコストは、システムの安定稼働を維持するために、毎秒処理されるガスの最大量（Arbitrum Oneの場合は現在700万）に上限が設定されており、L1およびL2ガスのガイドライン価格はArbOSによって追跡・調整されます。はここでは繰り返さない。

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

Proof of Optimistic Fraud

上述したように、L2は実際にはfastbox内のシーケンサーによって提出されたトランザクション入力のバッチの投影に過ぎません。入力 -> STF -> 状態出力。入力はすでに決定されており、STFは一定である。楽観的証明のための一連のシステムである。

L1上には、シーケンサーがポストする入力データと、検証者がポストする出力状態がある。レイヤー2の状態をチェーンに公開する必要があるかどうか、より慎重に考えてみよう。

入力はすでに出力を完全に決定しており、入力データは一般に公開されているので、出力結果の状態を再び提出するのは冗長に思えるのではないでしょうか？しかし、この考えは、L1-L2の2つのシステム間で状態を決済する必要があるという事実を無視している。つまり、L2がL1に対して引き出しを行うためには、状態の証明が必要なのだ。

ロールアップを構築する際、最も注意深く考慮したことの1つは、L1の高コストを避けるために、計算とストレージのほとんどをL2に置くことでした。これは、L1がL2の状態を知らないことを意味し、L2シーケンサーがすべての取引に入力をポストするのを助けるだけで、L2の状態を把握する責任はありません。

L1から資金を引き出すことは、基本的にL2からのクロスチェーンメッセージに従ってL1のコントラクトから資金をアンロックし、ユーザーのL1アカウントに送金する、または他のことを行うことです。

この時点で、レイヤー1のコントラクトは次のように尋ねます：レイヤー2でのあなたのステータスは？この時点で、ユーザーは対応するMerkle Proofなどを与えなければならない。

つまり、もし引き出しのないロールアップを構築するとしたら、理論的にはL1への状態がないロールアップを構築することになります。理論的には、L1への状態同期を実行することなく、キャッシュアウト機能のないロールアップを構築することは可能であり、不正行為の証明のような状態証明システムは必要ない(他の問題を引き起こすかもしれないが)。しかし、実際の使用においては、これは明らかに不可能である。 

いわゆる楽観的証明では、コントラクトはL1に提出された出力状態が正しいかどうかをチェックせず、すべてが正確であると楽観的に仮定します。楽観的証明システムは、任意の瞬間に少なくとも1人の正直なバリデータが存在すると仮定し、不正な状態がある場合、不正な証明によって挑戦される。

この設計の利点は、L1にポストされたすべてのRブロックを積極的に検証する必要がなく、無駄なガスを回避できることである。実際、OPRがすべての言語を検証することは非現実的である。各Rブロックには1つ以上のL2ブロックが含まれているため、L1上ですべてのトランザクションの再実行を実行することは、L1上で再実行を実行するよりもはるかに困難である。各トランザクションをL1上で再実行することは、L2トランザクションをL1上で直接実行することと同じであり、Layer2拡張の目的を失うことになる。

これはZKRの問題ではない。なぜなら、ZK Proofには、そのProofの背後にある多くのトランザクションを実際に実行することなく、非常に小さなProofを検証するという単純さがあるからである。したがって、ZKRは楽観的に動作せず、Verfier契約は状態がポストされるたびに数学的に検証される。

不正の証明はゼロ知識証明ほど高水準の単純さではありませんが、アービトラムは回転式の「マルチラウンド・パーティショニング-シングルステップ証明」相互作用プロセスを使用しており、比較的少ないコストで単一のVMオペコードの証明に終わります。コストは比較的小さい。

The Rollup Protocol

課題を立ち上げ、証明を開始するためのエントリーポイントであるRollupプロトコルがどのように機能するかを見ることから始めましょう。

Rollupプロトコルの中核となる契約はRollupProxy.sol,であり、データ構造の一貫性を保ちながら、1つのプロキシが2つの実装RollupUserLogic.solとRollupAdminLogic.solに対応する、珍しいデュアルプロキシ構造を使用しています。RollupAdminLogic.solの2つの実装に対応しています。

チャレンジを管理するためのChallengeManager.solコントラクトと、不正の証明を決定するためのOneStepProverコントラクトファミリーもあります。

(Source: L2BEAT website)

RollupProxyでは、異なるValidatorによって提出された一連のRBlock(別名Assertion)を記録する。黄色 - 改ざん。

RBlockには、最後のRBlock以降の実行後の、1つ以上のL2ブロックの最終状態が含まれています。.これらのRBlockは正式なロールアップチェーンを形成する（L2元帳自体は別物であることに注意）。楽観的なシナリオでは、このRollup Chainにはフォークがないはずです。フォークがあるということは、Validatorが互いに衝突するRollup Blocksを提出したことを意味するからです。

アサーションを行う、またはアサーションに同意するには、まずValidatorがアサーションに対して一定額のETHを誓約し、Stakerになる必要があります。不正な証明が行われた場合、敗者の誓約は没収され、これが検証者の誠実な行動を保護する経済的根拠となる。

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

さらに、検証者Aはロールアップ・ブロック#106を提案し、Bはそれに異議を唱えます。

Bがチャレンジを開始した後、ChallengeManagerコントラクトは、チャレンジステップのセグメンテーションのプロセスを検証する責任を負う。セグメンテーションとは、2つの当事者が交互にやりとりするプロセスであり、一方の当事者は特定のロールアップブロックに含まれる履歴データをセグメンテーションし、もう一方の当事者はデータ断片のどの部分に問題があるかを指摘する。二項対立（実際にはN/K）に似ており、継続的かつ段階的に範囲を狭めていくプロセスです。

2.その後、どのトランザクションと結果に問題があるかを特定し続け、さらにそのトランザクションで問題となっている特定のマシン命令まで分解することができます。

3.ChallengeManagerコントラクトは、オリジナルデータのセグメンテーションから得られる「データスニペット」の妥当性のみをチェックします。

4.チャレンジャーとチャレンジされる者が、チャレンジされるマシン命令の断片を見つけると、チャレンジャーはoneStepProveExecution()を呼び出し、このマシン命令の問題のある実行結果のワンステップ詐欺証明を送信する。

ワンステップ証明

ワンステップ証明は、アービトラムの詐欺証明の中核をなすものです。証明の核心である。ワンステップ証明が具体的に何を証明するのかを見てみよう。

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

つまり、L2の状態遷移は、実際にはArbOSとGethコアの共同作業なのです。

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

コンパイル後に得られるターゲット言語をWasmに変更すると、検証者が不正証明を生成するために使用するWAVMが得られ、シングルステップ証明を検証するコントラクト上でシミュレートされるのはWAVM VMの機能です。

では、なぜ不正証明を生成するときにWasmバイトコードにコンパイルするのでしょうか？主に、シングルステップの不正証明を検証するコントラクトは、テラフロップスマートコントラクトで特定の命令セットを処理できるVM VMをエミュレートする必要があり、WASMはコントラクトにエミュレーションを実装しやすいからです。

しかし、WASMはネイティブのマシンコードに比べて若干遅いので、アービトルムのノード/コントラクトがWAVMを使うのは、不正証明の生成と検証のときだけです。

以前のインタラクティブな分解を何度も繰り返した後、シングルステップの証明はWAVM命令セットのシングルステップ命令の証明に終わります。

下のコードでわかるように、OneStepProofEntryはまず証明される命令のオペコードがどのクラスに属するかを決定し、Mem、Mathなどの対応する証明器を呼び出し、シングルステップ命令をその証明器のコントラクトに渡します。

最終的なafterHashの結果がChallengeManagerに戻ってきます。ハッシュが操作後にRollup Blockに記録されたハッシュと一致しなければ、チャレンジは成功である。もし一致すれば、Rollup Blockに記録された命令の結果は問題なく、チャレンジは失敗となる。

次の記事では、Arbitrumと、Layer2とLayer1の間のクロスチェーンメッセージング/ブリッジングを処理するコントラクトモジュールについて分析し、真のLayer2がどのように機能すべきかをさらに明らかにする。検閲に対抗するためにLayer2がどのように実装されるべきかの本当の意味。