元アービトラム技術大使が解釈したアービトラムの構成要素構造(その1)

中国のコミュニティでは、Layer2プロトコル、特にArbitrumとOP Rollupに関連する記事や資料の専門的な解釈が不足しているため、この記事では、Arbitrumの運用メカニズムを説明することでこのギャップを埋めることを目的としています。 Arbitrum自体の複雑さにより、全文は、可能な限り簡略化された後でも、10,000語を超えています。 そのため、2つのパートに分かれており、参考資料として保存・共有することをおすすめします。

ロールアップ シーケンサーの概要

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

コストの最適化:ほとんどの計算タスクとストレージタスクを、L1 で動作するレイヤー 2 に転送します。 L2 は、ほとんどの場合、シーケンサー/オペレーターと呼ばれる 1 台のサーバー上で実行され、別のチェーンを形成します。

シーケンサーは、知覚の点では中央集権的なサーバーのように見え、「ブロックチェーンの不可能な三位一体」での分散化を放棄して、TPSとコストで優位に立っています。 ユーザーは、イーサリアムの代わりにL2を使用してトランザクションの指示を処理できるため、イーサリアムでのトランザクションと比較してはるかに低いコストで処理できます。

(出典:BNB Chain)

セキュリティ保証:L2のトランザクションコンテンツとトランザクション後の状態はイーサリアムL1に同期され、その有効性は状態遷移のコントラクトを通じて検証されます。 同時に、イーサリアムはL2の履歴を保持しているため、シーケンサーが恒久的にクラッシュした場合でも、他の人はイーサリアムの記録を通じてL2全体の状態を再構築できます。

基本的に、Rollupのセキュリティはイーサリアムに依存しています。 シーケンサーが口座の秘密鍵を知らない場合、その口座に代わって取引を開始したり、口座の資産残高を操作したりすることはできません(たとえ試みたとしても、すぐに検出されます)。

中央ハブとしてのシーケンサーには集中的な側面がありますが、成熟したロールアップ ソリューションでは、集中型シーケンサーは、トランザクションの検閲や悪意のあるクラッシュなどのソフトな悪意のあるアクティビティにのみ関与できます。 理想的なロールアップのシナリオでは、強制的な撤回や反検閲メカニズムの証明の順序付けなど、そのような行動を抑制するための対応する措置があります。

(Loopringプロトコルは、L1のコントラクトソースコードに強制引き出し機能を設定し、ユーザーが呼び出すことができます)

ロールアップ シーケンサーによる悪意のあるアクションを防止するための状態検証メカニズムは、Fraud Proof と Validity Proof の 2 つのカテゴリに分類されます。 Fraud Proof を使用するロールアップ ソリューションは OP ロールアップ (オプティミスティック ロールアップ、OPR) と呼ばれますが、Validity Proof を使用するロールアップ ソリューションは、履歴の手荷物があるため、有効性ロールアップではなく ZK ロールアップ (ゼロ知識証明ロールアップ、ZKR) と呼ばれることがよくあります。

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

したがって、OPRは、常に少なくとも1つの誠実なL2バリデータノードが存在するという信頼の前提を意味します。 一方、ZKRは、シーケンサーから提出されたデータを暗号計算によって積極的かつ安価に検証します。

(オプティミスティック・ロールアップ操作法)

(ZKロールアップ操作方法)

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

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

コア契約:

Arbitrum で最も重要なコントラクトには、SequencerInbox、DelayedInbox、L1 ゲートウェイ、L2 ゲートウェイ、Outbox、RollupCore、Bridge などがあります。 これらについては、次のセクションで詳しく説明します。

シーケンサー：

シーケンサーは、ユーザー トランザクションを受信し、並べ替え、トランザクション結果を計算し、すばやく (通常は <1) レシートをユーザーに返します。 ユーザーは数秒以内にL2でトランザクションを確認することが多く、Web2プラットフォームと同様のエクスペリエンスを提供します。

同時に、シーケンサーは、イーサリアムのオフチェーンで生成された最新のL2ブロックを即座にブロードキャストします。 すべてのレイヤ 2 ノードは、これらの L2 ブロックを非同期に受信できます。 ただし、これらの L2 ブロックはこの時点ではファイナリティを持たず、シーケンサーでロールバックできます。

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

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

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

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

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

バリデーター:

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

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

Active Validatorは、事前に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 つの組み合わせをネイティブ AVM と見なし、Arbitrum が使用する仮想マシンです。 WAVM は、AVM コードを Wasm にコンパイルした結果です。 アービトラム・チャレンジ・プロセスでは、最後の「ワンステップ証明」でWAVM命令が検証されます。

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

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

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

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

2. シーケンサは、まずデジタル署名などのデータに処理するトランザクションを検証し、無効なトランザクションを排除し、シーケンスと計算を行います。

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

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

5. シーケンサーは、データ量や ETH の輻輳などの要因の影響を受けて、L1 のシーケンサー受信トレイ コントラクトにトランザクション バッチを発行することがあります。 この時点で、トランザクションはハードファイナリティを持っていると考えることができます。

シーケンサー受信ボックス契約

コントラクトは、データの可用性を確保するために、シーケンサーによって送信されたトランザクションバッチを受信します。 これをより深く見ていくと、シーケンサー受信トレイのバッチデータには、Layer2のトランザクション入力情報が完全に記録されています。 シーケンサーが永続的にダウンしている場合でも、バッチ記録に基づいてレイヤー 2 の現在の状態を復元し、障害のあるシーケンサーを交換できます。

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

