活動中心

創作者招募

校園大使

影片創作者

每日學堂

熱點打卡

元アルビトラムテックアンバサダー: Arbitrumのコンポーネント構造（パート1）

初級編

イーサリアム

2/27/2024, 2:27:46 AM

この記事は、Arbitrumの元技術アンバサダーであり、スマートコントラクトの自動化監査企業であるGoplus Securityの共同創設者であるLuo Benben（罗奔奔）によるArbitrum Oneの技術解釈を提供しています。

元のタイトルを転送：

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

Layer 2に関連する中国語の記事や資料において、ArbitrumやOP Rollupの専門的な解釈が不足しているため、この記事はArbitrumの動作メカニズムを普及することによってこの分野のギャップを埋めようとしています。 Arbitrum自体の構造があまりにも複雑であるため、テキスト全体をできるだけ簡略化しましたが、それでも1万語を超えているため、2つに分割されています。参考のために収集して転送することをお勧めします！

Rollupシーケンサーの簡単な紹介

Rollup拡張の原則は、次の2つのポイントに要約されます:

コスト最適化：ほとんどの計算およびストレージタスクをオフチェーンL1、すなわちL2に移行します。 L2は、主に1台のサーバーで実行されているチェーンであり、シーケンサー/オペレーターでもあります。

シーケンサーはある意味で中央集権的なサーバーに近いです。“ブロックチェーンの不可能な三位一体”では、“分散化”がTPSとコストの利点と引き換えに放棄されます。ユーザーは、イーサリアムで取引するよりもL2に取引指示を処理させることができ、コストがはるかに低くなります。

(出典:BNB Chain)

セキュリティ保証：Layer 2上の取引内容およびその結果の状態は、その有効性が契約を介して検証されるEthereum Layer 1に同期されます。一方、EthereumはL2の履歴記録を保持しているため、シーケンサーが永久にクラッシュしても、他の者はEthereum上の記録からL2の全体の状態を再構築することができます。

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

シーケンサーはシステムの中心ハブとして、集中的な色調を持っているかもしれませんが、成熟したRollupソリューションでは、中央集権的なシーケンサーはトランザクションの検閲や悪意のあるクラッシュなどの軽微な悪意の行動にしか関与できません。ただし、理想的なRollupソリューションでは、そのような行動を抑制するための対策があります（強制的な引き出しや検閲防止メカニズムとしてのソーティングプルーフなど）。

（Loopringプロトコルは、L1の契約ソースコードに強制引き出し機能を設定し、ユーザーが呼び出せるようにしています）

Rollupシーケンサーによる悪意のある行動を防ぐために、2種類の状態検証方法があります: 詐欺証明と妥当性証明。詐欺証明を使用するRollupソリューションは、楽観的Rollup（OPR）と呼ばれますが、妥当性証明を使用するものはしばしばZero-knowledge Proof Rollup（ZKR）と呼ばれます。歴史的な経緯から、妥当性RollupというよりもZK Rollupと呼ばれます。

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

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

(Optimistic Rollup操作方法)

(ZK Rollup操作方法)

この記事では、Optimistic RollupのトッププロジェクトであるArbitrum Oneについて、システムのすべての側面を網羅した詳細な紹介を提供します。注意深く読むことで、ArbitrumとOptimistic Rollup（OPR）について深い理解を得ることができます。

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

コア契約：

Arbitrumで最も重要な契約には、SequencerInbox、DelayedInbox、L1 Gateways、L2 Gateways、Outbox、RollupCore、Bridgeなどが含まれます。これらは後で詳細に説明されます。

シーケンサー：

ユーザートランザクションを受け取り、シーケンスを行い、トランザクション結果を計算し、通常は1秒未満でユーザーにレシートを迅速に返します。ユーザーは通常、数秒以内にL2でトランザクションが確認され、Web2のような体験を提供できます。

さらに、シーケンサーはすぐに最新の生成されたL2ブロックをEthereumチェーンの下でブロードキャストしますが、Layer 2ノードは非同期的に受信できます。ただし、この時点では、これらのL2ブロックには最終性がなく、シーケンサーによってロールバックされる可能性があります。

数分ごとに、シーケンサーはシーケンス化されたL2トランザクションデータを圧縮し、それらをバッチにまとめてLayer 1のSequencerInboxコントラクトに提出して、データの可用性とRollupプロトコルの動作を確保します。一般的に、Layer 1に提出されたL2データは取り消すことができず、確定性を持つことができます。

上記のプロセスから、レイヤー2には独自のノードネットワークがありますが、これらのノードは数が少なく、一般的にパブリックブロックチェーンで一般的に使用されるコンセンサスプロトコルが不足していると要約できます。そのため、セキュリティが悪く、データ公開の信頼性や状態遷移の有効性を確保するためにイーサリアムに頼らざるを得ません。

