著者: Benben Luo、元Arbitrumテクニカルアンバサダー、オタクWeb3コントリビューター前回の記事「元ArbitrumテクニカルアンバサダーがArbitrumのコンポーネント構造を説明する(パートI)」では、Arbitrumのコアコンポーネントにおけるシーケンサー、バリデーター、SequencerInboxコントラクト、ロールアップブロック、および非インタラクティブな不正防止の役割を紹介しましたが、本日の記事では、クロスチェーンインタラクションメッセージングと検閲に強いトランザクションエントランスに関連するArbitrumコアコンポーネントのコンポーネントに焦点を当てます。本文: 以前の記事で、シーケンサー受信トレイ コントラクトは、レイヤー 1 のシーケンサーによって公開されたトランザクション パケットのバッチを具体的に受信すると述べました。 同時に、シーケンサー インボックスは、スロー ボックス ディレイド インボックス (略してインボックス) とは対照的に、ファスト ボックスとも呼ばれます。 **以下では、遅延受信トレイなどのクロスチェーンインタラクションメッセージングに関連するコンポーネントを詳しく見ていきます。### クロスチェーンインタラクションとブリッジの原則クロスチェーンインタラクショントランザクションは、L1からL2(入金)とL2からL1(出金)に分けることができます。 ここで言及されている入出金は、必ずしも資産間の相互作用に関連しているわけではなく、資産を直接添付しないメッセージである可能性があることに注意してください。 したがって、これらの2つの単語は、クロスチェーン相互作用に関連する動作の2つの方向のみを意味します。クロスチェーン・インタラクション・トランザクションは、純粋なL2トランザクションよりも複雑で、クロスチェーン・インタラクション・トランザクションでは、L1とL2の2つの異なるシステムで情報が交換されます。また、通常クロスチェーン相互作用行動と呼ばれるものは、witnessモードのCross-Chain Interactionブリッジを持つ2つの無関係なネットワーク上でのクロスチェーン相互作用であり、このCross-chain InteractionのセキュリティはCross-Chain Interaction Bridgeの運営者に依存しており、witnessモデルに基づくCross-Chain Interactionブリッジの盗難は歴史上頻繁に発生しています。Rollup と ETHMainnet の間のクロスチェーン インタラクションの動作は、上記のクロスチェーン インタラクションとは根本的に異なり、レイヤー 2 の状態はレイヤー 1 に記録されたデータによって決定されるため、公式のロールアップ クロスチェーン インタラクション ブリッジを使用する限り、操作構造の点で絶対に安全です。 **これもRollupの本質を浮き彫りにしており、ユーザーの観点からは独立したチェーンのようなものですが、実際には、いわゆる**「Layer2」は、ユーザーに公開されているRollupのクイック表示ウィンドウにすぎず、その実際のチェーン構造はレイヤー1に焼き付けられたままです。 したがって、L2はハーフチェーン、つまり「レイヤー1で作成されたチェーン」と考えることができます。### 再試行可能なチケット 再試行可能項目クロスチェーンの相互作用は非同期で非アトミックであり、チェーンのようにトランザクションの確認を完了した後に結果を知ることは不可能であり、ある時点で反対側で何かが起こるという保証はないことに注意してください。 したがって、クロスチェーンインタラクションはいくつかのソフトな問題で失敗する可能性がありますが、再試行可能なチケットなどの適切な手段が使用されている限り、資金のスタックなどのハード問題は発生しません。**再試行可能なチケットは、公式のArbitrumブリッジを介して入金する際に使用される基本的なツールであり、**ETHおよびERC20入金が使用されます。 そのライフサイクルは3つのステップに分かれています。**1. L1でチケットを送信します。 **Delayed Inbox コントラクトの createRetryableTicket() メソッドを使用して、入金チケットを作成し、送信します。**2. L2での自動償還。 **ほとんどの場合、シーケンサーは、その後の手動操作を必要とせずに、ユーザーに代わって請求書を自動的に引き換えることができます。**3. L2です。 **L2のガス価格の急騰や手形のガスプリペイドの不足など、一部の限界的なケースでは、自動的に償還されません。 この場合、ユーザーが手動で行う必要があります。自動償還に失敗した場合は、7日以内に手動で手形を引き換える必要があり、そうでない場合は請求書が削除される(資金は永久に失われる)か、請求書の保存のためにリースを更新するための料金を支払う必要があることに注意してください。さらに、Arbitrumオフィシャルブリッジの出金プロセスと入金動作の間には一定の対称的な類似性がありますが、一方ではRollupプロトコル自体から理解できるRetryablesの概念はなく、他方ではいくつかの違いがあります。EVMにはタイマーや自動化がなく、自動償還はシーケンサーの助けを借りてL2で実現できるため、出金プロセスでは自動償還はなく、L1のユーザーはOutboxコントラクトを手動で操作してClaimで資産を取得する必要があります。引き出しの延滞請求書の問題はなく、チャレンジ期間が過ぎている限り、いつでも請求できます。 ### ERC-20アセットクロスチェーンインタラクションゲートウェイ* ERC-20資産のクロスチェーン相互作用は複雑です。 考えてみれば、いくつかの疑問があります。* トークンは L1 にデプロイされますが、L2 ではどのようにデプロイされますか?* 対応するL2は事前に手動でデプロイする必要がありますか、それともクロスオーバーしているがまだコントラクトを展開していないトークンのアセットコントラクトをシステムが自動的にデプロイできますか?* L2に対応するL1のERC-20アセットのコントラクトアドレスは何ですか? L1 と一貫性を持たせる必要がありますか?* L2でネイティブに発行されたトークンのL1へのクロスチェーンインタラクションの方法は?*調整可能なリベーストークンの数、自己成長する有利子トークン、クロスチェーンインタラクションの方法など、特別な機能を備えたトークン?これらの質問は複雑すぎて拡張できないため、すべてに答えるつもりはありません。 これらの質問は、ERC20のクロスチェーン相互作用の複雑さを説明するためにのみ使用されます。現在、多くのスケーリングソリューションでは、許可リスト+手動インベントリソリューションを使用して、さまざまな複雑な問題や境界状況を回避しています。Arbitrumは、Gatewayシステムを使用して、ERC20クロスチェーンインタラクションの問題点のほとんどを次の機能で解決します。* ゲートウェイ コンポーネントは、L1 と L2 でペアで表示されます。ゲートウェイ ルーターは、トークン L1<->Token L2 間、および一部のゲートウェイ<->一部のトークン間のアドレス マッピングを維持する役割を担います。*ゲートウェイは、StandardERC20ゲートウェイ、ジェネリックカスタムゲートウェイ、カスタムゲートウェイなどに分けて、さまざまなタイプと機能的なERC20ブリッジングの問題を解決できます。カスタムゲートウェイの必要性を説明するために、比較的単純なWETHクロスチェーンインタラクションを例に挙げてみましょう。WETHはERC20のETHに相当します。 イーサリアムがメインコインであるため、dAppsの多くの複雑な機能は不可能であり、ERC20に相当するものが必要です。 一部のETHをWETHコントラクトに転送すると、コントラクトにロックされ、同じ量のWETHが生成されます。同様にWETHを燃やしてETH取り出すことも可能です。 **もちろん、流通しているWETHの量とETHロックアップポジションの量は常に1:1になります。 ****WETHをL2に直接クロスチェーンすると、いくつかの奇妙な問題が見つかります。※L2ではETHに対応するロックアップ位置がないため、L2ではWETHをETHにアンラップすることはできません。* Wrap 関数は使用できますが、L1 と L2 の WETHコントラクトは「対称」ではないため、L1 にクロスバックした場合、これらの新しく生成された WETHをL1のETHとしてカプセル化解除することはできません。明らかに、これはWETHの設計原則に違反しています。 **次に、WETHがクロスチェーンインタラクションである場合、それが預金であろうと引き出しであろうと、最初にETHにラップされ、次に反対側にクロスしてから、WETHにラップする必要があります。 そこでWETHゲートウェイの出番です。より複雑なロジックを持つ他のトークンも同じことを行うため、クロスチェーンの相互作用環境で適切に機能するには、より複雑で適切に設計されたゲートウェイが必要です。 Arbitrumのカスタムゲートウェイは、通常のゲートウェイのクロスチェーンインタラクションロジックを継承しており、開発者はトークンロジックに関連するクロスチェーンインタラクションの動作をカスタマイズできるため、ほとんどのニーズを満たすことができます。### 受信トレイの遅延SequencerInbox に対応するのは、遅延受信トレイ (遅延受信トレイ) です。 ファスト ボックスは、シーケンサーによって発行された L2 トランザクションのバッチの受信専用であるため、L2 ネットワーク内のシーケンサーによって前処理されていないすべてのトランザクションは、ファスト ボックス コントラクトに表示されません。**スロー ボックスの最初の機能は、L1 から L2 へのトップアップ動作を処理することです。 **ユーザーがSlow Boxを通じて入金を行い、シーケンサーがそれをリッスンしてL2に反映し、最終的に入金記録がシーケンサーによってL2トランザクションシーケンスに含まれ、シーケンサー受信箱に送信されます。この例では、シーケンサーの受信トレイに送信されたトランザクションがレイヤ 2 の通常のトランザクション順序付けに干渉し、シーケンサーの作業に影響を与えるため、ユーザーがデポジット トランザクションをシーケンサー受信ボックスに直接送信することは適切ではありません。スローボックスの2つ目の機能は、検閲に抵抗することです。 **ユーザーがSlowboxコントラクトに直接送信したトランザクションは、10分以内にシーケンサーによって収集されます。 しかし、シーケンサーが悪意を持ってリクエストを無視した場合、スローボックスには強制インクルード機能もあります。トランザクションが遅延受信トレイに送信された場合、24時間後、スローボックス内のトランザクションはシーケンサーによってトランザクションシーケンスに含まれておらず、**ユーザーはレイヤー1で強制包含機能を手動でトリガーできます**、シーケンサーによって無視されたトランザクション要求はFastboxシーケンサー受信トレイに強制的にグループ化され、すべてのArbitrum Oneノードによって監視され、レイヤー2トランザクションシーケンスに強制的に含まれます。前述したように、ファストボックス内のデータは L2 の履歴データ エンティティです。 したがって、悪意のある検閲の場合、**は最終的にスローボックスを介してL2台帳にトランザクション指示を含めることができ、レイヤー2から脱出するための強制引き出しなどのシナリオをカバーします。 **このことから、トランザクションのどの方向とレベルでも、シーケンサーは最終的に永続的にレビューできないことがわかります。Slowbox Inboxのいくつかのコア機能:* depositETH() は、ETHを預けるための最も単純な関数です。* createRetryableTicket()は、ETHやERC20、メッセージの入金に使用できます。 depositETH()と比較して、入金後にL2の受取アドレスを指定できるなど、柔軟性が高いです。* forceInclusion()は強制集約関数で、誰でも呼び出すことができます。 この関数は、Slowboxコントラクトに送信されたトランザクションが24時間後に処理されていないかどうかを確認します。 条件が満たされた場合、メッセージは強制的に集約されます。ただし、force Inclusion関数は実際にはSlowboxコントラクトにあるので、理解しやすいように、ここにSlowboxに入れて一緒に説明します。### 送信トレイ送信トレイは出金にのみ関連しており、出金行動の記録および管理システムとして理解できます。* Arbitrumオフィシャルブリッジからの出金は、ロールアップブロック確定後、約7日間のチャレンジ期間が終了するまで待つ必要があることがわかっています。 チャレンジ期間の終了時に、ユーザーは対応するマークルプルーフをレイヤー1のアウトボックスコントラクトに送信し、レイヤー1は他の機能コントラクト(他のコントラクトにロックされた資産のロック解除など)と通信し、最終的に引き出しを完了します。* OutBoxコントラクトは、どのL2からL1へのクロスチェーンインタラクションメッセージが処理されたかを記録し、誰かが実行された引き出しリクエストを繰り返し送信するのを防ぎます。 mapping(uint256 => bytes32) public spen を使用して、出金リクエストの消費済みインデックスと、マッピング[spentIndex] != bytes32(0) の場合、要求は既に取り下げられています。 この原理は、リプレイ攻撃を防止するトランザクションカウンタノンスと似ています。以下では、入出金プロセスを完全に説明するために、例としてETHを取り上げます。 ERC20とERC20の違いは、ゲートウェイを経由するだけなので、繰り返さないことです。### ETH入金1. ユーザーは Slowbox の depositETH() 関数を呼び出します。2. 関数は引き続き bridge.enqueueDelayedMessage() を呼び出し、ブリッジ コントラクトにメッセージを記録し、ブリッジ コントラクトにETHを送信します。 **すべてのETH入金資金は、入金アドレスに相当するブリッジコントラクトに保管されます。 **3.シーケンサーは、スローボックス内の入金メッセージをリッスンし、入金操作をL2データベースに反映することで、ユーザーはL2ネットワークに入金した資産を見ることができます。4. シーケンサーは、デポジットレコードをバッチに含め、L1 の Express コントラクトに送信します。### ETH出金1. ユーザーは、L2 で ArbSys コントラクトの withdrawEth() 関数を呼び出し、L2 で対応する量のETHをバーンします。2. シーケンサーが Quickbox に出金リクエストを送信します。**3.バリデーターノードは、上記の出金トランザクションを含むFastboxのトランザクションシーケンスに基づいて新しいロールアップブロックを作成します。 **4. ロールアップブロックがチャレンジ期間を過ぎて確認された後、ユーザーはL1でOutbox.ute Transaction()関数を呼び出して、パラメータが前述のArbSysコントラクトによって指定されていることを証明できます。5. 送信トレイ コントラクトが正しいことを確認した後、ロック解除されたブリッジの対応する量のETHがユーザーに送信されます。### 迅速な支払い**オプティミスティック・ロールアップ・オフィシャル・ブリッジを使用した出金は、チャレンジ期間の待機期間となります。 この問題は、プライベートなサードパーティのクロスチェーンインタラクションブリッジで回避できます。*アトミックロックスワッピング。 この方法では、2つの当事者がそれぞれのチェーン内で資産を交換することしかできず、一方の当事者がプリイメージを提供する限り、両者は間違いなくふさわしい資産を手に入れることができます。 しかし、問題は流動性が相対的に乏しく、ピアツーピアで相手方を見つける必要があることです。*目撃者クロスチェーンインタラクションブリッジ。 **クロスチェーン相互作用ブリッジの一般的なタイプは、証人ブリッジです。 ユーザーは、サードパーティのブリッジまたは流動性プールのオペレーターに独自の引き出しリクエストを送信します。 証人は、クロスチェーンインタラクションがL1ファストボックスコントラクトに送信されたことを発見した後、L1側のユーザーに直接送金することができます。 このアプローチでは、基本的に別のコンセンサスシステムを使用してレイヤー2を監視し、レイヤー1にコミットしたデータを操作します。 **問題は、このモードでの安全率が公式のロールアップブリッジほど高くないことです。 **### 強制支払いforce Inclusion() は、シーケンサーの検閲に対抗するために使用され、L2 ローカル、L1 から L2、および L2 から L1 のトランザクションに使用できます。 シーケンサーの悪質な検閲は取引体験に深刻な影響を与えており、ほとんどの場合、撤退してL2を離れることを選択するため、forceInclusionの使用を導入するための強制撤退の例を以下に示します。**ETHの離脱ステップでは、ステップ1と2のみがシーケンサーレビューを含むため、次の2つのステップのみを変更する必要があることを思い出してください。* L1 のスローボックス コントラクトで inbox.sendL2Message() を呼び出し、入力パラメータは L2 で withdrawEth() を呼び出すときに入力する必要があるパラメータです。 メッセージは L1 のブリッジ コントラクトと共有されます。* 24時間の強制集約待機期間を待った後、高速ボックスで強制Inclusion()を呼び出してコレクションを強制すると、高速ボックスコントラクトはブリッジに対応するメッセージがあるかどうかを確認します。エンドユーザーは送信トレイで出金でき、残りの手順は通常の出金と同じです。さらに、arbitrum-tutorialsには、Arb SDKの使用方法に関する詳細なチュートリアルもあり、forceInclusion()を使用してL2ローカルトランザクションとL2からL1トランザクションを実行する方法をユーザーにガイドします。
元ArbitrumテクニカルアンバサダーがArbitrumのコンポーネント構造を説明(パートII)
著者: Benben Luo、元Arbitrumテクニカルアンバサダー、オタクWeb3コントリビューター
前回の記事「元ArbitrumテクニカルアンバサダーがArbitrumのコンポーネント構造を説明する(パートI)」では、Arbitrumのコアコンポーネントにおけるシーケンサー、バリデーター、SequencerInboxコントラクト、ロールアップブロック、および非インタラクティブな不正防止の役割を紹介しましたが、本日の記事では、クロスチェーンインタラクションメッセージングと検閲に強いトランザクションエントランスに関連するArbitrumコアコンポーネントのコンポーネントに焦点を当てます。
本文: 以前の記事で、シーケンサー受信トレイ コントラクトは、レイヤー 1 のシーケンサーによって公開されたトランザクション パケットのバッチを具体的に受信すると述べました。 同時に、シーケンサー インボックスは、スロー ボックス ディレイド インボックス (略してインボックス) とは対照的に、ファスト ボックスとも呼ばれます。 **以下では、遅延受信トレイなどのクロスチェーンインタラクションメッセージングに関連するコンポーネントを詳しく見ていきます。
クロスチェーンインタラクションとブリッジの原則
クロスチェーンインタラクショントランザクションは、L1からL2(入金)とL2からL1(出金)に分けることができます。 ここで言及されている入出金は、必ずしも資産間の相互作用に関連しているわけではなく、資産を直接添付しないメッセージである可能性があることに注意してください。 したがって、これらの2つの単語は、クロスチェーン相互作用に関連する動作の2つの方向のみを意味します。
クロスチェーン・インタラクション・トランザクションは、純粋なL2トランザクションよりも複雑で、クロスチェーン・インタラクション・トランザクションでは、L1とL2の2つの異なるシステムで情報が交換されます。
また、通常クロスチェーン相互作用行動と呼ばれるものは、witnessモードのCross-Chain Interactionブリッジを持つ2つの無関係なネットワーク上でのクロスチェーン相互作用であり、このCross-chain InteractionのセキュリティはCross-Chain Interaction Bridgeの運営者に依存しており、witnessモデルに基づくCross-Chain Interactionブリッジの盗難は歴史上頻繁に発生しています。
Rollup と ETHMainnet の間のクロスチェーン インタラクションの動作は、上記のクロスチェーン インタラクションとは根本的に異なり、レイヤー 2 の状態はレイヤー 1 に記録されたデータによって決定されるため、公式のロールアップ クロスチェーン インタラクション ブリッジを使用する限り、操作構造の点で絶対に安全です。 **
これもRollupの本質を浮き彫りにしており、ユーザーの観点からは独立したチェーンのようなものですが、実際には、いわゆる**「Layer2」は、ユーザーに公開されているRollupのクイック表示ウィンドウにすぎず、その実際のチェーン構造はレイヤー1に焼き付けられたままです。 したがって、L2はハーフチェーン、つまり「レイヤー1で作成されたチェーン」と考えることができます。
再試行可能なチケット 再試行可能項目
クロスチェーンの相互作用は非同期で非アトミックであり、チェーンのようにトランザクションの確認を完了した後に結果を知ることは不可能であり、ある時点で反対側で何かが起こるという保証はないことに注意してください。 したがって、クロスチェーンインタラクションはいくつかのソフトな問題で失敗する可能性がありますが、再試行可能なチケットなどの適切な手段が使用されている限り、資金のスタックなどのハード問題は発生しません。
**再試行可能なチケットは、公式のArbitrumブリッジを介して入金する際に使用される基本的なツールであり、**ETHおよびERC20入金が使用されます。 そのライフサイクルは3つのステップに分かれています。
**1. L1でチケットを送信します。 **Delayed Inbox コントラクトの createRetryableTicket() メソッドを使用して、入金チケットを作成し、送信します。
**2. L2での自動償還。 **ほとんどの場合、シーケンサーは、その後の手動操作を必要とせずに、ユーザーに代わって請求書を自動的に引き換えることができます。
**3. L2です。 **L2のガス価格の急騰や手形のガスプリペイドの不足など、一部の限界的なケースでは、自動的に償還されません。 この場合、ユーザーが手動で行う必要があります。
自動償還に失敗した場合は、7日以内に手動で手形を引き換える必要があり、そうでない場合は請求書が削除される(資金は永久に失われる)か、請求書の保存のためにリースを更新するための料金を支払う必要があることに注意してください。
さらに、Arbitrumオフィシャルブリッジの出金プロセスと入金動作の間には一定の対称的な類似性がありますが、一方ではRollupプロトコル自体から理解できるRetryablesの概念はなく、他方ではいくつかの違いがあります。
EVMにはタイマーや自動化がなく、自動償還はシーケンサーの助けを借りてL2で実現できるため、出金プロセスでは自動償還はなく、L1のユーザーはOutboxコントラクトを手動で操作してClaimで資産を取得する必要があります。 引き出しの延滞請求書の問題はなく、チャレンジ期間が過ぎている限り、いつでも請求できます。
ERC-20アセットクロスチェーンインタラクションゲートウェイ
これらの質問は複雑すぎて拡張できないため、すべてに答えるつもりはありません。 これらの質問は、ERC20のクロスチェーン相互作用の複雑さを説明するためにのみ使用されます。
現在、多くのスケーリングソリューションでは、許可リスト+手動インベントリソリューションを使用して、さまざまな複雑な問題や境界状況を回避しています。
Arbitrumは、Gatewayシステムを使用して、ERC20クロスチェーンインタラクションの問題点のほとんどを次の機能で解決します。
カスタムゲートウェイの必要性を説明するために、比較的単純なWETHクロスチェーンインタラクションを例に挙げてみましょう。
WETHはERC20のETHに相当します。 イーサリアムがメインコインであるため、dAppsの多くの複雑な機能は不可能であり、ERC20に相当するものが必要です。 一部のETHをWETHコントラクトに転送すると、コントラクトにロックされ、同じ量のWETHが生成されます。
同様にWETHを燃やしてETH取り出すことも可能です。 **もちろん、流通しているWETHの量とETHロックアップポジションの量は常に1:1になります。 **
**WETHをL2に直接クロスチェーンすると、いくつかの奇妙な問題が見つかります。
※L2ではETHに対応するロックアップ位置がないため、L2ではWETHをETHにアンラップすることはできません。
明らかに、これはWETHの設計原則に違反しています。 **次に、WETHがクロスチェーンインタラクションである場合、それが預金であろうと引き出しであろうと、最初にETHにラップされ、次に反対側にクロスしてから、WETHにラップする必要があります。 そこでWETHゲートウェイの出番です。
より複雑なロジックを持つ他のトークンも同じことを行うため、クロスチェーンの相互作用環境で適切に機能するには、より複雑で適切に設計されたゲートウェイが必要です。 Arbitrumのカスタムゲートウェイは、通常のゲートウェイのクロスチェーンインタラクションロジックを継承しており、開発者はトークンロジックに関連するクロスチェーンインタラクションの動作をカスタマイズできるため、ほとんどのニーズを満たすことができます。
受信トレイの遅延
SequencerInbox に対応するのは、遅延受信トレイ (遅延受信トレイ) です。 ファスト ボックスは、シーケンサーによって発行された L2 トランザクションのバッチの受信専用であるため、L2 ネットワーク内のシーケンサーによって前処理されていないすべてのトランザクションは、ファスト ボックス コントラクトに表示されません。
**スロー ボックスの最初の機能は、L1 から L2 へのトップアップ動作を処理することです。 **ユーザーがSlow Boxを通じて入金を行い、シーケンサーがそれをリッスンしてL2に反映し、最終的に入金記録がシーケンサーによってL2トランザクションシーケンスに含まれ、シーケンサー受信箱に送信されます。
この例では、シーケンサーの受信トレイに送信されたトランザクションがレイヤ 2 の通常のトランザクション順序付けに干渉し、シーケンサーの作業に影響を与えるため、ユーザーがデポジット トランザクションをシーケンサー受信ボックスに直接送信することは適切ではありません。
スローボックスの2つ目の機能は、検閲に抵抗することです。 **ユーザーがSlowboxコントラクトに直接送信したトランザクションは、10分以内にシーケンサーによって収集されます。 しかし、シーケンサーが悪意を持ってリクエストを無視した場合、スローボックスには強制インクルード機能もあります。
トランザクションが遅延受信トレイに送信された場合、24時間後、スローボックス内のトランザクションはシーケンサーによってトランザクションシーケンスに含まれておらず、ユーザーはレイヤー1で強制包含機能を手動でトリガーできます、シーケンサーによって無視されたトランザクション要求はFastboxシーケンサー受信トレイに強制的にグループ化され、すべてのArbitrum Oneノードによって監視され、レイヤー2トランザクションシーケンスに強制的に含まれます。
前述したように、ファストボックス内のデータは L2 の履歴データ エンティティです。 したがって、悪意のある検閲の場合、**は最終的にスローボックスを介してL2台帳にトランザクション指示を含めることができ、レイヤー2から脱出するための強制引き出しなどのシナリオをカバーします。 **
このことから、トランザクションのどの方向とレベルでも、シーケンサーは最終的に永続的にレビューできないことがわかります。
Slowbox Inboxのいくつかのコア機能:
ただし、force Inclusion関数は実際にはSlowboxコントラクトにあるので、理解しやすいように、ここにSlowboxに入れて一緒に説明します。
送信トレイ
送信トレイは出金にのみ関連しており、出金行動の記録および管理システムとして理解できます。
以下では、入出金プロセスを完全に説明するために、例としてETHを取り上げます。 ERC20とERC20の違いは、ゲートウェイを経由するだけなので、繰り返さないことです。
ETH入金
ユーザーは Slowbox の depositETH() 関数を呼び出します。
関数は引き続き bridge.enqueueDelayedMessage() を呼び出し、ブリッジ コントラクトにメッセージを記録し、ブリッジ コントラクトにETHを送信します。 **すべてのETH入金資金は、入金アドレスに相当するブリッジコントラクトに保管されます。 **
3.シーケンサーは、スローボックス内の入金メッセージをリッスンし、入金操作をL2データベースに反映することで、ユーザーはL2ネットワークに入金した資産を見ることができます。
ETH出金
ユーザーは、L2 で ArbSys コントラクトの withdrawEth() 関数を呼び出し、L2 で対応する量のETHをバーンします。
シーケンサーが Quickbox に出金リクエストを送信します。
**3.バリデーターノードは、上記の出金トランザクションを含むFastboxのトランザクションシーケンスに基づいて新しいロールアップブロックを作成します。 **
ロールアップブロックがチャレンジ期間を過ぎて確認された後、ユーザーはL1でOutbox.ute Transaction()関数を呼び出して、パラメータが前述のArbSysコントラクトによって指定されていることを証明できます。
送信トレイ コントラクトが正しいことを確認した後、ロック解除されたブリッジの対応する量のETHがユーザーに送信されます。
迅速な支払い
**オプティミスティック・ロールアップ・オフィシャル・ブリッジを使用した出金は、チャレンジ期間の待機期間となります。 この問題は、プライベートなサードパーティのクロスチェーンインタラクションブリッジで回避できます。
*アトミックロックスワッピング。 この方法では、2つの当事者がそれぞれのチェーン内で資産を交換することしかできず、一方の当事者がプリイメージを提供する限り、両者は間違いなくふさわしい資産を手に入れることができます。 しかし、問題は流動性が相対的に乏しく、ピアツーピアで相手方を見つける必要があることです。 *目撃者クロスチェーンインタラクションブリッジ。 **クロスチェーン相互作用ブリッジの一般的なタイプは、証人ブリッジです。 ユーザーは、サードパーティのブリッジまたは流動性プールのオペレーターに独自の引き出しリクエストを送信します。 証人は、クロスチェーンインタラクションがL1ファストボックスコントラクトに送信されたことを発見した後、L1側のユーザーに直接送金することができます。 このアプローチでは、基本的に別のコンセンサスシステムを使用してレイヤー2を監視し、レイヤー1にコミットしたデータを操作します。 **問題は、このモードでの安全率が公式のロールアップブリッジほど高くないことです。 **
強制支払い
force Inclusion() は、シーケンサーの検閲に対抗するために使用され、L2 ローカル、L1 から L2、および L2 から L1 のトランザクションに使用できます。 シーケンサーの悪質な検閲は取引体験に深刻な影響を与えており、ほとんどの場合、撤退してL2を離れることを選択するため、forceInclusionの使用を導入するための強制撤退の例を以下に示します。
**ETHの離脱ステップでは、ステップ1と2のみがシーケンサーレビューを含むため、次の2つのステップのみを変更する必要があることを思い出してください。
エンドユーザーは送信トレイで出金でき、残りの手順は通常の出金と同じです。
さらに、arbitrum-tutorialsには、Arb SDKの使用方法に関する詳細なチュートリアルもあり、forceInclusion()を使用してL2ローカルトランザクションとL2からL1トランザクションを実行する方法をユーザーにガイドします。