前Arbitrum技術アンバサダーが解説するArbitrumのコンポーネント構造（下）
TechFlow厳選深潮セレクト
前Arbitrum技術アンバサダーが解説するArbitrumのコンポーネント構造（下）
Arbitrumはどのようにクロスチェーンメッセージの伝達および検閲耐性取引を処理するのか？
Web3業界の深掘り報道に専念し潮流を洞察執筆：ロ・ベンベン、元Arbitrum テクニカルアンバサダー、Web3 ギーク貢献者
前回の記事『元Arbitrum技術大使が解説するArbitrumのコンポーネント構造（上）』では、Arbitrumのコアコンポーネントであるシーケンサー、バリデータ、Sequencer Inboxコントラクト、Rollup Block、非インタラクティブな詐欺証明の役割について紹介しました。今回の記事では、Arbitrumのコアコンポーネントの中で、クロスチェーンメッセージ伝送および検閲耐性のあるトランザクションエントリポイントに関連するコンポーネントについて重点的に解説します。
以前の記事で述べたように、Sequencer Inboxコントラクトはレイヤー1上でシーケンサーが発行したトランザクションデータパケットBatchを専用に受け取ります。また、Sequencer Inboxは「ファストボックス」とも呼ばれ、これに対して「スローボックス」であるDelayed Inbox（略称Inbox）があります。以下では、Delayed Inboxなど、クロスチェーンメッセージ伝送に関連するコンポーネントについて詳しく解説します。
クロスチェーンとブリッジの原理
クロスチェーントランザクションはL1からL2への入金（チャージ）とL2からL1への出金（引き出し）に分けられます。ここで言うチャージや引き出しは必ずしも資産のクロスチェーンに関係しない場合もあり、直接資産を伴わないメッセージの伝送でもあります。したがって、これらの用語は単にクロスチェーン関連行為の二つの方向を表しています。
純粋なL2トランザクションと比較して、クロスチェーントランザクションはL1とL2という異なる二つのシステム間で情報を交換するため、プロセスがより複雑です。
また、一般的に言われるクロスチェーン行為は、互いに無関係なネットワーク間で、ワーナーモデルのクロスチェーンブリッジを使用して行われます。このようなクロスチェーンの安全性は、ブリッジ運営者の信頼性に依存しており、過去にワーナーモデルのクロスチェーンブリッジがハッキングされた事件が頻発しています。
しかし、RollupとETHメインネット間のクロスチェーン行為は上記とは本質的に異なります。なぜなら、Layer2の状態はLayer1上に記録されたデータによって決定されるため、公式Rollupブリッジを使用すれば、その運用構造上は絶対的に安全です。
これはRollupの本質を浮き彫りにしています。ユーザー視点では独立したチェーンのように見えますが、実際には「Layer2」というのはユーザー向けに開かれた高速ウィンドウであり、真のチェーン構造は依然としてLayer1上に刻まれています。つまり、L2は半分のチェーン、あるいは「Layer1上に創造されたチェーン」と言えるでしょう。
リトライ可能チケット（Retryables）
注意すべき点として、クロスチェーンはすべて非同期かつ非アトミックです。一つのチェーン上でトランザクションを完了して結果が即座にわかるようなものではなく、相手側で特定の事象が確実に発生する保証もありません。そのため、いくつかのソフト的な問題によりクロスチェーンが失敗することもありますが、正しい手段、例えばリトライ可能チケット（Retryable Ticket）を使用すれば、資金がロックされるなどのハードな問題は発生しません。
リトライ可能チケットは、Arbitrum公式ブリッジを通じてチャージを行う際に使用される基本的なツールです。ETHおよびERC20のチャージに使用され、そのライフサイクルは以下の三段階に分けられます：
1. L1でチケットを提出する。 Delayed Inboxコントラクト内のcreateRetryableTicket()メソッドを使用してチャージチケットを作成し、提出します。
2. L2で自動償還される。 多くの場合、シーケンサーがユーザーに代わって自動的にチケットを償還してくれるので、後続の手動操作は不要です。
3. L2で手動償還を行う。 一部のエッジケース、例えばL2でのガス価格が急騰して事前に支払ったガス料金が不足すると、自動償還ができなくなります。この場合、ユーザーが手動で操作する必要があります。
なお、自動償還が失敗した場合は7日以内に手動で償還しなければなりません。さもなくば、チケットは削除され（資金は永久に失われる）、またはチケットの保存を継続するために一定の費用を支払い更新する必要があります。
また、Arbitrum公式ブリッジの引き出しプロセスは、チャージプロセスとある種の対称性を持っていますが、「Retryables」という概念はありません。これはRollupプロトコル自体から理解できるほか、いくつかの違いからも理解できます：
-
引き出しプロセスには自動償還が存在しない。 EVMにはタイマーや自動化機能がないため、L2で自動償還が可能なのはシーケンサーが支援しているからです。一方、L1ではユーザーがOutboxコントラクトと手動でやり取りしてClaimすることで資産を取り戻す必要があります。
-
引き出しにはチケットの有効期限切れの問題もない。 挑戦期間を過ぎれば、いつでも資産を受け取ることができます。
ERC-20 資産クロスチェーン Gateway
ERC-20資産のクロスチェーンは非常に複雑です。以下の問いを考えてみましょう：
-
L1に展開されたトークンを、L2上にどのように展開すればよいでしょうか？
-
L2上の対応するコントラクトは事前に手動で展開する必要があるのか、それともまだコントラクトが展開されていないトークンに対して、システムが自動で資産コントラクトを展開してくれるのでしょうか？
-
L1のERC-20資産に対応するL2上のコントラクトアドレスは何か？L1と同じアドレスにするべきでしょうか？
-
L2上でネイティブに発行されたトークンは、どのようにL1へクロスチェーンすればよいでしょうか？
-
数量調整可能なRebase型トークン、自己増殖型利子付きトークンなど特別な機能を持つトークンは、どのようにクロスチェーンすればよいでしょうか？
これらすべての問いに答えるつもりはありません。それはあまりにも複雑すぎるからです。これらの問いはあくまでERC20のクロスチェーンの複雑さを示すために挙げました。
現在、多くのスケーリングソリューションでは、複雑な問題やエッジケースを回避するためにホワイトリスト＋手動登録方式を採用しています。
ArbitrumはGatewayシステムを採用することで、大部分のERC20クロスチェーンの課題を解決しています。以下の特徴があります：
-
GatewayコンポーネントはL1とL2にペアで存在します。
-
Gateway RouterはToken L1<->Token L2間のアドレスマッピング、およびsome token<->some gateway間のマッピングを管理します。
-
Gateway自体はStandardERC20 gateway、Generic-custom gateway、Custom gatewayなどに分けられ、異なるタイプおよび機能を持つERC20のブリッジング問題を解決します。
ここでは比較的単純なWETHのクロスチェーンを例に、カスタムgatewayの必要性を説明します。
WETHはETHのERC20等価物です。Etherは基軸通貨であり、多くのdAppにおいて複雑な機能を実現できないため、ERC20の等価物が必要になります。WETHコントラクトにETHを入金すると、それらはコントラクト内にロックされ、同量のWETHが生成されます。
同様に、WETHを破棄することでETHを取り出すこともできます。明らかに、流通しているWETHとロックされているETHの数量は常に1:1です。
もし今、WETHをそのままL2へクロスチェーンすると、奇妙な問題が発生します：
-
L2上でWETHをUnwrapしてETHに変換することはできません。なぜならL2上には対応するETHがロックされていないからです。
-
Wrap機能は使用可能ですが、新しく生成されたWETHをL1に戻したとしても、L1上でETHに解封することはできません。なぜならL1とL2のWETHコントラクトは「対称的ではない」からです。
これは明らかにWETHの設計理念に反しています。したがって、WETHのクロスチェーンでは、チャージでも引き出しでも、まずUnwrapしてETHに変換し、その後相手側に移動してから再びWrapしてWETHにする必要があります。これがWETH Gatewayの役割です。
より複雑なロジックを持つ他のトークンも同様に、より複雑かつ精巧に設計されたGatewayが必要です。ArbitrumのカスタムGatewayは通常のGatewayのクロスチェーン通信ロジックを継承しつつ、開発者がトークンロジックに関連するクロスチェーン動作をカスタマイズできるため、ほとんどのニーズを満たします。
遅延インボックス（Delayed Inbox）
ファストボックスであるSequencerInboxに対して、スローボックスInbox（正式名称：Delayed Inbox）があります。なぜこのような速度の区別があるのでしょうか？ファストボックスは、シーケンサーが発行したL2トランザクションBatchを専用に受信するため、シーケンサーによる事前処理を経ていないすべてのトランザクションは、ファストボックスコントラクトに出現してはいけません。
スローボックスの第一の目的は、L1からL2へのチャージ行為を処理することです。ユーザーはスローボックスを通じてチャージを行い、シーケンサーがそれを監視してL2に反映させます。最終的にこのチャージ記録はシーケンサーによってL2トランザクションシーケンスに組み込まれ、ファストボックスコントラクトSequencer Inboxに提出されます。
この例では、ユーザーが直接ファストボックスにチャージトランザクションを提出するのは適切ではありません。なぜなら、Sequencer Inboxに提出されたトランザクションは、Layer2の通常のトランザクション順序付けを妨害し、シーケンサーの作業に影響を与えるからです。
スローボックスの第二の目的は、検閲耐性です。ユーザーが直接スローボックスコントラクトに提出したトランザクションは、通常シーケンサーが10分以内にファストボックスに集約します。しかし、シーケンサーが悪意を持ってユーザーの要求を無視した場合、スローボックスには強制集約（force inclusion）機能があります：
トランザクションがDelayed Inboxに提出されてから24時間が経過しても、まだシーケンサーによってトランザクションシーケンスに含まれていない場合、ユーザーはLayer1上で手動でforce inclusion関数をトリガーし、シーケンサーに無視されたトランザクション要求を強制的にファストボックスSequencer Inboxに集約することができます。その後、すべてのArbitrum Oneノードがこれを監視し、強制的にLayer2トランザクションシーケンスに含められます。
前述したように、ファストボックスのデータこそがL2の履歴データそのものです。したがって、悪意のある検閲があった場合でも、スローボックスを通じてトランザクション命令を最終的にL2台帳に含めることができ、これには強制的な引き出しといったLayer2からの脱出シナリオも含まれます。
このことから、いかなる方向やレベルのトランザクションであっても、シーケンサーは最終的に永久に検閲できないことがわかります。
スローボックスInboxの主なコア関数：
-
depositETH()：ETHをチャージする最もシンプルな関数。
-
createRetryableTicket()：ETH、ERC20、およびメッセージのチャージに使用可能です。depositETH()よりも柔軟性が高く、例えばチャージ後のL2の受取アドレスを指定できることなどが挙げられます。
-
forceInclusion()：強制集約機能。誰でも呼び出せます。この関数は、スローボックスコントラクトに提出された特定のトランザクションが24時間以上処理されていないかどうかを検証します。条件を満たせば、メッセージを強制的に集約します。
ただし、force Inclusion関数は実際にはファストボックスコントラクトに存在しますが、理解しやすくするためにここではスローボックスと一緒に説明しています。
アウトボックス（Outbox）
アウトボックス（Outbox）は引き出しに関係するものであり、引き出し行為の記録および管理システムと捉えることができます：
-
Arbitrum公式ブリッジの引き出しには約7日のチャレンジ期間が必要であり、Rollup Blockが最終的に確定した後に引き出し行為を実施できます。ユーザーはチャレンジ期間終了後に、Layer1のOutboxコントラクトに該当するMerkle Proofを提出し、他の機能を持つコントラクトと通信（例えば、ロックされた資産を解除）して最終的に引き出しを完了します。
-
OutBoxコントラクトは、L2からL1へのクロスチェーンメッセージがすでに処理されたかどうかを記録し、誰かが既に実行された引き出し要求を繰り返し提出するのを防ぎます。これは
-
mapping(uint256 => bytes32) public spent を使って、引き出し要求のspent Indexと情報の対応関係を記録します。mapping[spentIndex] != bytes32(0) であれば、その要求はすでに引き出されています。これはリプレイ攻撃防止のためのトランザクションカウンターNonceと同様の原理です。
次に、ETHを例に、チャージと引き出しのプロセスを完全に解説します。ERC20はGatewayを通る点が異なるだけで、それ以外は同じなので、ここでは繰り返しません。
ETHチャージ
1. ユーザーがスローボックスのdepositETH()関数を呼び出します。
2. この関数はbridge.enqueueDelayedMessage()を呼び出し、bridgeコントラクト内にメッセージを記録し、ETHをbridgeコントラクトに送金します。すべてのETHチャージ資金はbridgeコントラクトに保管されており、一種のチャージアドレスのようなものです。
3. シーケンサーがスローボックス内のチャージメッセージを監視し、L2データベースにチャージ操作を反映させます。ユーザーはL2ネットワーク上で自分のチャージした資産を確認できます。
4. シーケンサーはこのチャージ記録をトランザクションバッチbatchに含め、L1のファストボックスコントラクトに提出します。
ETH引き出し
1. ユーザーがL2上でArbSysコントラクトのwithdrawEth()関数を呼び出し、L2上で対応する量のETHを破棄します。
2. シーケンサーがこの引き出し要求をファストボックスに送信します。
3. バリデータノードはファストボックス内のトランザクションシーケンスに基づいて新しいRollup Blockを作成し、上記の引き出しトランザクションを含めます。
4. Rollup Blockがチャレンジ期間を経て確定した後、ユーザーはL1上でOutbox.executeTransaction()関数を呼び出し、前述のArbSysコントラクトから提供されたパラメータを証明します。
5. Outboxコントラクトが問題ないことを確認した後、bridge内の対応する量のETHを解放してユーザーに送信します。
高速引き出し
オプティミスティックRollup公式ブリッジを使う引き出しではチャレンジ期間の待機が必要です。この問題を回避するために、民間の第三者クロスチェーンブリッジを利用できます：
-
原子的ロック交換。この方法は双方がそれぞれのチェーン内で資産を交換するもので、アトミック性があり、一方がPreimageを提供すれば双方とも必要な資産を得られます。ただし、流動性が希薄で、相手方をポイントツーポイントで探す必要があります。
-
ワーナーブリッジ。一般的なタイプのクロスチェーンブリッジはすべてワーナーブリッジに属します。ユーザーは自分の引き出し要求を提出し、引き出し先を第三者ブリッジの運営者または流動性プールに指定します。ワーナーがL1のファストボックスコントラクトにクロスチェーントランザクションが提出されたことを確認すると、すぐにL1側でユーザーに送金できます。この方法の本質は、別のコンセンサスシステムを使ってLayer2を監視し、Layer1に提出されたデータに基づいて操作を行うことです。問題は、このモデルのセキュリティレベルがRollup公式ブリッジほど高くないことにある。
強制引き出し
force Inclusion()の強制集約機能は、シーケンサーの検閲に対抗するために使用され、L2ローカルトランザクション、L1からL2へのトランザクション、L2からL1へのトランザクションのすべてに適用できます。シーケンサーの悪意ある検閲はトランザクション体験に深刻な影響を与えるため、多くの場合L2から引き出して離れる選択をします。以下では、強制引き出しを例にforceInclusionの使い方を紹介します。
ETH引き出しのステップを振り返ると、ステップ1と2のみがシーケンサーの検閲に関係しています。したがって、この二つのステップだけを変更すればよいです：
-
L1のスローボックスコントラクト内のinbox.sendL2Message()を呼び出し、L2上でwithdrawEth()を呼び出す際に必要なパラメータを入力します。このメッセージはL1のbridgeコントラクトと共有されます。
-
24時間の強制集約待機期間を経過後、ファストボックスのforce Inclusion()を呼び出して強制集約を行います。ファストボックスコントラクトはbridge内に該当するメッセージがあるかを確認します。
最終的にユーザーはOutboxで引き出しを完了でき、残りのステップは通常の引き出しと同じです。
また、arbitrum-tutorialsではArb SDKを使用した詳細なチュートリアルがあり、ユーザーがforceInclusion()を使ってL2ローカルトランザクションやL2からL1へのトランザクションを行う方法を指導しています。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@godrealmx
