元アービットラム技術大使がアービットラムのコンポーネント構造を説明（下）

著者：ベン・ロウ、元Arbitrumテクニカルアンバサダー、Geek Web3コントリビューター

はじめに。Arbitrumの元技術大使であり、スマートコントラクト自動化監査会社Goplus Securityの元共同設立者であるベニー・ロウによるArbitrum Oneの技術解説。

前回の記事"元アービトルム技術大使がアービトルムのコンポーネント構造を解説（上）"では、アービトルムのコアコンポーネントであるシーケンサー、バリデーター、シーケンサー インボックスコントラクト、ロールアップブロック、非対話型不正証明、インタラクティブな不正証明についてご紹介しました。そして今日の記事では、クロスチェーンメッセージングと検閲に強いトランザクションポータルに関するアービトルムのコアコンポーネントに焦点を当てます。

本文：前回の記事で、アービットラムのコアコンポーネントであるクロスチェーンメッセージングと検閲に強いトランザクションポータルに焦点を当てました。同時に、Sequencer InboxはFast Inboxとも呼ばれ、Slow InboxやDelayed Inbox（略してInbox）とは対照的であることも指摘しました。以下では、Delayed Inboxとクロスチェーンメッセージングに関連するその他のコンポーネントについて詳しく見ていきます。

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

クロスチェーン取引は、L1からL2（トップアップ）とL2からL1（引き出し）に分類されます。ここでいうトップアップと引き出しは、必ずしも資産のクロス・チェーンとは関係なく、直接資産を伴わないメッセージングである可能性があることに注意してください。つまり、これら2つの用語は、単にクロスチェーンに関連する行動の2つの方向を表しているのです。

クロスチェーン取引は、L1とL2という2つの異なるシステム間でメッセージを交換するため、純粋なL2取引よりも複雑です。

さらに、クロスチェーン操作は通常、証人モデルに基づくクロスチェーンブリッジを使用して、2つの無関係なネットワーク上で実行されますが、そのセキュリティはブリッジのオペレータに依存しており、証人モデルに基づくクロスチェーンブリッジの盗難は歴史上頻繁に発生しています。

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

ユーザーから見ると別チェーンのように見えるが、実際にはいわゆる「Layer2」はRollupがユーザーに公開している「Layer2」に過ぎないというRollupの性質も浮き彫りになっている。しかし、実際には"Layer2 "はユーザーのための簡単なショーケースに過ぎず、本当のチェーン構造はまだLayer1に埋め込まれている。ですから、L2は半分のチェーン、つまり「Layer1の上に作られたチェーン」と考えることができます。

再利用可能

クロスチェーンは非同期かつ非アトミックであることに注意してください。一方のチェーンのように、トランザクションが実行され確認された後にその結果を知ることはできませんし、ある時点で相手側で何かが起こるという保証もありません。そのため、ソフト的な問題でクロスチェーンが失敗することはあり得ますが、再取得可能なチケットのような適切な手段があれば、資金が滞留するようなハード的な問題は起こりません。

再取得可能チケットは、公式のArbitrumブリッジ経由でトップアップする際に使用される基本的なツールで、ETHとERC20の両方のトップアップに使用されます。そのライフサイクルは3つのステップに分かれています: 

1.L1でチケットを提出する。遅延受信契約のcreateRetryableTicket()メソッドを使用してリチャージチケットを作成し、それを提出します。

2.L2で自動リチャージ。ほとんどの場合、シーケンサーは、その後の手動操作なしに、ユーザーのチケットを自動的に現金化することができます。

3. L2での手動キャッシング。 いくつかのエッジケース、たとえば、L2でのガソリン価格が急に高騰し、チケットに十分なプリペイドガソリンがない場合、自動的にキャッシュアウトすることはできません。この場合、ユーザーは手動で行う必要があります。

自動引き換えに失敗した場合、チケットは7日以内に手動で引き換える必要があります。そうしないと、チケットは削除されるか（資金が永久に失われる）、チケットの保存のためにリース更新料を支払う必要があります。

また、アービトラム公式ブリッジの引き出しプロセスでは、特定の対称的な類似性の過程で再充電の動作が、Retryablesはありませんが、この概念は、一方では、ロールアッププロトコル自体から理解することができ、他方では、我々はからすることができます。

• 現金を引き出すプロセスは、自動償還のプロセスには存在しません。strong>EVMにはタイマーや自動化がないためです。L2では自動キャッシュアウトが可能ですが、それを実現するのはシーケンサーなので、L1のユーザーはOutboxコントラクトと手動でやり取りして、資産を取り戻すよう請求しなければなりません。

