Rollup の Force Inclusion メカニズムの概要

原作者: NIC リン
元のソース: メディア
フォースがあなたとともにありますように。この記事では、Rollup のトランザクション検閲防止メカニズムである Force Inclusion を紹介し、いくつかの有名な Rollup の設計と実践を例として使用します。
Unsplash の Artur Tumasjan による写真
前提知識:
ロールアップの仕組みと、ロールアップがトランザクションを L1 にアップロードする必要がある理由を理解する
取引検閲への抵抗
トランザクションの検閲耐性 (検閲耐性) は、ブロックチェーンにとって非常に重要です。ブロックチェーンがあらゆる検閲ユーザーに対してトランザクションを実行できる場合、このブロックチェーンは Web2 サーバーと何ら変わりません。イーサリアムの現在のトランザクションの検閲に対する耐性は、多数のバリデーターによるものです。アリスがボブのトランザクションをレビューして、彼のトランザクションがチェーンにアップロードされるのを阻止したい場合、アリスはネットワーク内のすべてのバリデーターに賄賂を贈ろうとする必要があります。電子メール ネットワーク全体が、ブロックを埋めるために、ボブのトランザクションよりも多いスパム トランザクションを送信し続けます。いずれにせよ、彼女にかかる費用は非常に高額になるでしょう。
注: イーサリアムの現在の PBS アーキテクチャでは、レビューのコストは実際に大幅に削減されています。Tornado Cash トランザクションにおけるブロックの割合に関する OFAC のレビューを参照してください。現在の検閲への抵抗は、OFAC および政府管轄外の独立した検証者と中継に依存しています。
しかし、ロールアップについてはどうでしょうか? Rollup はセキュリティを確保するために多数のバリデータを必要としません。また、Rollup はブロックをバッチ処理するための集中型の役割 (シーケンサー、シーケンサーまたはシーケンサーと呼ばれます) のみを持ち、L1 と同じくらい安全です。ただし、セキュリティと検閲への耐性は別のものです。ロールアップの構築はイーサリアムと同じくらい安全ですが、必要に応じてシーケンサーがユーザーのトランザクションをレビューできるようになります。
シーケンサーはユーザー トランザクションの受信を拒否し、ユーザーがロールアップを使用できなくなったり、ロールアップから離れたりする可能性があります。
強制包含メカニズム
同時に、検閲耐性を確保するために、ロールアップには L1 と同じ数のバリデータが必要です。L1 の検閲耐性を直接使用することをお勧めします。シーケンサーはトランザクション データも L1 のロールアップ コントラクトに圧縮します。ユーザーを監視するためのロールアップ コントラクトの関数。この方法は、強制包含と呼ばれます。 Sequencer が監視ユーザーの「L1 トランザクション」を確認できない限り、ユーザーが L1 経由でロールアップ トランザクションを強制的に挿入することを防ぐことはできません。また、ロールアップの操作とセキュリティは L1 の検閲防止機能に基づいています。
非常に複雑なコストが発生しない限り、シーケンサーはユーザーの L1 トランザクションをレビューできません
注: 強制的な包含は、ロールアップが確実に L1 を突破してロールアップ トランザクションを強制的に挿入できるように設計されている場合にのみ可能です。 Rollup が強制包含メカニズムを提供しない場合、ユーザーは Sequencer レビューが勝手に取引されないことを祈るしかありません。
トランザクションは即時に有効になりますが、遅延して有効になります。
Force Inclusion を通じて挿入されたトランザクションを Rollup のトランザクション履歴に直接書き込むことを許可すると (即座に有効になります)、Rollup のステータスはすぐに変更されます。たとえば、Bob が Force Inclusion メカニズムを通じてペンを挿入すると、「彼は 1000 を転送しました。」 DAI から「キャロル」へのトランザクションで、トランザクションが即時に発効した場合、最新の状態でのボブの残高は 1000 DAI 減り、キャロルの残高は 1000 DAI 増になります (もちろん、ボブの残高が 1000 DAI を超えていることが前提です)。
ボブのトランザクションがトランザクション履歴に直接書き込まれ、すぐに有効になる場合、ロールアップのステータスはすぐに変更されます。
この時点でシーケンサーがオフチェーンでトランザクションを収集しており、次のトランザクションがロールアップ コントラクトに送信されるまで待機している場合、ボブが強制的に挿入してすぐに有効になるトランザクションの影響を受ける可能性があります。たとえば、ボブは事前に「1000 DAI をアリスに転送する」という支払いトランザクションをシーケンサーに送信するだけで済みます。シーケンサーは、問題がないことを確認し、収入を受け取ることを約束するのと同じです。トランザクションが受信されるかどうかをシーケンサーで計算します (Alice は 1000 DAI が多く、Bob は 1000 DAI が少ない)。しかし、ボブがトランザクションを強制的に挿入しようと急いでいることをシーケンサが発見したとき、シーケンサは、「ボブが 1000 DAI をアリスに転送した」トランザクションが実行失敗になったことを知り、アリスは実行できなくなりました。 1000DAIまで取得します。
シーケンサーがボブのトランザクションを受信するため、アリスは 1000 DAI を受け取ると信じています
その結果、ボブは L1 で別の競合するトランザクションを直接受信することを強制したため、シーケンサーの手元にあるトランザクションは受信されず、アリスは DAI を取得できませんでした。
これはユーザー エクスペリエンスが良くない可能性があるため、ロールアップは通常、強制包含トランザクションをすぐに有効にしますが、トランザクションを「準備中」状態に進めます。シーケンサは、予算トランザクションの送信時に「準備中」状態になるトランザクションをバッチの最後に追加するかどうかを選択できます。シーケンサがこれらの「準備中」状態を処理したくない場合は、これらのトランザクションは後で処理されます。一定時間が経過すると、強制的に取引履歴に挿入されます。
ボブは収益トランザクションを強制することでアリスをだまそうとしていますが、実際にはトランザクションが最初にキューに入れられます。
シーケンサは待機中のトランザクションをいつキューに「含める」かを独自に決定できるため、ボブからアリス DAI へのトランザクションが最初に実行されます。
シーケンサーがキュー内のトランザクションを待っていない場合、一定の時間が経過すると、ユーザー (または誰でも) が自分で収益を強制できます。
シーケンサーはボブのトランザクションの受信を拒否したため、ボブは L1 からトランザクションをキューに入れます。
シーケンサーはしばらくキュー内のトランザクションを拒否し続ける可能性があります
ただし、シーケンサーはキューで待機しているトランザクションを永久に拒否することはできません。一定時間が経過すると、誰でも強制インカムをトリガーできます。次に、Optimism、Arbitrum、StarkNet、zkSync などのより有名なロールアップの強制封じ込めメカニズムの実装を紹介します。 。
楽観的なパワー包括メカニズム
まず、Optimism の Deposit プロセスを紹介します。この Deposit は、Optimism にお金を入金することを指すだけでなく、より一般的な「L2 用のメッセージを L2 に入金する」ことにも相当します。新たにデポジットされたメッセージを受信した後、L2 ノードはメッセージを送信し、実行のためにポート L2 トランザクションに変換し、指定された受信者にメッセージを送信します。
L1 から L2 に入金するユーザーからのメッセージ
L1CrossDomainMessenger コントラクト
ユーザーが ETH または ERC-20 トークンを Optimism に入金することを決定すると、L1 上の L1StandardBridge コントラクトと (クロスウェブで) 対話し、入金する金額や受け取り先のアドレスなどを指定します。次に、L1StandardBridge 接続メッセージは、次の層の L1CrossDomainMessenger コントラクトに渡されます。このコントラクトは、主に L1 と L2 の間の一般的な通信コントラクトとして使用され、L2 上の L2StandardBridge と通信して、誰がミントによって開始できるかを決定します。 L2 からのトークン、または L1 からのトークンの引き出し。開発者が L1 と L2 の間の相互運用性と同期ステータスに関する契約を作成する必要がある場合は、L1CrossDomainMessenger 上にそれを構築できます。
ユーザーのメッセージング CrossChainMessenger コントラクトは L1 から L2 に渡されます
Optimismポータル契約
L1CrossDomainMessenger コントラクトは、最下位レベルの OptimismPortal コントラクトにメッセージを送信します。OptimismPortal コントラクトが処理された後、TransactionDeposited イベントが発行されます。イベント パラメーターには、「メッセージを送信した人」、「メッセージを受信した人」が含まれます。 "、および関連する実行パラメータ。
次に、L2 の Optimism ノードは、OptimismPortal アグリーメントによって発行された TransactionDeposited イベントをリッスンし、イベント内のパラメーターを L2 を記録するトランザクションに変換します。この L2 トランザクションの開始者は、TransactionDeposited イベントの「メッセージ送信者」である可能性があります。トランザクションを送信した人 受信者はイベントの「メッセージを受信する人」となり、他の実行パラメータもイベントパラメータによって渡されます。
L2 ノードは、OptimismPortal によって発行された TransactionDeposited イベントをアノテーション付き L2 トランザクションに挿入します。
たとえば、これはユーザーが L1StandardBridge コントラクトを通じて 0.01 ETH を入金するトランザクションです。このメッセージと ETH は OptimismPortal コントラクトまで送信されます (アドレスは 0xbEb5...06Ed です)。 L2 トランザクションに移行し、メッセージの開始者は L1CrossDomainMessenger コントラクトです。受信者は L2 上の L2CrossDomainMessenger コントラクトです。
強制的に含める
ユーザーがトランザクションを強制的に楽観的に実行したい場合は、L1 から L2 にメッセージを送信する必要がないため、L1CrossDomainMessenger コントラクトを使用しません。彼が達成したい効果は、特定の請求書を「L2 アドレスから L2 上で送信および実行するトランザクション」がスムーズに実行されるようにすることです。そのため、彼は OptimismPortal コントラクトと直接対話し、L2 アドレスから OptimismPortal コントラクトを呼び出すことができます。 TransactionDeposited イベントが L2 トランザクションに変換されると、「トランザクションの開始者」がその L2 アドレスになるため、トランザクションを再度確認できるようになります。
TransactionDeposited イベントから変換された L2 トランザクションでは、開始者はボブ自身であり、受信者は、ボブ自身が L2 トランザクションを開始したのと同様に、指定された ETH を伴います。
L2 アドレスを使用して、OptimismPortal によって署名された DepositTransaction 関数を呼び出します。L2 トランザクションのパラメーターを 1 つずつ入力することを忘れないでください。
私は簡単な強制組み込みトランザクションを作成しました。つまり、L2 アドレス (0xeDc1...6909) で自分に送金し、「強制組み込み」テキスト メッセージを添付しました。これは、OptimismPortal コントラクトを通じて DepositTransaction 関数を実行した L1 トランザクションです。発行された TransactionDeposited イベントでは、from と to が両方とも自分自身であり、残りの opaqueData フィールドの値 (000000000000000000000000000000000000000000000000000000000000 0) であることがわかります。 00000000000000000000000000000000000000000000000000015BE000000000000C35000666F72636520696E636C7573696F6E) どのくらいエンコードされますか? 「その人が添付するETHの量」、「L2トランザクションの開始者はL2受信者にETHを添付する必要がある」、「L2トランザクションのガス制限」、「L2受信者へのデータ」などの情報。
L1 トランザクションによって発行された TransactionDeposited イベント
この opaqueData 内のいくつかの情報の数値を解釈すると、次の結果が得られます。
「DepositTransactionを呼び出した人にどれだけのETHが添付されているか」：L1からL2にETHをリチャージしたくないため0
「L2 トランザクションの開始者が L2 受信者に送信する必要がある ETH の量」: 5566 (wei)、自分自身に送金したいため
「L2トランザクションガス制限」：50,000
「L2 レシーバーのデータ」: 0x666f72636520696e636c7573696f6e、この文字列の 16 進エンコーディングの「強制組み込み」をクリアします
その後間もなく、変換された L2 トランザクションが表示されました。私が自分に送金した L2 トランザクションを記録します。金額は 5566、データは「必須含める」文字列です。また、図の最後から 2 行目のその他の属性の Txn Type (トランザクション タイプ) がシステム トランザクション 126 (システム) であることがわかります。これは、トランザクションが L2 で私によって開始されたのではなく、トランザクション 126 から変換されたことを意味します。 L1TransactionDeposited イベント。
変換が完了したL2トランザクション
ユーザーが異なるデータを持つ他のコントラクトを呼び出したい場合は、L2 トランザクションのイニシエーターが L1 で実行するために L2 アドレスを使用することを忘れないでください。 L2アドレスになります。
シーケンサーウィンドウ
前述の Optimism L2 ノードは、TransactionDeposited イベントを L2 トランザクションに変換します。実際、この Optimism ノードは Sequencer ノードを参照しているため、いつ L2 トランザクションに変換するかを決定できるのは Sequencer だけです。 。 TransactionDeposited イベントをリッスンする場合、シーケンサーはイベントをすぐに L2 トランザクションに変換する必要はありませんが、一定期間変換することを決定できます。この期間は、Optimism ではシーケンサー ウィンドウと呼ばれます。メインネットは現在 24 時間です。その後、ユーザーが L1 から入金を開始するか、プロンプトを受信するか、強制的にトップアップトランザクションを含めると、最悪のシナリオは 24 時間後に正式に L2 トランザクション履歴に追加されます。しかし少なくとも、トランザクションが何もできないよりはマシです。
Arbitrum の強制包含メカニズム
楽観的に考えると、L1 のデポジット操作は TransactionDeposited イベントを発行し、残りはシーケンサーがデポジット操作を受け取るのを待つことになりますが、L1 のすべての操作 (お金のデポジットや L2 へのメッセージの送信など) は保存されます。イベントを発行するだけではなく、 L1 によって合意されたキューに入れられます。シーケンサーには、このキュー内の L1 操作をトランザクション履歴に追加するための時間が与えられ、時間が経過してシーケンサーが使用されると、誰もシーケンサーを交換することなく完了できます。
アービトレーションは、L1 コントラクト内のキューを維持します。シーケンサーがキュー内のトランザクションをアクティブに受信しない場合、時間切れになると、誰でもキュー内のトランザクションをトランザクション履歴に強制的に入力できます。
すべての L1 操作は Delayed Inbox コントラクトであり、その名前が示すように、ここでの操作は遅延して期限切れになります。もう 1 つのコントラクトは Sequencer Inbox であり、L2 トランザクションを Sequencer にアップロードするためのインターフェイスです。 Sequencer によってアップロードされたトランザクションは、トランザクション履歴に直接書き込まれます。さらに、Sequencer がアップロードするときに、遅延受信ボックスから取得する L1 操作の数を選択し、それらをまとめてトランザクション履歴に書き込むことができます。これにより、これらの L1 操作がかかるようになります。効果。
SequencerInbox にはトランザクション履歴が含まれます。通常、新しいトランザクションを直接書き込むことができるのは Sequencer だけです。DelayedInbox には受信待ちのトランザクションが含まれます。
Sequencer は新しいトランザクションを書き込むときに、DelayedInbox からトランザクションを開始して一緒に書き込むことができます。
複雑な設計と印象的なドキュメント
読者がシーケンサと強制インクルージョンに関する Arbitrum の公式章を直接参照すると、そこで言及されている強制インクルージョンがどのように互換性があるか、またいくつかのパラメータ名と関数名がわかるでしょう。 ユーザーはまず受信トレイに移動して、sendUnsignedTransaction 関数を呼び出す予約をします。シーケンサーが 24 時間以内に予定の収入に参加していない場合、ユーザーはシーケンサーの受信箱によって署名された ForceInclusion 関数を呼び出すことができます。このように、リンクさえ含まれておらず、スキームコード内の対応する機能については自分で同意することしかできません。
sendUnsignedTransaction 関数を見つけると、実際には nonce 値と maxFeePerGas 値を自分で入力する必要があることがわかります。 nonce はどのアドレスですか? maxFeePerGas 値はどのネットワークですか?それを埋める最良の方法は何ですか? Natpsec によってさえドキュメントがありません。次に、スキンを蓄積する関数 sendL1FundedUnsignedTransaction、sendUnsignedTransactionToFork、sendContractTransaction、sendL1FundedContractTransaction も見つかります。また、これらの関数の違い、使用方法、およびパラメーターの入力方法を説明するドキュメントはありません。Natpsec さえもありません。
パラメータを入力してトランザクションを送信する前に、すべてを検討して試してみて、正しい方法が見つかるかどうかを確認したいと考えていますが、これらの関数はすべて L1 アドレスをアドレスとして使用することがわかります。 L2 上のトランザクション開始者は基本的に別のアドレスであるため、L2 アドレスはまったく移動しません。
L2メッセージを送信する
その後、Google 検索ページで誤ってリンクをクリックしたところ、Arbitrum には L1 から L2 トランザクションを送信する方法 (または強制インクルージョン) を示すスクリプトが含まれていることがわかりました。その機能はまったく適切ではありませんでした。上で述べたのと同じです。それらのいずれかは単なる sendL2Message という関数であり、メッセージパラメータは実際には署名された Arbitrum L2 トランザクションですか? ? ? 「L2 メッセージの送信」が実際には「署名された L2 トランザクション」を意味することを誰が知っていたでしょうか? ?繰り返しになりますが、この関数をいつどのように使用するかを説明するドキュメントや Natspec はありません。
結論: Arbitrum 強制収益トランザクションを手動で生成するのは面倒です。公式チュートリアルに従って Arbitrum SDK を実行することをお勧めします。他のロールアップとは異なり、Arbitrum には明確な開発者ドキュメントとプロジェクト コード ノートがあり、多くの機能の目的とパラメーターに説明が不足しているため、開発者はアクセスして使用するのに予想以上に時間がかかります。 Arbitrum Discord で Arbitrum の人々にも質問しましたが、満足のいく答えは得られませんでした。
注: Discord で質問したとき、相手は sendL2Message を聞いてほしいとだけ言ってくれました。他の関数 (必須インクルード ファイルに記載されている sendUnsignedTransaction も) が何に使用されるのか、どのように使用するのか、いつ使用するのかを説明する必要はありませんでした。それらを使用してください。
残念ながら、StarkNet は現在、包含を強制していません。公式フォーラムには、検閲と強制的な包含メカニズムについて議論した記事が 2 つしかありません。
トランザクションの失敗を証明できない
その理由は、StarkNet のゼロ知識証明システムでは記録に失敗した取引を証明できないため、強制的なクレジットは許可されないためです。なぜなら、誰かが悪意を持って（または意図せずに）失敗して証明できないトランザクションの入力を強制した場合、StarkNet は直接スタックしてしまうからです。トランザクションが強制的に入力された後、証明者は失敗したトランザクションを証明しなければなりませんが、それを証明する方法がないからです。 。
StarkNet は、バージョン v0.15.0 で失敗したトランザクションを証明する機能を導入する予定であり、その後、強制包含メカニズムをさらに実装できるようになるはずです。
zkSync の必須組み込みメカニズム
zkSync の L1->L2 メッセージ パッシングと強制包含メカニズムはすべて、MailBox コントラクトの requestL2Transaction 関数を通じて実行されます。ユーザーは、呼び出す L2 アドレス、呼び出しデータ、伝送される ETH の量、L2 ガス制限値などを指定します。 requestL2Transaction のパラメーターを分割して L2 トランザクションに結合し、優先キューでシミュレートすると、シーケンサーはトランザクションのバックアップが L1 にアップロードされるときに、優先キューから取り出して一緒に受信するトランザクションの数を指定します (commitBatches 関数)。 。
zkSync は、強制インクルード インターフェイスの点で Optimistic に非常に似ています。どちらも、Arbitrum のような署名付き L2 トランザクションを入力するのではなく、ユーザーの L2 アドレスを使用して関連データ (呼び出し先、通話データなど) を入力します。ただし、設計の観点からは、トランザクションと Arbitrum は L1 にエンティティ キューを維持し、シーケンサーはキューからトランザクションを取得してトランザクション履歴に書き込みます。
ユーザーは requestL2Transaction を通じて L2 トランザクションを優先キューに挿入し、シーケンサーはバッチをコミットするときに優先キューからトランザクションと通信できます。
このときのトランザクションに相当するzkSyncの公式ブリッジ経由でETHをリチャージすると、MailBoxコントラクトのrequestL2Transaction関数を呼び出し、リチャージされたETHをL2トランザクション優先キューに保持し、NewPriorityRequestイベントを発行します。コントラクトは L2 トランザクション データをバイト文字列にエンコードするため、読み取るのは簡単ではありませんが、代わりに L1 トランザクションのパラメータを見ると、パラメータ内の L2 の受信者がトランザクションの開始者でもあることがわかります。トランザクションのため（自分への入金です）、しばらくすると、引換L2トランザクションがシーケンサーによって優先キューから取り出され、トランザクション履歴に含められると、L2上で送金を記録するトランザクションに変換されます。転送の金額は、L1 のトランザクション開始者によってデポジット ETH 取引所に持ち込まれた ETH の金額です。
L1 リチャージ トランザクションでは、トランザクションの開始者と受信者は両方とも 0xeDc1…6909、金額は 0.03 ETH、呼び出しデータは空です。
Accounting 0xeDc1…6909 は L2 に表示され、自分自身に転送するトランザクションです。トランザクション タイプ (Txn Type) は 255 で、これはシステム トランザクションです。
次に、スクリプトに従って requestL2Transaction レターを直接呼び出し、通話を記録したトランザクションを自分に送信しました。ETH なしで、通話データには「強制インクルード」文字列の 16 進エンコードが含まれていました。後続の式は、独自の通話を記録する L2 上のトランザクションに変換され、通話データには「強制包含」文字列 0x666f72636520696e636c7573696f6e が含まれます。
シーケンサーが優先キューからトランザクションを取り出してトランザクション履歴に書き込むと、L2 上の対応する L2 トランザクションに変換できます。
requestL2Transaction 関数を通じて、ユーザーは L2 アドレスを使用して L1 で L2 トランザクションをリクエストし、L2 受信者、持ち込まれた ETH の量、通話データを指定できます。ユーザーが異なるデータを持つ他のコントラクトを呼び出したい場合は、L2 トランザクションの開始者が L2 になるように、L1 で実行するために L2 アドレスを使用することを忘れずに requestL2Transaction 関数にパラメータを入力する必要があります。住所。 。
ユーザーに収入を強制する機能はありません
L2 トランザクションを優先キューに入れると、シーケンサーが収集する L2 トランザクションの期間が自動的に計算されますが、現在の zkSync の設計には、ユーザーが自分で実行できる必須の関連機能が含まれておらず、これはセットの半分に相当します。したがって、「収益有効期間」はありますが、実際には、シーケンサーが収益を受け取りたいかどうかによって異なります。シーケンサーは、移行が完了するまで収益を受け取るまで待機するか、優先キュー内のトランザクションを決して受け取ることができません。将来的には、zkSync は関連機能を追加して、収入が過ぎてもシーケンサーがまだ受け取っていない場合にユーザーが収入を強制できるようにする必要があります。これは本当に効果的な強制組み込みメカニズムです。
要約する
L1 はインターネットの「セキュリティ」と「検閲耐性」を確保するために多数の人々に依存していますが、ロールアップは「L1 と同じセキュリティ」を得るために「L1 の検閲耐性」に依存していますが、ロールアップの検閲耐性は含まれていません。能力
それどころか、Rollup はトランザクションの作成に少数のシーケンサー、または単一のシーケンサーを使用するため、検閲防止機能はさらに弱くなります。したがって、Rollup には、ユーザーが Sequencer をバイパスしてトランザクションを履歴に書き込めるようにする Force Inclusion メカニズムが必要です。これにより、Sequencer によるレビューが行われ、Rollup を使用または終了できなくなるのを回避できます。
強制的に含めることにより、ユーザーはトランザクションを強制的に履歴に書き込むことができますが、設計では、トランザクションをすぐに履歴に挿入してすぐに有効にするかどうかを選択する必要があります。トランザクションの即時有効化を許可すると、L2 で受信を待機しているトランザクションが L1 で強制的に受信されたトランザクションの影響を受ける可能性があるため、シーケンサーに問題が発生し、ユーザー エクスペリエンスが困難になります。
したがって、ロールアップの現在の強制包含メカニズムは、まず L1 に挿入されたトランザクションを待機状態にし、シーケンサーに反応してこれらの待機トランザクションを含めるかどうかを選択するための時間を与えます。
zkSync と Arbitrum は両方とも、L1 にエンティティ キューを維持し、ユーザーによって L1 から送信された L2 トランザクションまたは L2 へのメッセージを管理します。 Arbitrum では遅延受信ボックスと呼ばれ、zkSync では優先キューと呼ばれます。
ただし、zkSync が L2 トランザクションを送信する方法は Optimism と似ており、どちらも L2 アドレスを使用して L1 に送信されるため、L2 トランザクションの開始者は L2 アドレスになります。 L2 トランザクションを送信するための Optimism の関数は、depositTransaction と呼ばれます。zkSync は、requestL2Transaction と呼ばれます。 Arbitrum は、完了した L2 トランザクションを作成して署名し、sendL2Message レターを通じて送信します。Arbitrum は、L2 トランザクションの開始者として、L2 上の署名を通じて署名者を復元します。
StarkNet には現在、強制包含メカニズムがありません。zkSync は、強制包含の半分のセットを実装しています。優先キューがあり、各キューの L2 トランザクションには収入の有効期間がありますが、実際には、この有効期間は現在装飾用にすぎません。 、シーケンサーは、優先キュー内の L2 トランザクションをまったく受信しないことを選択できます。