シーケンサー受信トレイ コントラクトは、高速ボックスと呼ばれます。 シーケンサーは、前処理されたトランザクションをシーケンサーに明示的に送信し、シーケンサーのみがデータを送信できます。 対応する高速ボックスは低速ボックスDelayer Inboxであり、その機能は以降のプロセスで説明する。

バリデーターは、常にシーケンサーの受信トレイコントラクトを監視します。 シーケンサーがコントラクトにバッチをリリースするたびに、オンチェーンイベントが生成されます。 バリデーターは、このイベントの発生を検出すると、バッチデータをダウンロードします。 ローカル実行後、RBlockはETHチェーン上のRollupプロトコルコントラクトに発行されます。

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

(シーケンサーは、シーケンサーの受信トレイにバッチを継続的に送信します)

(バッチの特定の情報。データフィールドはバッチデータに対応します。 データのこの部分のサイズは非常に大きく、スクリーンショットは完全には表示されません。

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

Origin()からシーケンサーL2Batchを追加

シーケンサーは、バッチ データを Sequencer Inox コントラクトに送信するたびにこの関数を呼び出します。

強制インクルージョン()

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

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

ガス料金

明らかに、L2トランザクションはDoS攻撃につながるため、無料にすることはできません。 また、選別機L2自体の運用コストがかかり、L1でデータを提出するためのオーバーヘッドが発生します。 ユーザーがレイヤー 2 ネットワーク内でトランザクションを開始すると、ガス料金体系は次のようになります。

レイヤー 1 リソースの占有によって発生するデータ公開コスト

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

レイヤ 2 リソースを占有するユーザによって発生するコスト

システムの安定稼働のためにTPSのガスリミットを設けています(現在Arbitrum Oneでは700万個)。 L1とL2の両方のガスガイダンス価格はArbOSによって追跡および調整されており、計算式は今のところここでは詳しく説明していません。

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

楽観的な不正防止

上記を思い出すと、L2 は実際には、シーケンサーによって高速ボックスで送信されたトランザクション入力バッチの投影にすぎません。

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

L1 には、シーケンサーによってパブリッシュされた入力データと、ベリファイアによってパブリッシュされた出力ステータスがあります。 慎重に検討しましょう:レイヤー2のステータスをチェーンに公開する必要がありますか?

入力が出力を完全に決定し、入力データが公開されているため、出力結果状態を送信するのは冗長に思われますか? しかし、この考え方は、L1とL2の2つのシステム間の状態決済の実際の必要性、つまり、L2からL1への撤退行動には状態の証明が必要であることを無視しています。

Rollup を構築する際の中核となるアイデアの 1 つは、L1 の高コストを回避するために、コンピューティングとストレージのほとんどを L2 に配置することです。 つまり、L1 は L2 のステータスを認識せず、L2 を支援するだけです。 シーケンサーは、すべてのトランザクションの入力データをパブリッシュしますが、L2 の状態の計算は行いません。

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

このとき、レイヤー1の契約では、レイヤー2でのステータスはどうなっているのか、また、譲渡すると宣言した資産を実際に所有していることを証明する方法はどうすればよいか、という質問が行われます。 このとき、利用者は対応するマークルプルーフ等を提供しなければなりません。

そのため、引き出し機能なしでRollupをビルドすれば、理論的にはL1に状態を同期させないことも可能であり、不正防止などの状態証明システムは不要になります(他の問題を引き起こす可能性はありますが)。 しかし、実際のアプリケーションでは、これは明らかに実現不可能です。

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

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

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

不正証明はゼロ知識証明ほど簡潔ではありませんが、Arbitrumは「セグメンテーションのマルチラウンド-ワンステップ証明」ターンベースのインタラクティブプロセスを使用しています。 結局のところ、証明する必要があるのは単一の仮想マシン操作コードのみであり、コストは比較的小さいです。

ロールアップ プロトコル

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

Rollup プロトコルのコア コントラクトは RollupProxy.sol です。 これは、データ構造の一貫性を確保しながら、まれなデュアルエージェント構造を使用します。 1 つのエージェントは、RollupUserLogic.sol と RollupAdminLogic.sol の 2 つの実装に対応していますが、Scan などのツールでは適切に解析できません。

さらに、ChallengeManager.sol コントラクトはチャレンジの管理を担当し、OneStepProver シリーズのコントラクトは不正の証拠を判断するために使用されます。

(出典:L2BEAT公式サイト)

これは、下図のボックスである、異なるバリデーターによって送信された一連のRBlock(別名アサーション)をRollupProxyに記録する方法を示しています。

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

アサーションを提案または同意するには、検証者はまずアサーションに対して一定量のETHを賭け、ステーカーになる必要があります。 このようにして、異議申し立て/詐欺の証拠が発生すると、敗者の担保が削減されます。 これは、検証者の誠実な行動を確保するための経済的基盤です。

写真の右下隅にある青いブロックNo.111は、親ブロックNo.104(黄色)が間違っているため、最終的にスラッシュされます。

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

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

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

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

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

4. チャレンジャーとチャレンジパーティは、チャレンジ対象となるマシンインストラクションを見つけると、「oneStepProveExecution()」関数を呼び出し、ワンステップ不正証明を送信して、このマシンインストラクションの実行結果に問題があることを証明します。

ワンステッププルーフ

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

そのためには、まずWAVMを理解する必要があります。 Wasm Arbitrum Virtual Machineは、ArbOSモジュールとGeth(イーサリアムクライアント)コアモジュールでコンパイルされた仮想マシンです。 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ブロックに記録されたこの命令の実行結果に問題はなく、チャレンジは失敗していることを意味します。

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

免責事項：

1. この記事は[WeChat]からの転載です。 すべての著作権は原著作者[羅弁弁論]に帰属します。 この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。