• 引き出しは、チケットの期限切れの問題もありません。strong>そして挑戦期間が過ぎている限り、いつでも請求することができます。strong>ERC-20資産のクロスチェーンは複雑です。考えるべきいくつかの質問：

  • L1にデプロイされたトークンは、L2にどのようにデプロイされるのでしょうか？L2でどのようにデプロイされるのでしょうか？

  • L2に対応するトークンは、事前に手動でデプロイする必要があるのでしょうか、それとも、クロスオーバーしているがまだコントラクトをデプロイしていないトークンに対して、システムが自動的にアセットコントラクトをデプロイできるのでしょうか？

  • L1上のERC-20アセットのL2コントラクトアドレスは何ですか？L1と同じであるべきですか？

  • L2でネイティブに発行されたトークンをL1にクロスチェーンするにはどうすればよいですか？" style="text-align: left;">数量が調整可能なRebase型トークンや自己成長する利子付きトークンなど、特別な機能を持つトークンはどのようにクロスチェーンするのですか？

  拡大すると複雑になりすぎるため、これらの質問にすべて答えるつもりはありません。これらの質問は、ERC20クロスチェインの複雑さを説明するためのものです。

  

  現時点では、非常に多くの拡張シナリオでホワイトリストが使用されています。シナリオでは、様々な複雑さや境界ケースを回避するために、ホワイトリスト＋手動リストのスキームを使用しています。

  Arbitrumは、ERC20クロスチェーンのペインポイントのほとんどを解決するゲートウェイシステムを使用しています。paddingleft-2">

• ゲートウェイのコンポーネントは、L1とL2のペアで表示されます。

• ゲートウェイルーターは、トークンL1<->トークンL2,間のアドレスマッピングを維持する責任があります。strong>とあるトークン<->あるゲートウェイ間のマッピングを維持する役割を果たします。ゲートウェイ、ジェネリックカスタムゲートウェイ、カスタムゲートウェイなどに分類され、ERC20ブリッジングのさまざまなタイプや機能を解決するために使用されます。

比較的単純なWETHクロスチェーンの例を見てみましょう。WETHのクロスチェーンの例で、カスタムゲートウェイの必要性を説明しましょう。

WETHはETHのERC20相当です。Etherを主要コインとすると、dAppの複雑な機能の多くは不可能なので、ERC20相当が必要になります。ETHをWETHコントラクトに送金すると、コントラクトにロックされ、同量のWETHが生成されます。

同様に、WETHを破棄してETHを取り出すことも可能です。: 1.

ここでWETHを直接L2にクロスチェーンしてみると、奇妙な問題が見つかります:

• ロック位置に対応するETHがL2上に存在しないため、WETHをL2上のETHにアンラップすることはできません。

• Wrap関数を使用することができますが、L1とL2上のWETH契約は「対称」ではないため、これらの新しく生成されたWETHは、L1に戻った場合、L1上のETHにアンラップすることはできません。

これは明らかにWETHの設計原則に違反しています。それなら、WETHは反対側に渡る前にETHにUnwrapされ、チェーンを渡るときにWETHにWrapされる必要があります。これはWETHゲートウェイの役割でもあります。

同じように、より複雑なロジックを持つ他のトークンは、クロスチェーン環境で適切に動作するために、より複雑でよく設計されたゲートウェイを必要とします。アービトルムのカスタムゲートウェイは、通常のゲートウェイのクロスチェーン通信ロジックを継承しており、開発者は以下のことができます。アービトルムのカスタムゲートウェイは、通常のゲートウェイのクロスチェーン通信ロジックを継承し、開発者がトークン・ロジックに関連するクロスチェーンの動作をカスタマイズできるようになっており、ほとんどの要件を満たしています。

Delayed Inbox

これは SequencerInbox と同じです。SequencerInboxはSlow Inbox (full name Delayed Inbox)とは対照的です。なぜ高速と低速の違いがあるのですか？Fast InboxはシーケンサーからL2トランザクションバッチを受け取るように設計されており、L2ネットワーク内でシーケンサーによって前処理されていないトランザクションはFast Inboxコントラクトにあるべきではありません。

スローボックスの最初の使用は、L1からL2へのトップアップを処理することです。 スローボックスの最初の使用は、L1からL2へのトップアップを処理することです。 ユーザーはスローボックスを通じてトップアップを実行し、それをシーケンサーが聞いてL2に反映し、最終的にトップアップはシーケンサーによってL2のトランザクションシーケンスに含まれ、ファーストボックス契約であるシーケンサー・インボックスに提出されます。

この例では、ユーザーはトップアップを直接ファーストボックスに提出します。Quickbox Sequencer Inbox に提出されたトランザクションが Layer2 の通常のトランザクション・ソートを妨害し、シーケンサーの作業に影響を与えるため、ユーザーがトップアップ・トランザクションを直接 Quickbox に提出することは適切ではありません。

スローボックスの2つ目の用途は、検閲に抵抗することです。ユーザーがスローボックスのコントラクトに直接トランザクションを送信すると、シーケンサーは通常10分以内にそれをファストボックスに入れる。

遅延受信箱にトランザクションが送信され、24時間後、そのトランザクションがまだシーケンサーによってslowboxに含まれていない場合、slowboxはそのトランザクションを処理できない可能性があります。24時間後、Slow Inboxのトランザクションがまだシーケンサーによってトランザクションシーケンスに含まれていない場合、ユーザーは手動でLayer1の強制取り込み機能をトリガーすることができます。これにより、シーケンサーによって無視されたトランザクションリクエストを強制的にFast InboxのSequencer Inboxにグループ化することができます。レイヤー2トランザクションシーケンスに強制的に含まれます。

