本文: 以前の記事で、シーケンサー受信トレイ コントラクトは、レイヤー 1 でシーケンサーによって公開されたトランザクション データのバッチを受信するように特別に設計されていると述べました。 同時に、シーケンサーの受信トレイは「ファストボックス」とも呼ばれ、対応するのがディレイド受信トレイ(受信トレイと呼ばれる)であることも指摘しました。 次に、Delayed Inboxなど、クロスチェーンメッセージ送信に関連するコンポーネントについて詳しく説明します。

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

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

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

さらに、通常クロスチェーン動作と呼ばれるのは、witnessモードのクロスチェーンブリッジを使用した2つの無関係なネットワークでのクロスチェーンです。 このクロスチェーンのセキュリティは、クロスチェーンブリッジに依存します。 歴史的に、目撃者モードに基づくクロスチェーンブリッジでは、盗難事件が頻繁に発生してきました。

対照的に、RollupとEthereumメインネット間のクロスチェーン動作は、前述のクロスチェーン操作とは根本的に異なります。 これは、レイヤ 2 の状態がレイヤ 1 に記録されたデータによって決定されるためです。 公式のRollupクロスチェーンブリッジを使用する限り、その運用構造は絶対に安全です。

これはまた、ユーザーの視点から見ると、独立したチェーンとして表示される Rollup の本質を強調しています。 ただし、実際には、いわゆる「レイヤー 2」は、ロールアップによってユーザーに開かれる高速表示ウィンドウにすぎず、その真のチェーンのような構造はレイヤー 1 に記録されます。 したがって、L2はハーフチェーン、または「レイヤー1で作成されたチェーン」と見なすことができます。

再試行可能項目

クロスチェーン操作は非同期であり、非アトミックであることに注意することが重要です。 トランザクションの結果が確認されるとわかるシングルチェーンとは異なり、クロスチェーントランザクションでは、特定の時間に反対側で特定のイベントが発生することを保証することはできません。 したがって、クロスチェーントランザクションはソフトな問題が原因で失敗する可能性がありますが、再試行可能なチケットなどの正しい方法を使用すると、資金がスタックするなどの問題は発生しません。

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

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

2. L2での自動引き換え:ほとんどの場合、シーケンサーは、手動での介入なしに、ユーザーのチケットを自動的に引き換えることができます。

3. L2での手動引き換え:チケットのプリペイドガスが不足しているL2でのガス料金の急激な上昇など、特定のエッジケースでは、自動引き換えが失敗することがあります。 このような場合は、ユーザーによる手動の介入が必要です。 自動引き換えに失敗した場合、チケットは7日以内に手動で引き換える必要があります。そうしないと、チケットが削除されるか(資金が永久に失われる)、リースを更新するための料金の支払いが必要になる可能性があります。

さらに、Arbitrumオフィシャルブリッジの出金プロセスでは、プロセスに関してはデポジット動作と対称的な類似性がありますが、再試行可能という概念はありません。 これは、Rollup プロトコル自体の観点からも、いくつかの違いを調べることでも理解できます。

• EVMにはタイマーや自動化がないため、引き出し時の自動償還はありません。 自動償還はシーケンサーの助けを借りてL2に実装できますが、L1のユーザーは資産を請求するために送信トレイコントラクトを手動で操作する必要があります。

• また、出金時のチケットの有効期限の問題もありません。チャレンジ期間が過ぎている限り、資産はいつでも請求できます。

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

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

• トークンが L1 にデプロイされている場合、トークンは L2 にどのようにデプロイされますか?
• L2 の対応するコントラクトは事前に手動でデプロイする必要がありますか、それとも転送されたがまだデプロイされていないトークンのアセット コントラクトをシステムが自動的にデプロイできますか?
• L1のアドレスに対応するL2のERC-20資産のコントラクトアドレスは何ですか?L1 のアドレスと一致させる必要がありますか。
• L2でネイティブに発行されたトークンは、L1にクロスチェーンされますか?
• 調整可能な供給リベーストークンや自動ステーキングトークンなどの特別な機能を持つトークンは、どのようにクロスチェーンするのでしょうか?

これらの質問は複雑すぎて包括的に対処することができないため、すべてに答えるつもりはありません。 これらの質問は、ERC-20クロスチェーントランザクションの複雑さを説明するためのものです。

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

Arbitrumは、ERC20クロスチェーントランザクションのほとんどの問題点に対処するためにゲートウェイシステムを採用しており、以下の特徴を備えています。

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

カスタムゲートウェイの必要性を説明するために、クロスチェーンWETH転送の比較的簡単な例を考えてみましょう。

WETHはETHのERC20版です。 イーサリアムが主要通貨として機能するため、dAppsの多くの複雑な機能を直接実現することは不可能です。 したがって、WETHのような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のクロスチェーン通信ロジックを継承しており、開発者はトークンロジックに関連するクロスチェーン動作をカスタマイズして、ほとんどの要件を満たすことができます。

受信トレイの遅延

SequencerInbox に対応するのは、ファスト ボックスとも呼ばれ、受信トレイ (正式名称は遅延受信トレイ) です。 高速ボックスと遅延ボックスを区別するのはなぜですか? ファスト ボックスは、シーケンサーによって発行された L2 トランザクションのバッチを受信するように特別に設計されているため、L2 ネットワーク内のシーケンサーによって前処理されていないトランザクションは、ファスト ボックス コントラクトに表示されません。

