最初のレベルのタイトル

アーキテクチャの概要

• Arbitrum はイーサリアム L1 の L2 スケーラビリティ ソリューションであるため、Arbitrum のアーキテクチャの一部は L1 上にあり、一部は L2 上にあります。

• L1 上の Arbitrum のコンポーネントは EthBridge であり、これは一連の Ethereum コントラクトで構成されます。

• EthBridge は、Arbitrum Rollup プロトコルを調停し、Ethereum チェーン上の Arbitrum ロールアップの受信ボックスと送信ボックスを維持する責任を負います。

• ユーザー、L1 コントラクト、およびフル ノードは、イーサリアム チェーン上の受信ボックスと送信ボックスを介して自分のトランザクションを Arbitrum チェーンに送信し、それらのトランザクションの結果を観察できます。

• Arbitrum Virtual Machine (AVM) は、L1 と L2 間のゲートウェイである EthBridge が提供する機能です。

• AVM は入力を読み取り、それらの入力に基づいて計算を実行して出力を生成できます。

• ArbOS は AVM 上で実行され、スマート コントラクトが Arbitrum チェーン上で確実に実行されます。

• 画像の説明

最初のレベルのタイトル

仲裁ロールアップ契約

• 受信箱内のメッセージの順序によって、トランザクションの結果が決まります。

• したがって、自分でトランザクションを実行する限り、受信箱をチェックする人は誰でもトランザクションの結果を知ることができます。

• Arbitrum Rollup プロトコルは、発生したトランザクションの結果を確認する責任があります。

• プロトコルに参加するユーザーはバリデーターと呼ばれ、バリデーターがステーキングコントラクトに ETH を預けるとステーカーとなり、Arbitrum チェーンにブロックをステーキングできます。

• バリデーターもステーカーも許可を必要としません。

• セキュリティの観点からは、Arbitrum チェーンが正しく実行されることを保証するために必要な誠実なバリデータは 1 つだけです。

• これにより、Arbitrum チェーンは Ethereum チェーンと同様にトラストレスになります。

• Arbitrum は、少なくとも 1 人のバリデーターが誠実であることを前提としています。

• Arbitrum Rollup プロトコルは、Arbitrum Rollup チェーンで動作します。後者は、イーサリアム チェーンから独立したロールアップ ブロックのチェーンです。

• バリデーターの役割は、新しいブロックを提案し、それらを Arbitrum チェーンに追加することです。

• 提案されたすべてのブロックは、最終的にプロトコルによって確認または拒否されます。

• 各ブロックには複数のフィールドが含まれます。ブロック番号フィールドを除く各フィールドのデータはブロック提案者の主張ですが、必ずしも正しいとは限りません。

• アサーション フィールドのいずれかが正しくない場合、プロトコルは最終的にブロックを拒否します。

• 提案されたすべてのブロックには確認期間があります。

• 誓約

誓約

• ロールアップ ブロックをチェーンに追加するには、ステーカーはブロックにステークする必要があります。

• ステーキングは許可が必要なく、誰でも任意のブロックをステーキングできます。

• 一度ブロックにベットすると、ブロックが確認されるまでデポジットを取り戻すことはできません。

• ブロックに賭けると、そのブロックが正しいと信じたことになり、最後に確認されたブロックから賭けたブロックまでのチェーン上のすべてのブロックが正しいと信じたことになります。

• 賭けたブロックが間違っている場合、または最後に確認されたブロックから賭けたブロックまでのチェーン上のブロックが間違っている場合、デポジットは没収されます。

• 特定のブロックに賭けたくない場合は、最後に確認されたブロックに賭けることができます。

• ブロックに賭けた場合は、そのブロックに続く任意のブロックに賭けを拡張できます。

• 必要な担保額は変動します。

• Arbitrum チェーンには指定された基本誓約額パラメーターがあり、ほとんどの場合に使用されます。

• 攻撃者がステーキングを犠牲にしてネットワークの速度を低下させるのを防ぐために、ステーキングには、タイムアウトとともに指数関数的に増加する係数が乗算されます (タイムアウトは、最初の保留中のブロックの期限からカウントされます)。

• これは、攻撃中のこの種の攻撃のコストを増加させるためです。

• 副題

チャレンジプロトコル

• 2 人のステーカーが継承関係を持たずに異なるブロックにステークする場合、ブロック上で分岐する場合に問題が発生します。

• 異議申し立ては主に Arbitrum チェーン上で行われ、L1 コントラクトによって裁定されます。

• このチャレンジは、L2 でのインタラクティブなマルチラウンド スプリット ゲームと、L1 で実行されるワンステップ証明で構成されます。

• ステーカーがブロックに異議を唱えた場合、ブロックを提案したステーカーは「被告」として自分の主張を弁護します。

• 「被告」質権者は、前のブロックから始めて、仮想マシンが N 個の命令を実行した後、前のブロックの状態が提案されたブロックの状態に進むと主張しています。

