前回の記事「元アービトラムテクニカルアンバサダーが解釈するアービトラムのコンポーネント構造(第1回)」では、アービトラムの主要コンポーネントの役割として、シーケンサー、バリデーター、シーケンサー受信箱コントラクト、ロールアップブロック、非対話型不正証明の役割について紹介しました。 今日の記事では、クロスチェーンメッセージパッシングに関連するコンポーネントと、Arbitrumのコアコンポーネントにおける検閲防止トランザクションのエントリの説明に焦点を当てます。

本文: 以前の記事で、シーケンサー受信トレイ コントラクトは、レイヤー 1 のシーケンサーによって発行されたトランザクション データ バッチを受信するように特別に設計されていることを説明しました。 同時に、シーケンサーの受信トレイは「ファストボックス」とも呼ばれ、対照的に「スローボックス」または「遅延受信ボックス」(インボックスと呼ばれる)があることも指摘しました。 以下では、Delayed Inboxを含むクロスチェーンメッセージパッシングに関連するコンポーネントの詳細な解釈を提供します。

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

クロスチェーン取引は、L1からL2(入金)までの取引とL2からL1(出金)までの取引に分けることができます。 ここでの「入金」と「出金」という用語は、必ずしも資産のクロスチェーン転送を含むとは限らないことに注意することが重要です。これらは、アセットを直接転送せずにメッセージパッシングを参照できます。 したがって、これらの用語は、クロスチェーン関連のアクションの2つの方向を表しているにすぎません。

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

さらに、クロスチェーンアクションについて話すとき、それは通常、フェデレーテッドモデルのクロスチェーンブリッジを使用して、まったく関係のない2つのネットワーク間を横断することを指します。 このようなクロスチェーン操作のセキュリティは、クロスチェーンブリッジのオペレーターに依存しており、歴史的に、目撃者ベースのクロスチェーンブリッジでは盗難事件が頻繁に発生しています。

一方、RollupとETHメインネット間のクロスチェーンアクションは、前述のクロスチェーンプロセスとは根本的に異なります。 これは、Layer2 の状態が Layer1 に記録されたデータによって決定されるためです。 公式のRollupクロスチェーンブリッジを使用する限り、その操作は構造的に安全です。

これは、ユーザーの視点から見ると独立したチェーンのように見える Rollup の本質を浮き彫りにしていますが、実際には、いわゆる "Layer2" は Rollup によってユーザーに開かれる高速表示ウィンドウにすぎず、その真のチェーンのような構造は Layer1 に記録されています。 したがって、L2はハーフチェーン、つまり「Layer1上に作成されたチェーン」と見なすことができます。

再試行可能項目

クロスチェーントランザクションは非同期であり、非アトミックであることに注意してください。 単一チェーン上のトランザクションとは異なり、クロスチェーントランザクションでは、1つのチェーン上の1つのトランザクションの後にトランザクションを完了し、結果を確認することはできません。 また、ある時点で相手側で何か特定のことが起こるという保証もありません。 したがって、クロスチェーントランザクションは、いくつかのソフトな問題が原因で失敗する可能性がありますが、再試行可能なチケットなどの適切な手法を使用することで、資金がスタックするなどのハード問題は発生しません。

再試行可能なチケットは、入金時にArbitrumオフィシャルブリッジで使用される基本的なツールであり、ETHとERC20の両方の入金に適用されます。 ライフサイクルは、次の 3 つのステップで構成されます。

1. L1 でのチケットの送信: 遅延受信トレイ コントラクトの「createRetryableTicket()」メソッドを使用して、入金チケットを作成して送信します。
2. L2での自動引き換え:ほとんどの場合、シーケンサーは追加の手動操作を必要とせずに、ユーザーに代わってチケットを自動的に引き換えることができます。
3. L2での手動引き換え:L2でのガス料金の急騰など、特定の極端なケースでは、航空券のプリペイドガスが不足している場合、自動引き換えは行われません。 このシナリオでは、ユーザーによる手動の介入が必要です。 自動引き換えに失敗した場合、ユーザーは7日以内に手動でチケットを引き換える必要があることに注意してください。そうしないと、チケットが削除されるか(資金が永久に失われる)、ユーザーはチケットのストレージを更新するために一定の料金を支払う必要があります。

さらに、アービトラムオフィシャルブリッジでの出金プロセスについては、入金と比較してプロセスに一定の対称性がありますが、再試行可能なチケットの概念はありません。 これは、Rollup プロトコル自体の観点から理解でき、いくつかの違いを強調することができます。