クイックボックスのデータはL2の履歴データ実体であることは先に述べた。そのため、悪意のある検閲が行われた場合、slowboxを使えば、取引注文がL2の元帳に含まれてしまう可能性があります。

このことからわかるように、シーケンサーは、どちらの方向とレイヤーの取引についても、永久に検閲を終了することはできません。

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

• depositETH()は、ETHをトップアップするための最もシンプルな関数です。

• createRetryableTicket()は、ETHとERC20とメッセージのリチャージに使用できます。depositETH()と比較して、例えばリチャージ後のL2収集アドレスを指定できるなど、より柔軟性があります。

• 強制包含関数であるforceInclusion()は、どの⼈からも呼び出すことができます。この関数は、スローボックス契約にサブミットされたトランザクションが24時間後に処理されていないかどうかをチェックします。この条件が十分であれば、メッセージは強制包含の対象となる。

ただし、強制インクルージョン関数は実際にははfastboxコントラクトにありますが、ここでは理解しやすいようにslowboxで説明します。

アウトボックス

アウトボックスは出金にのみ関係します。

• 私たちは、以下のことを知っています。アービトラム公式ブリッジからの引き出しは、約7日間続くチャレンジ期間の終了後、ロールアップブロックが確定した後にのみ行うことができます。チャレンジ期間が終了すると、ユーザーは対応するMerkle ProofをLayer1のOutboxコントラクトに提出し、Outboxコントラクトは他の機能コントラクトと通信して（例えば、他のコントラクトにロックされたアセットを解除するために）引き出しを確定します。

• OutBoxコントラクトは、どのL2からL1へのクロスチェーンメッセージが処理されたかを追跡します。OutBoxコントラクトは、L2からL1へのクロスチェーンメッセージがどのように処理されたかを追跡し、実行済みの引き出し要求を繰り返し送信するのを防ぐ。これは、

  mapping(uint256 => bytes32) public spentを介して、メッセージに対するキャッシュアウトリクエストの使用済みインデックスを記録します。mapping[spentIndex] ！= bytes32(0)であれば、リクエストはすでに使われた。

次のセクションでは、ETHを例にとって、お金のチャージと引き出しのプロセスを完全に説明します。

ETHトップアップ

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

2.この関数はbridge.enqueueDelayedMessage()を呼び出す。コントラクトにETHを送る。すべてのETHリチャージ資金はブリッジ契約に保管され、リチャージアドレスに相当します。

3.シーケンサーはスローボックスでトップアップメッセージをリッスンし、トップアップ操作をL2データベースに反映します。

4.シーケンサーはトランザクションバッチにトップアップレコードを含め、L1のファストボックスコントラクトに提出する。

ETHの引き出し。ETHの引き出し

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

2.ユーザーはL2上のArbSysコントラクトのwithdrawEth()関数を呼び出し、L2上の対応する量のETHを破棄します。dir="ltr" role="presentation" style="text-align: left;">2.シーケンサーはチェストに引き出し要求を送信します。

3. バリデータノードは、QuickBox内のトランザクションシーケンスに基づいて新しいロールアップブロックを作成します。

4.ロールアップ・ブロックがチャレンジ期間を生き残り、検証された後、ユーザーはL1のOutbox.execute Transaction()関数を呼び出すことができます。関数を呼び出すことができる。

5.Outboxコントラクトが確認された後、ロック解除されたブリッジ内の対応する量のETHがユーザーに送信されます。

出金。高速出金

楽観的ロールアップ公式ブリッジを使用した出金にはチャレンジ期間があります。一次ロック交換。この方法は、単純に2つのパーティがそれぞれのチェーン内で資産を交換するもので、一方のパーティがプリイメージを提供する限り、もう一方のパーティは常にそれにふさわしい資産を手に入れることができるという意味で原始的なものである。問題は流動性が比較的乏しいことで、ピアツーピアで相手を探す必要がある。

強制撤回

force Inclusion() Force Inclusion関数は、L2ローカルトランザクション、L1からL2トランザクション、L2からL1トランザクションに対するシーケンサーの精査に対抗するために使用される。シーケンサーの悪意ある検閲はトランザクション体験に深刻な影響を及ぼし、ほとんどの場合、L2からの撤退を選択することになるので、以下はforceInclusionの使い方を紹介する強制撤退の例である。

ETHの引き出しステップでは、シーケンサーの審査に関わるステップは1と2だけであることを思い出してください。

• 以下の2つのステップを変更します。align: left;">L1のslowboxコントラクトでinbox.sendL2Message()を呼び出し、入力パラメータはL2でwithdrawEth()を呼び出す際に入力する必要があるものとする。メッセージはL1のブリッジ契約と共有される。

• 強制包含のための24時間の待機期間を待った後、クイックボックスでforceを呼び出します。QuickboxのInclusion()を呼び出して強制的にインクルードし、Quickboxコントラクトがブリッジをレビューして対応するメッセージを探します。

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

また、Arb SDKの使い方については、arbitrum-tutorialsに詳細なチュートリアルがあり、L2ローカル取引とL2→L1取引のforceInclusion()についてユーザーを案内しています。