• スプリット ゲームでは、「被告」であるステーカー (アリス) が最初の手を取り、N 個の命令を K 個のセグメントに分割します。各セグメントのサイズは N/K です。

• 各ステージの Arbgas 消費量は等しいですが、ステップ数は必ずしも等しいわけではないことに注意してください。

• また、各段落には開始と終了があることに注意してください (これは重要ではありませんが、次の点を理解するのに役立ちます)。

• 「原告」としての質権者（ボブ）も、N 個の命令を K 個のセグメント（各セグメントのサイズは N/K）に分割し、それらをアリスのセグメントに 1 つずつ対応させ、そのうちの 1 つのセグメントが終点であることを発見します。アリスとは違います。

• ボブは実際、同意できない部分を見つけています。

• 次に、ボブはアリスの元の操作を実行し、係争中のセグメント (サイズ N/K) を K 個のサブセグメントに分割し、セグメントとサブセグメントをアリスに送信します。

• アリスはボブの元の操作を実行し、異なるエンドポイントを持つサブセグメントを見つけます。

• 分割プロセスは、アリスとボブが分岐した 1 つの命令を見つけるまで続きます。

• この命令は L1 コントラクトに送信され、L1 コントラクトがそれを実行し、紛争の「勝者」を決定します。

• 「敗者」は誓約を失い、その一部は破棄され（攻撃者の賭けのヘッジを防ぐ）、残りは正直な「勝者」に報酬が与えられます。

• 分割プロセス全体を通じて、裁定者としての L1 コントラクトは指示に関する情報を一切知らず、両当事者がゲームのルールに従っているかどうかを確認することのみを担当します。

• 紛争中、他のすべてのバリデーターは、紛争が終了する前に紛争の結果を決定できます。これは、ソフトフォークが発生し、バリデーターが正しいチェーンでロールアップブロックを送信し続けることができることを意味します。

• チャレンジ期間には強制的な期間があり、ステーカーあたり約 1 週間です。

• 各ステーカーは 1 週間の期限内にタスクを完了する必要があり、さもなければ「敗訴」となります。

• チェスのタイマーのようなもの。

副題

検証者

• バリデーターは、ロールアップ プロトコルのアクティビティを監視し、チェーン全体の状態を進める役割を担う Arbitrum チェーン上のノードです。

• すべてのノードがバリデーターであるわけではありません。

• Offchain Labs は、バリデーターが積極的、防御的、または待機的な戦略を採用することを期待していますが、プロトコルはバリデーターがどの戦略を採用するかを強制するものではありません。

• 「アクティブなバリデーター」は、新しいブロックを提案することでチェーンの状態を前進させ続けます。各チェーンで必要な正直なアクティブ バリデーターは 1 つだけです。アクティブなバリデーターの数を増やしても、チェーン全体の効率は向上しません。

• 「防御型バリデーター」は Arbitrum プロトコルを監視し、不正を発見した場合にのみ行動を起こします。つまり、自ら正しいブロックを提案するか、他のバリデーターが提案した正しいブロックに賭けます。

• 「待機バリデーター」も防御的バリデーターと同様にアービトラムプロトコルを監視しますが、たとえ不正を発見したとしても、正しいブロックを提案したり賭けたりすることはなく、他のバリデーターに警告を発するだけです。

• オフチェーン ラボは、主力の Arbitrum チェーン上でアクティブなバリデーター ノードを実行します。

• ほとんどの場合、防御側バリデーターと待機バリデーターは何もする必要がないため、攻撃者は防御側バリデーターが何人あるかを知りません。

• 最初のレベルのタイトル

フルノード

• Arbitrum チェーンのフル ノードはイーサリアムのフル ノードと同じように機能し、チェーンの状態を追跡し、他のノードがチェーンと対話できるようにする役割を果たします。

• すべてのノードには AVM シミュレーターが組み込まれています。したがって、完全なノードの観点から見ると、Arbitrum チェーンは実際のロールアップ プロトコルを知ることなく、入力に基づいて出力を計算するだけです。

• フルノードはオンチェーンアグリゲーターとして機能し、ユーザーのコスト効率の向上に役立ちます。

• Arbitrum には、アグリゲーターとして機能するコストをフルノードに補償するためにユーザーから料金を徴収する機能もあります。

• フルノードでは、トランザクションを圧縮することで、L1 通話データのコストをさらに削減することもできます。

• フルノードは圧縮されたトランザクションを受信ボックスに送信し、arbOS はトランザクションを受信した後に解凍します。

• 最初のレベルのタイトル

シーケンサーモード

• Arbitrum チェーンが開始されると、シーケンサーを有効にするかどうかを選択できます。

• シーケンサーは、受信ボックス内のトランザクションの順序を決定する権限を持つ完全なノードです。