• EVMにはタイマーや自動化がないため、出金プロセス中の自動償還はありません。 L2 では、自動償還を実装でき、シーケンサーによって容易になります。 したがって、L1 のユーザーは、送信トレイ コントラクトを手動で操作して、アセットを請求する必要があります。
• 出金時にチケットの有効期限の問題はありません。 チャレンジ期間が過ぎている限り、ユーザーはいつでも資産を請求できます。

ERC-20資産のクロスチェーンゲートウェイ

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

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

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

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

Arbitrumは、ERC20クロスチェーンのスティッキング問題のほとんどを解決するためにゲートウェイシステムを使用しています。 次の機能があります。

• ゲートウェイ コンポーネントは、L1 と L2 にペアで表示されます。
• ゲートウェイ ルーターは、トークン L1<->Token L2 間のアドレス マッピングを維持する役割を担います。 <->また、あるトークン<>ゲートウェイ間のマッピング。
• ゲートウェイ自体は、標準ERC20ゲートウェイ、ジェネリックカスタムゲートウェイ、カスタムゲートウェイなどに分けて、ERC20ブリッジングのさまざまなタイプと機能を解決できます。

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

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

同様に、WETHを燃やしたり、ETHを引き出したりすることもできます。 明らかに、流通するWETHとロックされたETHの比率は常に1:1です。

WETHをL2に直接クロスチェーンすると、いくつかの奇妙な問題が見つかります。

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

明らかに、これはWETHの設計原則に違反しています。 したがって、WETHをクロスチェーンする場合、入金であれ出金であれ、まずETHにアンラップし、次に反対側にクロスしてからWETHにラップする必要があります。 これがWETHゲートウェイの役割です。

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

受信トレイの遅延

シーケンサー受信トレイと呼ばれる高速受信トレイに対応するのが、低速受信トレイ (正式名称は遅延受信トレイ) です。 なぜ高速と低速を区別するのですか? これは、高速受信トレイはシーケンサーによって発行された L2 トランザクションのバッチの受信専用であり、L2 ネットワーク内のシーケンサーによって前処理されていないトランザクションは高速受信トレイ コントラクトに表示されないためです。

スローインボックスの最初の機能は、L1からL2への入金プロセスを処理することです。ユーザーは低速受信トレイから入金を開始し、シーケンサーがこれを観察すると、L2に反映されます。 最終的に、この入金記録はシーケンサーによって L2 トランザクション シーケンスに含まれ、高速受信ボックス コントラクト (シーケンサー受信ボックス) に送信されます。

このシナリオでは、高速受信トレイに送信されたトランザクションがレイヤー 2 の通常のトランザクション順序を乱し、シーケンサーの動作に影響を与える可能性があるため、ユーザーが高速受信トレイ (シーケンサー受信トレイ) に入金トランザクションを直接送信することは不適切です。

遅い受信トレイの2番目の機能は、検閲に強いことです。低速受信ボックス コントラクトに直接送信されたトランザクションは、通常、シーケンサーによって 10 分以内に高速受信トレイに集約されます。 ただし、シーケンサーが悪意を持って要求を無視した場合、低速受信トレイには強制インクルード機能があります。

トランザクションが遅延受信トレイに送信され、24 時間後にシーケンサーによってトランザクション シーケンスに組み込まれていない場合、ユーザーは Layer1 で強制包含機能を手動でトリガーできます。 このアクションにより、シーケンサーによって無視されたトランザクションは、高速受信トレイ (シーケンサー受信ボックス) に強制的に集約されます。 その後、それらはすべてのArbitrum Oneノードによって検出され、Layer2トランザクションシーケンスに強制的に含まれます。

先ほど、高速受信トレイのデータは L2 の履歴データ エンティティを表していると説明しました。 したがって、悪意のある検閲の場合、遅い受信トレイを使用すると、トランザクションの指示が最終的にL2台帳に含まれ、レイヤー2を逃れるための強制引き出しなどのシナリオをカバーできます。

このことから、トランザクションの方向やレベルにかかわらず、シーケンサーは最終的に永久に検閲することはできないことがわかります。

低速受信トレイ(受信トレイ)のいくつかの主要機能:

• depositETH(): ETHを入金するための最もシンプルな関数。
• createRetryableTicket():ETH、ERC20、およびメッセージの入金に使用されます。 depositETH()に比べて柔軟性が高く、入金後のL2での受取アドレスなどの指定が可能です。
• forceInclusion(): この関数 (強制インクルージョン機能) は、誰でも呼び出すことができます。 この関数は、低速受信トレイコントラクトに送信されたトランザクションが 24 時間後に処理されていないかどうかを確認します。 条件が満たされると、メッセージが強制的に含められます。

ただし、強制包含機能は、実際には高速受信トレイ コントラクトにあることに注意することが重要です。 分かりやすくするために、受信トレイが遅いことと併せて説明しました。

トレイ

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

• アービトラム公式ブリッジでの出金は、チャレンジ期間が終了するまで約7日間待つ必要があり、出金はロールアップブロックが確定した後にのみ実施できることがわかっています。 チャレンジ期間が終了すると、ユーザーは対応するマークルプルーフをLayer1のOutboxコントラクトに送信し、Layer1は他の機能(他のコントラクトにロックされた資産のロック解除など)のコントラクトと通信し、最終的に出金を完了します。
• OutBoxコントラクトは、L2からL1までのどのクロスチェーンメッセージが処理されたかを記録し、誰かが実行された引き出しリクエストを繰り返し送信するのを防ぎます。 支出インデックスと出金依頼の情報との対応関係を「mapping(uint256 => bytes32) public spent」で記録します。 mapping[spentIndex] != bytes32(0) の場合、要求は取り消されています。 この原理は、リプレイ攻撃を防止するためのトランザクションカウンタ Nonce と似ています。

以下では、ETHを例にとり、入出金プロセスを完全に説明します。 ERC20とETHの唯一の違いは、前者がゲートウェイを使用していることです。 詳しくは説明しません。

ETH入金

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

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

3. シーケンサーは、スローボックス内の入金メッセージを監視し、入金操作をL2データベースに反映します。 ユーザーは、L2ネットワークに預けた資産を見ることができます。

4. シーケンサーは、デポジット レコードをトランザクション バッチに含め、L1 の高速ボックス契約に送信します。

ETHの出金

1. ユーザは L2 で ArbSys コントラクトの withdrawEth() 関数を呼び出し、対応する数の ET が L2 でバーンされます。

2. シーケンサーは、出金リクエストをエクスプレスボックスに送信します。

3. バリデーターノードは、上記の引き出しトランザクションを含むファストボックス内のトランザクションシーケンスに基づいて、新しいロールアップブロックを作成します。

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

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

迅速な現金引き出し

オプティミスティックロールアップ公式ブリッジを使用して現金を引き出す場合、チャレンジ期間を待つという問題が発生します。 プライベートなサードパーティのクロスチェーンブリッジを使用して、この問題を取り除くことができます。

• アトミックロック交換。 この方法は、それぞれのチェーン内の2つの当事者間でのみ資産を交換し、アトミックです。 一方の当事者が Preimage を提供する限り、両者は間違いなく相応しい資産を手に入れることができます。 しかし、問題は流動性が比較的乏しく、ピアツーピア方式で取引相手を見つける必要があることです。F
• 目撃者が鎖橋を渡る。 一般的なタイプのクロスチェーンブリッジは、ウィットネスブリッジです。 ユーザーは自分で出金リクエストを送信し、出金先はサードパーティのブリッジまたは流動性プールのオペレーターを指します。 証人は、クロスチェーントランザクションがL1ファストボックスコントラクトに送信されたことを発見した後、L1側のユーザーに直接送金することができます。 このアプローチは、基本的に別のコンセンサスシステムを使用してレイヤ2を監視し、レイヤ1に送信したデータに基づいて動作します。 \

強制退会

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

ETHの出金手順を振り返ってみると、ステップ1と2のみシーケンサーの検閲を伴うため、変更する必要があるのはこの2つのステップのみです。

• L1 のスロー ボックス コントラクトで 'inbox.sendL2Message()' を呼び出す場合、入力パラメータは L2 で withdrawEth() を呼び出すときに入力する必要があるパラメータです。 このメッセージは、L1 のブリッジ コントラクトに共有されます。
• 24 時間の強制インクルード待機期間の後、高速ボックスの force Inclusion() が呼び出され、強制インクルードが実行されます。 ファストボックスコントラクトは、ブリッジに対応するメッセージがあるかどうかをチェックします。

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

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

免責事項：

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