Arbitrumロールアッププロトコル：

Rollupチェーン上のRBlocksと呼ばれるブロックの構造、チェーンの継続、RBlocksの公開、およびチャレンジモードプロセスなどを、一連の契約を通じて定義します。ここで言及されているRollupチェーンは、一般的にLayer 2として理解される台帳ではなく、Arbitrum Oneによって独自に設定された抽象的な「チェーン様のデータ構造」です。

RBlockには複数のL2ブロックの結果が含まれることがあり、そのデータエンティティであるRBlockは、RollupCore内の一連の契約に格納されています。RBlockに問題がある場合、検証者は、RBlockの作成者からの提出に基づいてそれに異議を申し立てます。

検証者:

Arbitrumのバリデータは実際にはLayer 2フルノードの特別なサブセットであり、現在はホワイトリスト入場制限があります。

バリデータは、シーケンサーによってシーケンサーインボックス契約に提出されたトランザクションのバッチに基づいて、新しいRBlocks（ロールアップブロック、アサーションとも呼ばれる）を作成し、ロールアップチェーンの現在の状態を監視して、シーケンサーによって提出された不正確なデータに対処します。

アクティブな検証者は、事前にイーサリアムチェーンに資産をステークする必要があり、時々ステーカーと呼ばれます。資産をステークしないLayer 2ノードは、Rollupの運用を監視し、イーサリアムチェーン上のシーケンサーによって提出された誤ったデータについてユーザーに警告を送信できますが、直接介入することはできません。

チャレンジ：

基本的な手順は、マルチラウンドのインタラクティブな細分化と単一ステップの証明として要約することができます。細分化フェーズでは、両当事者がまず問題のあるトランザクションデータのマルチラウンドのインタラクティブな細分化を行い、問題のあるオペコード命令が分解されて検証されるまで行います。「マルチラウンド細分化-単一ステップ証明」のパラダイムは、Arbitrumの開発者によって、最もガス効率の良い詐欺証明の実装と見なされています。すべての手順はスマートコントラクトによって制御され、どちらの当事者も不正をすることはできません。

チャレンジ期間：

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

ArbOS、Geth、WAVM：

Arbitrumは、GethとArbOSからなるAVMと呼ばれる仮想マシンを使用しています。 GethはEthereumの最も一般的に使用されるクライアントソフトウェアであり、Arbitrumはそれに軽微な修正を加えています。 ArbOSは、ネットワークリソースの管理、L2ブロックの生成、およびEVMとの連携など、すべてのL2関連特殊機能を担当しています。私たちは、両者の組み合わせをNative AVMと見なしており、これはArbitrumが使用している仮想マシンです。WAVMは、AVMコードをWasmにコンパイルした結果です。 Arbitrumのチャレンジプロセスでは、最終的な「単一ステップ証明」がWAVM命令を検証します。

ここでは、以下の図を使用して、さまざまなコンポーネント間の関係やワークフローを表現することができます。

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

L2トランザクションの処理フローは次のようになります:

ユーザーはシーケンサーにトランザクションの指示を送信します。
シーケンサーはまず、処理される取引のデータ、デジタル署名などを検証し、無効な取引を取り除き、それから順序付けして計算します。
シーケンサーは取引の受領をユーザーに送信します（通常は非常に迅速ですが）、しかし、これはイーサリアムチェーン上のシーケンサーによる「前処理」に過ぎず、ソフトファイナリティの状態であり、信頼性はありません。ただし、シーケンサーを信頼するユーザー（ほとんどのユーザー）にとっては、楽観的に取引が完了したと想定し、取引が取り消されないと仮定できます。
シーケンサーは、事前処理されたトランザクションデータを高度に圧縮してバッチにカプセル化します。
一定の間隔で(データ量やイーサリアムの輻輳などの要因の影響を受けて)、シーケンサーはトランザクションバッチをL1のシーケンサー受信トレイコントラクトに公開します。この時点で、トランザクションはハードファイナリティを持っていると考えることができます。

シーケンサー受信トランザクション

この契約は、データの利用可能性を確保するためにシーケンサによって提出されたトランザクションのバッチを受け取ります。詳しくは、シーケンサ・インボックス内のバッチデータは、Layer2のトランザクション入力情報を完全に記録しています。シーケンサが永久にクラッシュしても、誰でもバッチの記録に基づいてLayer2の現在の状態を復元し、失敗/欠落したシーケンサを引き継ぐことができます。

物理的な類推では、私たちがL2として見ているものは、シーケンサーインボックス内のバッチの投影にすぎず、光源はソフトファイナリティです。光源であるソフトファイナリティは簡単に変化しないため、影の形は対象として機能するバッチによってのみ決定されます。

