元ArbitrumテクニカルアンバサダーがArbitrumのコンポーネント構成を解説（後編）

Arbitrum はクロスチェーンメッセージングと検閲耐性のあるトランザクションをどのように処理しますか?クロスチェーンブリッジのモデルは何ですか?

執筆者: Luo Benben、元 Arbitrum テクニカル アンバサダー、オタク Web3 寄稿者

前回の記事*「元 Arbitrum テクニカル アンバサダーが Arbitrum のコンポーネント構造を解釈する (パート 1)」** では、Arbitrum のコア コンポーネントであるシーケンサー、バリデーター、シーケンサー インボックス コントラクト、ロールアップ ブロック、および非対話型不正行為証明について紹介しました。今日の記事では、Arbitrum のコアコンポーネントのうち、クロスチェーンメッセージングと検閲耐性のあるトランザクション入口に関連するコンポーネントに焦点を当てます。 *

前回の記事では、Sequencer Inbox コントラクトが、Layer1 上のシーケンサーによって発行されたトランザクション データ パッケージ バッチを具体的に受信すると述べました。同時に、シーケンサー受信ボックスは、低速ボックスの遅延受信ボックス (受信ボックスと呼ばれます) とは対照的に、高速ボックスとも呼ばれることを指摘します。以下では、Delayed Inbox などのクロスチェーン メッセージングに関連するコンポーネントについて詳しく説明します。

クロスチェーンとブリッジングの原則

クロスチェーントランザクションは、L1 から L2 (リチャージ) と L2 から L1 (出金) に分けることができます。ここで言及されているリチャージと引き出しは、必ずしもクロスチェーン資産に関連しているわけではなく、資産を直接含まないメッセージングである可能性があることに注意してください。したがって、これら 2 つの単語は、クロスチェーン関連の動作の 2 つの方向のみを表しています。

純粋な L2 トランザクションと比較して、クロスチェーン トランザクションは L1 と L2 の 2 つの異なるシステムで情報を交換するため、プロセスがより複雑になります。

さらに、通常、クロスチェーン動作と呼ばれるものは、監視モードのクロスチェーン ブリッジを使用して、2 つの無関係なネットワーク上でクロスチェーンを行うことです。このクロスチェーンのセキュリティは、クロスチェーン ブリッジに依存します。オペレーター、クロスチェーンの盗難目撃者モデルに基づいた鎖橋は歴史上頻繁に発生しました。

公式ロールアップを使用している限り、レイヤー 2 の状態はレイヤー 1 に記録されたデータによって決定されるため、ロールアップと ETH メイン ネットワーク間のクロスチェーンの動作は本質的に上記のクロスチェーンとは異なります**。クロスチェーンブリッジは、その運用構造において絶対に安全です。 **

これは、Rollup の本質を強調するものでもあり、ユーザーの視点からは独立したチェーンにしか見えませんが、実際には、いわゆる「**Layer2」は、Rollup によってユーザーに開かれる単なるクイック表示ウィンドウです。その実際のチェーン タイプの構造はまだ Layer1 に書き込まれています。 **したがって、L2 はチェーンの半分、つまり「Layer1 上に作成されたチェーン」と考えることができます。

再試行可能なチケット再試行可能

クロスチェーンは非同期かつ非アトミックであるため、一方のチェーンのようにトランザクションを確認した後に結果を知ることは不可能であり、ある時点でもう一方のチェーンで何かが起こることを保証することもできません。 。したがって、クロスチェーンはソフト的な問題によって失敗する可能性がありますが、再試行可能なチケットなどの正しい手段が使用されている限り、資金詰まりなどのハード的な問題は発生しません。

**再試行可能なチケットは、Arbitrum 公式ブリッジを通じて入金するときに使用される基本ツールです ** ETH と ERC20 の両方の入金が使用されます。そのライフサイクルは 3 つのステップに分かれています。

**1. L1 でチケットを送信します。 **遅延受信トレイ コントラクトの createRetryableTicket() メソッドを使用して、リチャージ チケットを作成し、送信します。

**2. L2 での自動引き換え。 **ほとんどの場合、仕分け機はユーザーが後で手動操作を行わなくても自動的に請求書の支払いを支援します。

**3. L2 での手動支払い。 **L2 でのガソリン価格の突然の高騰や、チケットの前払いガスが不足しているなど、一部のエッジ ケースでは、自動支払いを行うことができません。このとき、ユーザーによる手動操作が必要となります。