スローボックスの最初の役割は、L1からL2への入金動作を処理することです。ユーザーはスローボックスから入金を開始し、シーケンサーはそれをL2に反映します。 最終的に、この入金記録はシーケンサーによって L2 トランザクション シーケンスに含まれ、ファスト ボックス コントラクトである SequencerInbox に送信されます。

このシナリオでは、SequencerInbox に送信されたトランザクションがレイヤー 2 の通常のトランザクション シーケンスに干渉し、シーケンサーの動作に影響を与えるため、ユーザーがデポジット トランザクションをファスト ボックスに直接送信することは不適切です。

遅延ボックスの2つ目の役割は、検閲への抵抗です。 遅延ボックスコントラクトに直接送信されたトランザクションは、通常、シーケンサーによって 10 分以内にファストボックスに集約されます。 ただし、シーケンサーが悪意を持って要求を無視した場合、遅延ボックスには強制包含機能があります。

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

前述したように、ファストボックス内のデータは、L2の履歴データエンティティを表します。 したがって、悪意のある検閲の場合、遅延ボックスを使用してトランザクションを最終的にL2台帳に含めることができ、レイヤー2からの強制引き出しなどのシナリオをカバーできます。

このことから、シーケンサーは最終的に、どの方向またはレイヤーでもトランザクションを永続的に打ち切ることはできないことがわかります。

スローボックス受信トレイのコア機能は次のとおりです。

• depositETH(): この関数は、ETHを入金するための最も簡単な方法です。
• createRetryableTicket():この関数は、ETH、ERC20トークン、およびメッセージの入金に使用できます。 depositETH()と比較して、入金後にL2で受取アドレスを指定するなど、柔軟性に優れています。
• forceInclusion(): フォースインクルージョン関数とも呼ばれ、誰でも呼び出すことができます。 この関数は、スローボックス契約に送信されたトランザクションが 24 時間後に処理されていないかどうかを確認します。 条件が満たされると、関数はメッセージを強制的に集約します。

ただし、forceInclusion() 関数は実際には高速ボックスコントラクトに存在することに注意することが重要です。 わかりやすくするために、ここではスローボックス関数と並行して説明しました。

トレイ

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

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

以下では、ETHを例に入出金のプロセスについて解説します。 ERC20トークンのプロセスは、ゲートウェイが追加されたことで似ていますが、ここでは詳しく説明しません。

ETH入金

1. ユーザーは、遅延受信トレイの depositETH() 関数を呼び出します。
2. 次に、この関数は bridge.enqueueDelayedMessage() を呼び出します。 ブリッジコントラクトにメッセージを記録し、ETHをブリッジコントラクトに送信します。 入金されたETH資金はすべてブリッジコントラクトに保持され、入金アドレスとして機能します。
3. シーケンサーは、遅延受信トレイの入金メッセージを監視し、L2データベースに入金操作を反映します。 ユーザーは、L2ネットワーク上で預け入れた資産を見ることができます。
4. シーケンサーは、トランザクションのバッチに入金レコードを含め、L1 の Fast Inbox コントラクトに送信します。

ETHの出金

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

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

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

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

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

迅速な引き出し

楽観的なロールアップ公式ブリッジを使用するには、チャレンジ期間を待つ必要があります。 この問題を回避するには、プライベートなサードパーティのクロスチェーンブリッジを利用します。

• アトミックスワップ交換:このアプローチでは、資産はそれぞれのチェーン内の当事者間で交換され、アトミックであるため、一方の当事者がプリイメージを提供すれば、両方の当事者が対応する資産を取得できます。 しかし、流動性は比較的乏しく、カウンターパーティをピアツーピアで探す必要があります。
• ウィットネスベースのクロスチェーンブリッジ:ほとんどのタイプのクロスチェーンブリッジは、このカテゴリに分類されます。 ユーザーは、第三者ブリッジのオペレーターまたは流動性プールとして送金先を指定して、出金リクエストを送信します。 証人は、クロスチェーントランザクションがL1のFast Inboxコントラクトに送信されたことを発見すると、L1のユーザーに直接資金を送金できます。 基本的に、この方法では、別のコンセンサス システムを使用してレイヤー 2 を監視し、レイヤー 1 に送信されたデータに基づいて操作を実行します。 ただし、このモードのセキュリティ レベルは、ロールアップ公式ブリッジに比べて低くなります。

強制撤退

forceInclusion() 関数は、シーケンサーの検閲に対抗するために使用されます。 これは、任意の L2 ローカル トランザクション、L1 から L2 へのトランザクション、および L2 から L1 へのトランザクションに適用できます。 シーケンサーの悪意のある検閲はトランザクション体験に大きく影響するため、L2からの撤退を選択することがよくあります。以下は、強制的な引き出しにforceInclusion()を使用する例です。

ETHの引き出しのコンテキストでは、ステップ1と2のみがシーケンサー検閲を伴います。 したがって、次の2つの手順を変更するだけで済みます。

• L1 の Delayed Inbox コントラクトで inbox.sendL2Message() を呼び出し、L2 で withdrawEth() を呼び出すときに必要なパラメータを指定します。 このメッセージは、L1 のブリッジ コントラクトと共有されます。
• 24 時間の強制インクルージョン待機期間を待機した後、Fast Inbox コントラクトで forceInclusion() を呼び出して、強制インクルージョンを行います。 Fast Inbox コントラクトは、ブリッジに対応するメッセージがあるかどうかを確認します。

最後に、ユーザーは送信トレイから出金することができ、残りの手順は通常の出金プロセスと同じです。

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

免責事項：

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