シーケンサーインボックス契約は、高速ボックスとも呼ばれ、シーケンサーが特に事前処理されたトランザクションをそれに提出し、シーケンサーだけがそれにデータを提出できます。対応する遅いボックスはデレイヤーインボックスで、その機能は後続のプロセスで説明されます。

バリデータは継続的にSequencer Inbox契約を監視します。シーケンサーがこの契約にバッチを公開するたびに、オンチェーンイベントがトリガーされます。このイベントを検出すると、バリデータはバッチデータをダウンロードし、ローカルで実行してから、イーサリアムチェーン上のロールアッププロトコル契約にRBlockを公開します。

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

（シーケンサーは継続的にバッチをSequencerInboxに提出します）

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

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

add Sequencer L2Batch From Origin()，The sequencer will call this function every time to submit Batch data to the Sequencer Inox contract.

force Inclusion()、この関数は誰でも呼び出すことができ、検閲に耐える取引を実装するために使用されます。この関数がどのように機能するかについては、後で遅延インボックス契約について詳しく説明します。

上記の2つの機能は、アキュムレータパラメーターを更新するために「bridge.enqueueSequencerMessage()」を呼び出します。

ガス価格設定

明らかに、L2トランザクションは無料にはできません。なぜなら、これはDoS攻撃につながるからです。さらに、シーケンサーL2自体の運用コストがかかり、L1にデータを提出する際にオーバーヘッドが発生します。ユーザーがレイヤー2ネットワーク内でトランザクションを開始すると、ガス料金の構造は以下のとおりです:

Layer1リソースを占有して生成されるデータの公開コストは、主にシーケンサーによって提出されたバッチから発生します（各バッチには多くのユーザーの取引が含まれます）、そしてそのコストは最終的に取引イニシエーターたちで共有されます。データの公開によって生成される取引手数料の価格設定アルゴリズムは動的です。シーケンサーは、最近の利益と損失条件、バッチサイズ、および現在のEthereumガス価格に基づいて価格を調整します。

ユーザーがLayer2リソースを占有するために負担するコストは、秒あたり処理されるガスの最大制限を設定することによって決定され、システムの安定動作を確保します（現在のArbitrum Oneは700万です）。 L1とL2のガスガイダンス価格は、ArbOSによってトラッキングおよび調整され、ここでは式は詳細に説明されていません。

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

楽観的な詐欺証明

前のテキストを振り返ると、Layer2（L2）は基本的にはシーケンサーがシーケンサーインボックスに提出したトランザクション入力バッチの投影にすぎません。

トランザクション入力 -> 状態遷移関数（STF） -> 状態出力

入力はすでに決定されており、STFは不変ですので、出力結果も決まっています。詐欺証拠とArbitrum Rollupプロトコルシステムは、RBlock（または主張としても知られる）によって表される出力状態をLayer1に公開し、そのための楽観的な証拠を提供します。

L1には、シーケンサーによって公開された入力データと、バリデータによって公開された出力状態の両方が存在します。注意深く考えると、Layer2の状態をチェーン上に公開する必要があるのでしょうか？なぜなら、入力がすでに出力を完全に決定しており、入力データは一般に公開されているため、出力結果や状態を提出することは冗長だと思われます。しかしながら、この考えはL1とL2システム間で状態の決済が必要であるという事実を見落としています。特にL2からL1への引き出し操作には、状態の証明が必要とされるため、これは非常に重要です。

Rollupを構築する際の中心的なアイデアは、L2にほとんどの計算とストレージをオフロードして、L1の高いコストを回避することです。これは、L1がL2の状態を把握していないことを意味し、すべての取引の入力データを公開するL2シーケンサーを支援するだけであり、L2の状態を計算する責任はありません。

出金アクションは基本的に、L2から提供されたクロスチェーンメッセージに基づいて、L1契約から対応する資産をアンロックし、ユーザーのL1アカウントに送金するか、他のタスクを完了することを含みます。

この時点で、Layer1契約は尋ねます：Layer2でのあなたの状態は何ですか、そしてあなたが主張している資産を本当に所有していることをどのように証明しますか？この段階では、ユーザーは対応するMerkle Proofsなどを提供する必要があります。

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

いわゆる楽観的な証明では、契約はL1に提出された出力状態が正しいかどうかをチェックしませんが、楽観的にすべてが正確であると信じています。楽観的な証明システムは、常に少なくとも1人の正直な検証者がいると仮定しています。不正な状態が発生した場合、詐欺証明を通じて挑戦されます。

この設計の利点は、ガスを無駄にするのを避けるために、L1に発行されたすべてのRBlockを積極的に検証する必要がないことです。実際、OPRにおいては、すべての主張を検証することは非現実的であり、それは各Rblockが1つ以上のL2ブロックを含み、各トランザクションをL1上で再実行する必要があるためです。これは、L1上で直接L2トランザクションを実行することと変わらず、これによってLayer 2の拡張性の意味を失います。