自動償還が失敗した場合は、ノートを 7 日以内に手動で償還する必要があることに注意してください。そうしないと、ノートが削除されるか (資金が永久に失われます)、リースを更新するためにノートを保存するために料金を支払う必要があります。

さらに、Arbitrum 公式ブリッジの出金プロセスは、リチャージ動作と対称的な類似性を持っていますが、リトライ可能の概念はなく、一方ではロールアップ プロトコル自体から理解でき、他方では、いくつかの違いからそれを理解できます。

• **引き出しプロセス中に自動償還はありません。**EVM にはタイマーや自動化がなく、自動償還はシーケンサーの助けを借りて実装される L2 で実現できるため、L1 のユーザーは手動で行う必要があります。 Outbox 契約と対話して、Retrieve アセットを要求します。
• **現金出金時にチケットの有効期限は問題ありません **チャレンジ期間が過ぎていればいつでも受け取ることができます。

ERC-20 アセットクロスチェーンゲートウェイ

クロスチェーン ERC-20 アセットは複雑です。いくつかの質問について考えることができます:

• L1 に展開されたトークンを L2 に展開するにはどうすればよいですか?
• L2 に対応するコントラクトを事前に手動でデプロイする必要がありますか、それともクロスオーバーしたがまだコントラクトをデプロイしていないトークンのアセット コントラクトをシステムが自動的にデプロイできますか?
• L1 上の ERC-20 アセットの場合、L2 上の対応するコントラクト アドレスは何ですか? L1と一致する必要がありますか?
• L2 でネイティブに発行されたトークンを L1 にクロスチェーンするにはどうすればよいですか?
• 数量を調整できるリベーストークンや自己成長型の有利子トークンなど、特別な機能を持つトークンをクロスチェーンするにはどうすればよいですか?

あまりに複雑すぎて解明できないため、これらの質問すべてに答えるつもりはありません。これらの質問は、ERC20 クロスチェーンの複雑さを説明するためにのみ使用されます。

現在、多くの拡張ソリューションは、さまざまな複雑な問題や境界条件を回避するために、ホワイトリスト + 手動リスト ソリューションを使用しています。

**Arbitrum はゲートウェイ システムを使用して、ERC20 クロスチェーンの問題点のほとんどを解決します。 **次の機能があります。

• ゲートウェイ コンポーネントは L1 と L2 にペアで表示されます。
• ゲートウェイ ルーターは、トークン L1<->トークン L2、 間のアドレス マッピングと、あるトークン<->あるゲートウェイ間のマッピングを維持する責任を負います。
• ゲートウェイ自体は、ERC20 ブリッジングの問題のさまざまな種類と機能を解決するために、StandardERC20 ゲートウェイ、汎用カスタム ゲートウェイ、カスタム ゲートウェイなどに分割できます。

ゲートウェイのカスタマイズの必要性を説明するために、比較的単純な WETH クロスチェーンを例に挙げてみましょう。

WETH は ERC20 に相当する ETH です。主要通貨であるイーサは多くの dApp で複雑な機能を実装できないため、ERC20 相当の通貨が必要です。一部の ETH を WETH コントラクトに転送すると、それらはコントラクト内にロックされ、同量の WETH が生成されます。

同様に、WETHを破壊してETHを取り出すことも可能です。明らかに、循環するWETHとロックされたETHの数は常に1:1です。 **

WETH を L2 に直接クロスリンクすると、いくつかの奇妙な問題が見つかるでしょう。

• L2 にはロックに対応する ETH がないため、L2 で WETH を ETH にアンラップすることはできません。
• Wrap 機能は使用できますが、これらの新しく生成された WETH が L1 にクロスバックされる場合、L1 と L2 の WETH コントラクトが「対称」ではないため、L1 上の ETH にカプセル化解除できません**。

明らかに、これは WETH の設計原則に違反しています。 **その後、WETH がクロスチェーンの場合、再チャージする場合でも出金する場合でも、最初に ETH にラップ解除し、次に反対側にクロスしてから、WETH にラップする必要があります。 **これはWETHゲートウェイの役割です。

より複雑なロジックを備えた他のトークンにも同様のことが当てはまります。クロスチェーン環境で適切に動作するには、より複雑で慎重に設計されたゲートウェイが必要です。 Arbitrum のカスタム ゲートウェイは、通常のゲートウェイのクロスチェーン通信ロジックを継承しており、開発者がトークン ロジックに関連するクロスチェーン動作をカスタマイズできるため、ほとんどのニーズを満たすことができます。