• この権限により、シーケンサーはトランザクションの結果を即座に保証できます。

• シーケンサーが Arbitrum チェーンに対して有効になっている場合、受信ボックスは 2 つの部分に分割されます。

• 最初の受信ボックスは、シーケンサーが存在しないかのように機能します。つまり、ノードはブロック番号とタイムスタンプのタグが付いたメッセージをこの受信ボックスに送信できます。

• 2 番目の受信ボックスはシーケンサーによって制御され、シーケンサーのみがこの受信ボックスにメッセージを送信できます。

• メッセージを受信箱に送信するとき、シーケンサーはメッセージにスタンプするブロック番号とタイムスタンプを指定できます。

• これには、(過去のブロックの) ブロック番号、指定されたデルタ ブロックまでのタイムスタンプとデルタ秒 (過去の時間) が含まれます。

• これらの差分は通常、現実世界では約 10 分に相当します。

• arbOS が受信トレイをチェックすると、最も小さいブロック番号を持つメッセージを受信します。このブロック番号は、通常の受信ボックスのブロック番号またはシーケンサーの受信ボックスのブロック番号のいずれかです。

• シーケンサーがバックトラックできるブロックの数は、イーサリアム上のアービトラム ブロックを完了するために必要な確認済みブロックの数によって異なります。

• アービトラムがイーサリアム上でファイナリティに達するまで X ブロックを待つ必要がある場合、シーケンサーは X ブロックを遡って、現在のパッケージ化されたトランザクションの直後にどのトランザクションが処理されるかを決定する必要があります。

• Arbitrum チェーンでシーケンサー モードが有効になっている場合、シーケンサーに送信されたトランザクションは、シーケンサーを使用しない場合よりも x ブロック早く終了しますが、通常の受信ボックスに送信されたトランザクションは、シーケンサーを使用しない場合よりも早く終了します。x ブロックの背後の状況が終了します。

• 即時 OK と 5 分 OK と 5 分 OK と 10 分 OK の間には大きな違いがあるため、これはプラスのトレードオフです。

• ただし、悪意のあるシーケンサーはこれらの権限をある程度悪用することができます。

• 悪意のあるシーケンサーは、ユーザーのトランザクションをシーケンサーの受信箱に入れずに検閲し、検閲されたことを知ったユーザーに同じトランザクションを通常の受信箱に送信するよう強制する可能性があります。

• シーケンサーはユーザー トランザクションをプリエンプトすることもできます。

• 最初の Arbitrum チェーンでは、Offchain Labs によって実行されるシーケンサーが有効になります。

• 画像の説明

最初のレベルのタイトル

ArbGas / 料金

• ArbGas の原理は、Arbitrum チェーンの計算コストを測定するために使用される Ethereum ガスに似ています。

• ただし、Arbitrum チェーンには ArbGas の厳しい上限はなく、ArbGas はイーサリアム ガスよりもはるかに早く消費されます。

• ArbGas の重要な役割は、計算結果の検証にかかる時間を予測することです。

• 各 Rollup ブロックには、ArbGas 消費量の合計に関するステートメントが含まれています。つまり、現在のブロックのステートメントと前のブロックのステートメントの差が、現在のブロックでの ArbGas 消費量の有効な指標となるはずです。

• したがって、ブロックの正当性をチェックする際、検証者はこの差をガスの上限として設定することができ、ブロックが実行される前に非常に多くの ArbGas が使い果たされた場合、ブロックは無効であると判断し、ブロックへのチャレンジに成功することができます。

• これらのトランザクションのデータは最終的にチェーンにアップロードする必要があるため、ユーザーは料金を支払う必要があります。

• そのユーザーがアグリゲーターにトランザクションを送信すると、料金の一部が報酬としてアグリゲーターに自動的に支払われます。

• 残りの料金はネットワークの料金プールに入り、チェーン全体の安全な運用を保証するサービス料金を支払います。

• 料金には、L2 トランザクション、L1 通話データ、計算およびストレージのコストが含まれます。

• 結論は

結論は

• Arbitrum は、Offchain Labs によって開発された L2 スケーラビリティ ソリューションです。マルチラウンド インタラクティブ チャレンジ プロトコルを備えたオプティミスティック ロールアップです。

• 主力の Arbitrum チェーンは 5 月 28 日に開発者に公開されました。このチェーン上で実行されているプロジェクトがしきい値に達すると、ユーザーに公開されます。

• ユーザーの観点から見ると、Arbitrum チェーンのインタラクティブなエクスペリエンスはイーサリアムのインタラクティブなエクスペリエンスと何ら変わりません。

元のリンク:

Arbitrum について詳しく知りたい場合は、このドキュメントを参照してください。

元のリンク:

https://tracer.finance/radar/arbitrum-in-under-10/

翻訳・校正：Min Min & A Jian

翻訳・校正：Min Min & A Jian