ZKRはこの問題に直面していません。なぜなら、ZK Proofsは簡潔であり、実際には証明の背後にある多くの取引を実行する必要はなく、小さな証明の検証のみが必要だからです。そのため、ZKRは楽観的に動作しません。各状態の公開には、Verifier契約による数学的検証が伴います。

詐欺証明はゼロ知識証明ほど簡潔なレベルには達しないが、Arbitrumは「マルチラウンドサブディビジョン - シングルステップ証明」のインタラクティブプロセスを採用しており、最終的には証明する必要があるのは1つの仮想マシンオペコードのみであり、比較的低コストで済む。

Rollupプロトコル

まず、挑戦を開始し証明を開始するための入り口を見てみましょう、つまり、Rollupプロトコルがどのように機能するかを見てみましょう。

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

さらに、ChallengeManager.sol コントラクトはチャレンジを管理し、OneStepProver シリーズのコントラクトは詐欺証明を決定するために使用されます。

(出典: L2BEAT公式ウェブサイト)

RollupProxyでは、異なるバリデータによって提出された一連のRBlocks（またはアサーションとも呼ばれる）が記録され、図のブロックで表されます：確認済みの場合は緑、未確認の場合は青、反証済みの場合は黄色です。

RBlockには、前のRBlock以降の1つ以上のL2ブロックの実行によって生じた最終状態が含まれています。これらのRBlocksは、外観上はRollup Chainを形成します（L2台帳そのものとは異なることに注意してください）。楽観的なシナリオでは、このRollup Chainにはフォークがないはずであり、フォークは検証者が矛盾するRollupブロックを提出することを意味します。

主張を提案または同意するために、検証者は一定額のETHを賭ける必要があり、ステーカーとなります。これにより、検証者間で誠実な行動の経済的基盤が確保され、挑戦/詐欺証拠の場合、敗者の賭け金が没収されることが保証されます。

図の右下隅にある青いブロックの番号111は、最終的には親ブロックであるブロック番号104が誤っている（黄色）ため、否定されることになります。

さらに、Validator A は Rollup ブロック 106 を提案しましたが、Validator B はこれに異議を唱え、挑戦しています。

Bが挑戦を開始した後、ChallengeManager契約は挑戦ステップの分割を検証する責任があります。

セグメンテーションは、両当事者が交互にやり取りをするプロセスです。片方の当事者が、あるロールアップブロックに含まれる過去のデータをセグメント化し、もう片方の当事者がデータ断片のどの部分に問題があるかを指摘します。連続的かつ徐々に範囲を狭めていく（実際にはN/K）二分法に似たプロセスです。
その後、問題のある取引とその結果をさらに特定し、その後、その取引内の特定の機械命令にさらに細分化することができます。
ChallengeManager契約は、元のデータを細分化した後に生成された「データセグメント」が有効かどうかだけを検証します。
挑戦者と挑戦を受けた当事者が挑戦されるべき機械命令を特定すると、挑戦者はoneStepProveExecution()を呼び出して、実行結果が間違っていることを示す単一ステップの不正証明を送信します。

ワンステッププルーフ

シングルステップ証明は、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をシミュレートするために、Ethereumスマート契約を使用する必要があるためであり、WASMは契約上のシミュレーションを実装するのが簡単であるためです。

ただし、WASMはネイティブの機械語よりもわずかに遅く実行されるため、アービトラムのノード/コントラクトは、詐欺証明を生成および検証する際にのみWAVMを使用します。

前回のインタラクティブサブディビジョンのラウンドを経て、単一ステップの証明がついにWAVM命令セット内の単一ステップ命令を証明しました。

以下のコードでわかるように、OneStepProofEntryはまず、証明される命令の操作コードがどのカテゴリに属するかを判定し、その後、Mem、Mathなどの対応する証明者を呼び出して、一歩の命令を証明者契約に渡します。

afterHashを通過した最終結果はChallengeManagerに返されます。もしハッシュがRollupブロックに記録された命令操作後のハッシュと一致しない場合、チャレンジは成功です。一致する場合、Rollupブロックに記録されたこのコマンドの実行結果に問題がないことを意味し、チャレンジは失敗します。

免責事項：

この記事は[から転載されましたギークWeb3], すべての著作権は元の著者に帰属します[Luo Benben、元Arbitrum技術アンバサダー、ギークweb3貢献者]. If there are objections to this reprint, please contact the Gate Learnチームが迅速に対応します。
責任の免責事項：この記事で表現されている意見や見解はすべて著者個人のものであり、投資アドバイスを構成するものではありません。
他の言語への記事の翻訳は、Gate Learnチームによって行われます。特に記載されていない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。