遅延受信箱

SequencerInbox としても知られる Fast Box に対応するのは、Slow Box Inbox (正式名 Delayed Inbox)** です。なぜ速度と遅さを区別する必要があるのでしょうか?高速ボックスはシーケンサーによって発行された L2 トランザクション バッチの受信専用であるため、L2 ネットワーク内のシーケンサーによって前処理されていないすべてのトランザクションは高速ボックス コントラクトに表示されるべきではありません。

**スローボックスの最初の機能は、L1 から L2 への再充電動作を処理することです。 **ユーザーはスロー ボックスを通じてリチャージし、シーケンサーはそれを監視して L2 に反映します。最終的に、リチャージ記録はシーケンサーによって L2 トランザクション シーケンスに組み込まれ、ファスト ボックス契約のシーケンサー インボックスに送信されます。

この例では、エクスプレス ボックスのシーケンサー受信ボックスに送信されたトランザクションはレイヤー 2 の通常のトランザクションの並べ替えを妨げ、シーケンサーの動作に影響を与えるため、ユーザーがリチャージ トランザクションをエクスプレス ボックスに直接送信することは適切ではありません。

スローボックスの 2 番目の機能は、検閲に抵抗することです。ユーザーはトランザクションをスロー ボックス コントラクトに直接送信し、ソーターは通常 10 分以内にトランザクションをファスト ボックスに集約します。ただし、ソーターが悪意を持ってリクエストを無視した場合、スロー ボックスには 強制包含 機能もあります。

トランザクションが遅延受信ボックスに送信され、24 時間経過してもスロー ボックス内のトランザクションがシーケンサーによってトランザクション シーケンスに含まれていない場合、** ユーザーはレイヤー 1 で強制包含機能を手動でトリガーできます。**シーケンサーによって無視される トランザクションリクエストはシーケンサー受信箱に強制的に収集され、その後すべての Arbitrum One ノードによって監視され、強制的にレイヤー 2 トランザクションシーケンスに組み込まれます。 **

先ほど述べたように、高速ボックス内のデータは L2 の履歴データ エンティティです。したがって、悪意のある検閲の場合、強制引き出しやレイヤー 2 のエスケープなどのシナリオをカバーするスロー ボックスを通じて、最終的に取引指示を L2 台帳に含めることができます。 **

このことから、どの方向およびレベルのトランザクションでも、シーケンサーは最終的に永続的にユーザーをレビューすることができないことがわかります。

スローボックス受信トレイのいくつかのコア機能:

*depositETH()、ETHを入金するための最も単純な関数。

• createRetryableTicket()、ETH、ERC20、メッセージのリチャージに使用できます。デポジットETH()と比べて、入金後のL2決済アドレスを指定できるなど、柔軟性が高くなります。 ※強制収集関数であるforceInclusion()は誰でも呼び出すことができます。この機能は、スローボックス契約に送信されたトランザクションが 24 時間経過しても処理されていないかどうかを検証します。条件を満たした場合、メッセージは強制的に収集されます。

ただし、force Inclusion 関数は実際には Fast Box コントラクト内にあるため、理解を容易にするために、Slow Box 内でまとめて説明します。

送信ボックス 送信ボックス

送信トレイは出金にのみ関連しており、出金の記録および管理システムとして理解できます:

• Arbitrum 公式ブリッジからの出金は、出金が実行される前に、チャレンジ期間の終了とロールアップ ブロックの完了まで約 7 日間待つ必要があることを承知しています。チャレンジ期間が終了すると、ユーザーは対応するマークル プルーフをレイヤー 1 のアウトボックス コントラクトに送信し、その後、他の機能 (他のコントラクトにロックされているアセットのロック解除など) のコントラクトと通信し、最終的に出金を完了します。
• OutBox コントラクトは、誰かが実行された出金リクエストを繰り返し送信することを防ぐために、L2 から L1 へのどのクロスチェーン メッセージが処理されたかを記録します。それは通ります
• マッピング(uint256 => bytes32) パブリック支出、マッピングの場合、出金リクエストの支出インデックスと情報の間の対応を記録します。 [spentIndex] != bytes32(0) の場合、リクエストは取り消されました。この原理は、リプレイ攻撃を防ぐためのトランザクション カウンター Nonce と似ています。

以下ではETHを例として入出金プロセスを詳しく説明します。 ERC20 と Gateway の唯一の違いは、詳細は説明しないことです。

ETH デポジット

1. ユーザーはスローボックスのdepositETH()関数を呼び出します。

2. この関数は引き続き Bridge.enqueueDelayedMessage() を呼び出し、ブリッジ コントラクトにメッセージを記録し、ブリッジ コントラクトに ETH を送信します。 **すべてのETHリチャージ資金は、リチャージアドレスに相当するブリッジコントラクトに保管されます。 **

3. シーケンサはスローボックス内のリチャージメッセージを監視し、リチャージ操作を L2 データベースに反映し、ユーザーは L2 ネットワーク上でリチャージした資産を確認できます。

4. シーケンサーは、リチャージ レコードをトランザクション バッチに組み込み、それを L1 の高速ボックス コントラクトに送信します。

ETHの出金

1. ユーザーは、L2 上の ArbSys コントラクトのdrawEth() 関数を呼び出して、L2 上の対応する量の ETH を破棄します。

2. シーケンサは引き出し要求をエクスプレス ボックスに送信します。

3 **検証ノードは、ファスト ボックス内のトランザクション シーケンスに基づいて新しいロールアップ ブロックを作成します。これには上記の出金トランザクションが含まれます。 **

4. ロールアップ ブロックがチャレンジ期間を過ぎて確認された後、ユーザーは L1 で Outbox.ute Transaction() 関数を呼び出して、パラメーターが上記の ArbSys コントラクトによって指定されていることを証明できます。

5. Outbox 契約が正しいことが確認された後、ロック解除されたブリッジ内の対応する金額の ETH がユーザーに送信されます。

クイック引き出し

**Optimistic Rollup 公式ブリッジを使用して現金を引き出す場合、チャレンジ期間を待つ必要があるという問題が発生します。この問題を回避するには、プライベート サードパーティのクロスチェーン ブリッジを使用できます。 **

• アトミックロック交換。この方法は、それぞれのチェーン内の 2 者間でアセットを交換するだけであり、アトミックであり、一方が Preimage を提供している限り、両方の当事者は確実にそれぞれにふさわしいアセットを取得します。しかし問題は、流動性が比較的不足しており、ポイントツーポイントで取引相手を見つける必要があることです。
• **クロスチェーンブリッジを目撃してください。 **一般的なタイプのクロスチェーンブリッジはウィットネスブリッジです。ユーザーは独自の出金リクエストを送信し、出金先はサードパーティのブリッジまたは流動性プールのオペレーターを指します。証人は、クロスチェーントランザクションが L1 の高速ボックス契約に送信されたことを発見した後、L1 側のユーザーに直接送金することができます。このアプローチは基本的に、別のコンセンサス システムを使用してレイヤー 2 を監視し、レイヤー 1 に送信されたデータに基づいて動作します。 **問題は、このモードの安全率が公式のロールアップ ブリッジほど高くないことです。 **

強制退会

Force Inclusion() Force Inclusion 関数は、シーケンサのレビューに抵抗するために使用され、L2 ローカル トランザクション、L1 から L2 へのトランザクション、および L2 から L1 へのトランザクションを実装できます。シーケンサーの悪意のあるレビューは、トランザクション エクスペリエンスに深刻な影響を与えます。ほとんどの場合、お金を引き出して L2 から離れることを選択します。そのため、以下では強制引き出しを例として、forceInclusion の使用方法を紹介します。

**ETH の出金ステップでは、シーケンサーのレビューが含まれるのはステップ 1 と 2 のみであるため、変更する必要があるのはこれら 2 つのステップのみであることを思い出してください。

※L1のスローボックスコントラクトでinbox.sendL2Message()を呼び出します 入力パラメータは、L2でdrawEth()を呼び出す際に入力が必要なパラメータです。このメッセージは、L1 上のブリッジ コントラクトに共有されます。 ※ 24 時間の強制インクルード待機期間を待った後、Fast Box で Force Inclusion() を呼び出して強制インクルードを実行し、Fast Box コントラクトはブリッジ内に該当するメッセージがあるかどうかを確認します。

エンドユーザーは送信トレイでお金を引き出すことができ、残りの手順は通常の出金と同じです。

さらに、arbitrum-tutorials には、Arb SDK の使用に関する詳細なチュートリアルもあり、forceInclusion() を介して L2 ローカル トランザクションおよび L2 から L1 へのトランザクションを実行する方法をユーザーにガイドします。