原題：「Rollup の Force Inclusion Mechanism の紹介」
著者: NIC Lin、台北イーサリアムミートアップ代表
つい昨日、数え切れない人々に衝撃を与える出来事が起きた。メタマスクの親会社であるコンセンシスが立ち上げたイーサリアムの第二層であるリネアは、積極的に閉鎖されたのは、ベロコアのハッキング事件の影響を軽減するためだと当局は述べた。そして、このことは人々に、ハッカー攻撃による損失を減らすために公式調整の下で以前にBSCチェーン（BNBチェーン）が閉鎖されたことを思い出さずにはいられません。人々がこの種のことについて話すたびに、Web3 が提唱する分散型の価値に疑問を抱くでしょう。
もちろん、上記の事件の中心的な理由は、インフラストラクチャ自体の不完全さ、つまり分散化が不十分であることにあります。チェーンが十分に分散化されていれば、すぐに停止する必要はありません。イーサリアムの第 2 層の独特な構造により、ほとんどのレイヤー 2 は集中型シーケンサーに依存していますが、近年、分散型シーケンサーを求める議論がますます増えていますが、第 2 層の目的とその構造を考慮すると、おそらく分散型シーケンサーが重要です。レイヤー 2 ソーターはあまり分散化されない可能性が高く、最終的には BSC チェーンほど分散化されない可能性があると考えられます。これが本当に事実である場合、私たちは何をすべきでしょうか?
実際、第 2 層の場合、ソーターの非分散化によって引き起こされる最も直接的な害は、その検閲への抵抗と活動にあります。トランザクションを処理するエンティティ (シーケンサー) が少数しかない場合、サービスを提供するかどうかに関して絶対的な権限を持ちます。拒否したい場合は拒否できますが、選択の余地がない場合もあります。レイヤ 2 の反検閲問題をどのように解決するかが重要なテーマであることは明らかです。
過去数年間、主要なイーサリアムの第 2 層は、Loopring と Degate、StarkEx の強制引き出しおよび脱出ハッチ機能、Arbitrum やその他の OP Rollup の Force Inclusion 機能など、検閲防止問題に対するさまざまな解決策を提案してきました。これらの方法ではチェックを作成できます。また、理由なくユーザーのトランザクション要求を拒否しないように、特定の条件下でシーケンサーのバランスをとります。
今日の記事では、台北イーサリアム協会の NIC Lin 氏が自身の説明を行い、主流の 4 つのロールアップの検閲耐性トランザクション機能を個人的に実験し、ワークフローや操作方法などの側面から強制インクルージョンのメカニズム設計を深く分析しました。イーサリアムにとって非常に重要であり、コミュニティや巨大な資産を持つ大規模な投資家にとっては特に価値があります。
トランザクションのレビューと強制的な包含
トランザクション検閲耐性 (Censorship Resistance) はブロックチェーンにとって非常に重要です。ブロックチェーンがユーザーによって開始されたトランザクションを任意にレビューして拒否できる場合、それは Web2 サーバーと何ら変わりません。イーサリアムの現在のトランザクションの検閲に対する抵抗力は、多数のバリデーターによってもたらされます。誰かがボブのトランザクションをレビューして、彼のトランザクションがチェーンにアップロードされるのを阻止したい場合、ネットワーク内のほとんどのバリデーターに賄賂を送ろうとするか、全体にスパムを送信する必要があります。ブロックスペースを占有するために、Bob よりも高い手数料でジャンクトランザクションを送信し続けます。いずれにせよ、費用は非常に高額になります。
注: 現在のイーサリアムの PBS 構造では、トランザクションをレビューするコストが大幅に削減され、Tornado Cash トランザクションをレビューするために OFAC と連携するブロックの割合を参照できます。現在の検閲への抵抗は、OFAC および政府管轄外の独立した検証者と中継に依存しています。
しかしロールアップはどうでしょうか？ Rollup は、セキュリティを確保するために多数のバリデータを必要としません。たとえ、Rollup がブロックを生成するための集中的な役割 (シーケンサー) を 1 つだけ持っていたとしても、L1 と同じくらい安全です。しかし、セキュリティと検閲耐性は別の話です。ロールアップがイーサリアムと同じくらい安全であっても、集中シーケンサーが 1 つしかない場合、ユーザーのトランザクションは検閲される可能性があります。
シーケンサーはユーザーのトランザクションの処理を拒否し、ユーザーの資金が保留され、ロールアップから離れることができなくなる可能性があります。
フォースインクルージョンのメカニズム
Rollup に多数の分散シーケンサーを要求するよりも、L1 の検閲防止機能を直接利用する方が良いでしょう。
本来、Sequencer はトランザクションデータをパッケージ化して L1 Rollup コントラクトに送信するものですが、ユーザーが自分でトランザクションを Rollup コントラクトに挿入できるようにするための仕組みを「Force Inclusion」と呼びます。 Sequencer が L1 レベルでユーザーを検閲できない限り、ユーザーが L1 でトランザクションを強制的に挿入することを防ぐことはできません。このようにして、Rollup は L1 の検閲耐性を継承することができます。
シーケンサーは、高額なコストを支払わなければユーザーの L1 トランザクションをレビューできません
強制トランザクションはどのように実行されるべきですか?
トランザクションを強制組み込みを通じてロールアップ コントラクトに直接書き込むことができる場合 (つまり、すぐに有効になる場合)、ロールアップのステータスはすぐに変更されます。たとえば、ボブは強制組み込みを通じて「キャロルに 1000 DAI を転送する」というトランザクションを挿入します。トランザクションが直ちに有効になると、最新の状態でのボブの残高は 1,000 DAI 減り、キャロルの残高は 1,000 DAI 増加します。
Force Inclusion がトランザクションをロールアップ コントラクトに直接書き込み、すぐに有効になる場合、ステータスはすぐに変更されます。
この時点でシーケンサーがオフチェーンでもトランザクションを収集し、トランザクションの次のバッチをロールアップ コントラクトに送信する場合、Bob が強制的に挿入してすぐに有効になるトランザクションの影響を受ける可能性があります。この種の問題はできる限り回避する必要があるため、ロールアップでは通常、強制組み込みトランザクションがすぐに有効になるのではなく、まずユーザーがトランザクションを L1 の待機キューに挿入して「準備中」状態に入ることができます。 。
Sequencer がオフチェーン トランザクションをパッケージ化してロールアップ コントラクトに送信するとき、Sequencer がこれらのトランザクションを「準備中」状態で無視していた場合、ウィンドウ期間の終了後、ユーザーはそれらのトランザクションをトランザクション シーケンスに挿入するかどうかを選択します。これらのトランザクションをロールアップ コントラクトに強制的に挿入できます。
シーケンサーは、キュー内で待機しているトランザクションを「偶然受信」するタイミングを決定できます。
シーケンサは、待機キュー内のトランザクションの処理を拒否することができます。
シーケンサーが長期間拒否した場合、一定期間が経過すると、誰でも強制インクルージョン機能を通じてトランザクションを強制的にロールアップ コントラクトに組み込むことができます。
次に、Optimism、Arbitrum、StarkNet、zkSync を含む 4 つのよく知られた Rollup の Force Inclusion メカニズムの実装を順番に紹介します。
オプティミズムのフォースインクルージョンメカニズム
まず、Optimism の Deposit プロセスを紹介します。この Deposit は、単に Optimism にお金を入金することだけではなく、「ユーザーが L2 に送信した情報を L2 に送信する」ことも含みます。新しくデポジットされたメッセージを受信した後、L2 ノードはそのメッセージを実行用の L2 トランザクションに変換し、メッセージの指定された受信者に送信します。
L1デポジットからL2へのユーザーメッセージ
L1クロスドメインメッセンジャーコントラクト
ユーザーが ETH または ERC-20 トークンを Optimism に入金したい場合、フロントエンド Web ページを通じて L1 上の L1StandardBridge コントラクトと対話し、入金する金額とこれらの資産を受け取る L2 アドレスを指定します。
L1StandardBridge コントラクトはメッセージを次のレベルの L1CrossDomainMessenger コントラクトに渡します。このコントラクトは主に、L1 と L2 の間の通信コンポーネントとして使用され、この一般的な通信コンポーネントを通じて L2 でトークンをキャストできる人を決定します。 . コイン、または L1 からトークンのロックを解除できる人。
開発者が L1 と L2 の間でステータスを通信および同期するコントラクトを開発する必要がある場合は、L1CrossDomainMessenger コントラクトに基づいてそれを構築できます。
ユーザーのメッセージは、CrossDomainMessenger コントラクトを通じて L1 から L2 に渡されます。
注: この記事の一部の図では、CrossDomainMessager は CrossChainMessager と書かれています
Optimismポータル契約
L1CrossDomainMessenger コントラクトは、メッセージを最下位の OptimismPortal コントラクトに送信します。処理後、OptimismPortal コントラクトは TransactionDeposited というイベントをスローします。パラメーターには、「メッセージを送信した人」、「メッセージを受信した人」が含まれます。および関連する実行パラメータ。
次に、L2 Optimism ノードは、OptimismPortal コントラクトによってスローされた Transaction Deposited イベントをリッスンし、イベント内のパラメーターを L2 トランザクションに変換します。このトランザクションの開始者は、Transaction Deposited イベント パラメーターで指定された「メッセージ送信者」になります。トランザクション受信者はイベント パラメーターの「メッセージを受信する人」であり、他のトランザクション パラメーターも上記のイベントのパラメーターから派生します。
L2 ノードは、OptimismPortalemit の Transaction Deposited イベント パラメーターを L2 トランザクションに変換します。
たとえば、これはユーザーが L1StandardBridge コントラクトを通じて 0.01ETH を入金するトランザクションです。このメッセージと ETH は OptimismPortal コントラクト (アドレスは 0xbEb5...06Ed) まで送信され、その後 L2 に変換されます。数分後のトランザクション:
メッセージの開始者は L1CrossDomainMessenger コントラクト、受信者は L2 の L2CrossDomainMessenger コントラクトです。メッセージの内容は、L1StandardBridge が BoB の 0.01ETH デポジットを受け取ったというものです。この後、追加の 0.01 ETH を L2StandardBridge に発行するなど、いくつかのプロセスがトリガーされ、Bob に転送されます。
具体的にどうやって発動させるか
トランザクションを Optimism のロールアップ コントラクトに強制的に組み込む場合、達成したい効果は、「L2 アドレスから L2 で開始および実行されるトランザクション」をスムーズに実行できるようにすることです。このとき、L2 アドレスを使用する必要があります。メッセージを OptimismPortal コントラクトに直接送信します (OptimismPortal コントラクトは実際には L1 上にありますが、OP のアドレス形式は L1 アドレス形式と同じであることに注意してください。OP と同じアドレスを持つ L1 アカウントを使用して、上記のコントラクトを直接呼び出すことができます) L2 アカウント)。
コントラクトによってスローされる Transaction Deposited イベントによって変換される L2 トランザクションの「開始者」は、この時点でのトランザクション形式は通常の L2 トランザクションと一致します。
Transaction Deposit イベントから変換された L2 トランザクションでは、開始者はボブ自身であり、受信者は Uniswap コントラクトであり、ボブ自身が L2 トランザクションを開始したのと同様に、指定された ETH が伴います。
Optimism の Force Inclusion 関数を呼び出したい場合は、OptimismPortal コントラクトの DepositTransaction 関数を直接呼び出し、L2 で実行したいトランザクションのパラメーターを入力する必要があります。
このトランザクションは、自分のアドレスを使用して L2 (0xeDc1...6909) で自己転送し、「強制インクルージョン」というテキスト メッセージを添付するという、簡単な強制インクルージョンの実験を行いました。
これは、OptimismPortal コントラクトを介して DepositTransaction 関数を実行する L1 トランザクションです。Transaction Deposited イベントで、from と to の両方が自分自身をスローしていることがわかります。
残りの不透明なデータ列の値は、「デポジット トランザクション機能を呼び出した人に付属する ETH の量」、「L2 トランザクションの開始者が受信者に送信したい ETH の量」、「L2 トランザクションの GasLimit」および「」をエンコードします。 L2 受信者のデータへ」およびその他の情報。
上記の情報をデコードすると、次の情報が得られます。
「デポジットトランザクションを呼び出した人が添付したETHの金額」：0、L1からL2にETHをデポジットしなかったため。
「L2 トランザクションの開始者が受信者に送信したい ETH の量」: 5566 (wei)
「L2トランザクションのGasLimit」: 50000
「L2 レシーバーのデータ」: 0x666f72636520696e636c7573696f6e、これは文字列「force inclusion」の 16 進数エンコードです。
その後すぐに、変換された L2 トランザクションが表示されました。これは、私が自分自身に送金した L2 トランザクションで、金額は 5566 ウェイで、データは「強制包含」文字列でした。また、図の最後から 2 行目のその他の属性の TxnType (トランザクション タイプ) にシステム トランザクション 126 (システム) が示されていることがわかります。これは、このトランザクションが L2 で私によって開始されたのではなく、L1 トランザクションによってデポジットされたことを意味します。 . イベントから変換されます。
変換された L2 トランザクション
L2 コントラクトを呼び出し、Force Inclusion を通じて別のデータを送信したい場合は、前のデポジット トランザクション関数にパラメータを 1 つずつ入力するだけです。L2 アカウントと同じ L1 アドレスを使用して、L2 コントラクトを呼び出すことを忘れないでください。入金トランザクション関数。これにより、入金イベントが L2 トランザクションに変換されるとき、開始者は L2 アカウントになります。
シーケンサーウィンドウ
前述の Optimism L2 ノードは、Transaction Deposited イベントを L2 トランザクションに変換します。実際、この Optimism ノードはシーケンサーを参照します。したがって、前述のイベントをいつ変換するかを決定できるのはシーケンサーだけです。 L2トランザクション。
TransactionDeposited イベントをリッスンする場合、シーケンサーはイベントをすぐに L2 トランザクションに変換するとは限りません。この期間の最大値は SequencerWindow と呼ばれます。
Optimism メインネットの現在のシーケンサー ウィンドウは 24 時間です。つまり、ユーザーが L1 または Force include から金額を入金すると、最悪のシナリオでは 24 時間後に L2 トランザクション履歴に含まれることになります。
Arbitrum のフォースインクルージョンメカニズム
Optimism では、L1 の Deposit 操作によって Transaction Deposited イベントがスローされ、残りはシーケンサーが上記の操作を収集するのを待つことになりますが、Arbitrum では、L1 で発生する操作 (お金の節約や L2 へのメッセージの送信など)。 .) は、単にイベントをスローするのではなく、L1 キューに保存されます。
シーケンサーには、上記のキュー内のトランザクションを L2 トランザクション履歴に含める時間が与えられます。時間が経過してもシーケンサーが何もしない場合は、誰でもシーケンサーのトランザクションを完了できます。
Arbitrum は、L1 コントラクト内のキューを維持します。シーケンサーがキュー内のトランザクションをアクティブに処理しない場合、時間切れになると、誰でもキュー内のトランザクションを強制的に L2 トランザクション履歴に含めることができます。
Arbitrum の設計では、L1 で発生するデポジットなどの操作は、遅延受信ボックス コントラクトを経由する必要があります。その名前が示すように、ここでの操作は遅延して有効になります。ここがシーケンサー受信ボックスです。シーケンサーは L2 トランザクションを L1 にアップロードします。シーケンサーは L2 トランザクションをアップロードするたびに、遅延受信ボックスから保留中のトランザクションをいくつか取り出し、トランザクション履歴に書き込むことができます。
Sequencer は新しいトランザクションを書き込むときに、DelayedInbox からトランザクションを取り出して一緒に書き込むことができます。
複雑なデザインと優れた参考資料
読者がシーケンサーとフォースインクルージョンに関する Arbitrum の公式章を直接参照すると、フォースインクルージョンがどのように大まかに機能するか、またいくつかのパラメーター名と関数名が言及されていることがわかります。
ユーザーはまず DelayedInbox コントラクトに移動して sendUnsignedTransaction 関数を呼び出します。Sequencer が約 24 時間以内に含まれない場合、ユーザーは SequencerInbox コントラクトの ForceInclusion 関数を呼び出すことができます。その後、Arbitrum公式は公式Webサイトのドキュメントに関数のリンクを添付していないため、コントラクトコード内の対応する関数を自分で見ることしかできません。
sendUnsignedTransaction 関数を見つけると、nonce 値と maxFeePerGas 値を自分で入力する必要があることがわかります。 nonce はどのアドレスですか? maxFeePerGas はどのネットワーク上にありますか?それを埋める最良の方法は何ですか?ファイル参照はなく、Natpsec さえありません。次に、Arbitrum コントラクトにも同様の関数が多数含まれていることがわかります。
SendL1FundedUnsignedTransaction、sendUnsignedTransactionToFork、sendContractTransaction、sendL1FundedContractTransaction、これらの関数の違い、使用方法、パラメータの入力方法を説明する文書はなく、Natpsec さえありません。
試してみようという気持ちでパラメータを入力してトランザクションを送信しようとすると、正しい使用方法が見つかるかどうかを試行錯誤したいと考えていますが、これらの関数はすべて L1 アドレスに対して AddressAliasing を実行していることがわかります。トランザクションを開始するときの送信者は単に別のアドレスであるため、L2 アドレスは動かないままになります。
L2メッセージを送信
その後、誤って Google 検索をクリックして、Arbitrum にチュートリアル ライブラリがあることを知りました。このライブラリには、L1 から L2 トランザクションを送信する方法 (強制インクルージョンの意味です) を示すスクリプトが含まれており、そこにリストされている関数はどの関数でもありません。上で説明しましたが、sendL2Message という関数であり、message パラメーターは実際には L2 アカウントで署名されたトランザクションですか?
「Force Inclusion を通じて L2 に送信されたメッセージ」が実際には「署名付き L2 トランザクション」であることを誰が予想したでしょうか。また、この関数をいつどのように使用するかを説明するドキュメントや Natspec はありません。
結論: Arbitrum 強制トランザクションを手動で生成するのは面倒なので、公式チュートリアルに従って Arbitrum SDK を実行することをお勧めします。他のロールアップとは異なり、Arbitrum には明確な開発者ドキュメントとコード ノートがあり、多くの関数の目的とパラメーターに説明が不足しているため、開発者はアクセスして使用するのに予想以上に時間がかかります。 Arbitrum Discord の Arbitrum 関係者にも質問しましたが、満足のいく回答は得られませんでした。
Discordで質問したところ、相手はsendL2Messageを見ろと言うだけで、他の関数（Force Inclusionのドキュメントに記載されているsendUnsignedTransactionさえも）の機能や、それらが何に使われるのか、どのように使用するのかを説明したがりませんでした。 、いつ使用するか。
StarkNet の ForceInclusion メカニズム
残念ながら、StarkNet には現在、ForceInclusion メカニズムがありません。公式フォーラムには検閲と ForceInclusion について論じた記事が 2 つしかありません。
失敗したトランザクションを証明できません
上記の理由は、実際には、StarkNet のゼロ知識証明システムが失敗したトランザクションを証明できないため、強制包含が許可されないためです。なぜなら、誰かが悪意を持って (または意図せずに) 証明できない失敗したトランザクションを強制インクルードした場合、StarkNet は直接スタックしてしまうからです。トランザクションが強制的にインクルードされた後、Prover は失敗したトランザクションを証明しなければなりませんが、証明する方法がないからです。
StarkNet は、バージョン v0.15.0 で失敗したトランザクションを証明する機能を導入する予定であり、その後、強制包含メカニズムをさらに実装できるようになるはずです。
zkSync の ForceInclusion メカニズム
zkSync の L1->L2 メッセージ送信と Force Inclusion メカニズムはすべて、MailBox コントラクトの requestL2Transaction 関数を通じて実行されます。ユーザーは、L2 アドレス、calldata、追加の ETH 量、L2GasLimit 値などを指定します。requestL2Transaction は、これらのパラメーターを L2 に結合します。その後、トランザクションは優先キュー (PriorityQueue) に入れられ、(commitBatches 関数を通じて) トランザクションがパッケージ化されて L1 にアップロードされると、シーケンサーは優先キューから取り出して L2 トランザクション レコードに含めるトランザクションの数を示します。 。
zkSync は、Arbitrum のようなものではなく、Force Inclusion の形式で Optimism に非常に似ています。これは、イニシエーターの L2 アドレス (L1 アドレスと一致する) を使用して、関連する関数を呼び出し、データ (callee、calldata など) を書き込みます。署名された L2 トランザクションでは、しかし設計は Arbitrum と同じで、どちらも L1 にキュー Queue を維持し、シーケンサーはユーザーによって直接送信された保留中のトランザクションをキューから取り出してトランザクション履歴の中間に書き込みます。
このトランザクションのように、zkSync の公式ブリッジを通じて Deposit ETH にアクセスすると、MailBox コントラクトの requestL2Transaction 関数が呼び出され、Deposit ETH の L2 トランザクションが優先キューに入れられ、NewPriorityRequest イベントがスローされます。コントラクトは L2 トランザクション データをバイト列にエンコードするため、この L1 トランザクションのパラメータを見ると、パラメータ内の L2 の受信者がトランザクションの開始者でもあることがわかります (自分に入金されているため）、しばらくして、この L2 トランザクションが Sequencer によって優先キューから取り出され、トランザクション履歴に含められると、L2 上で自分に転送されたトランザクションに変換され、その量は送金は、L1 のトランザクション開始者のデポジットです。ETH トランザクションで運ばれる ETH の量です。
L1Deposit トランザクションでは、トランザクションの開始者と受信者は両方とも 0xeDc1...6909、金額は 0.03ETH、calldata は空です。
L2 で自分に送金する 0xeDc1...6909 のトランザクションが発生します。トランザクション タイプ (TxnType) は 255 で、これはシステム トランザクションです。
次に、zkSync の requestL2Transaction 関数を直接呼び出し、OP の強制トランザクション関数を実験したときに行ったように自己転送を送信しました。ETH を使用せずに、calldata に「強制インクルージョン」文字列の HEX エンコーディングが取り込まれました。
次に、それ自体への L2 の最後のトランザクションに変換されます。calldata は、「force inclusion」の 16 進文字列: 0x666f72636520696e636c7573696f6e です。
シーケンサーがトランザクションを PriorityQueue から取り出してトランザクション履歴に書き込むと、そのトランザクションは L2 上の対応する L2 トランザクションに変換されます。
requestL2Transaction 関数を通じて、ユーザーは同じ L2 アドレスを持つ L1 アカウントを使用して、L2 受信者、付随する ETH 金額、および呼び出しデータを指定して、L1 に情報を送信できます。ユーザーが異なるデータを持つ他のコントラクトを呼び出したい場合は、requestL2Transaction 関数にパラメーターを 1 つずつ入力することで同じことが行われます。
ユーザーが強制的に含めることを可能にする機能はありません
L2 トランザクションが優先キューに配置された後、L2 トランザクションがシーケンサーに含められるまでの待機期間が同時に計算されますが、現在の zkSync 設計には、ユーザーが強制できる強制組み込み機能がありません。セットの半分に相当します。つまり、「含めるまでの待機期間」がありますが、実際には「シーケンサーが収益を受け取りたいかどうかを確認している」ということです。シーケンサーはトランザクションを受け取る前に有効期限まで待つことができますが、トランザクションをまったく受け取ることができません。優先キューに入れられます。
将来的には、収入の有効期間が過ぎてもシーケンサーに含まれていない場合に、ユーザーがトランザクションを強制的に L2 トランザクション履歴に含めることができるように、zkSync は関連機能を追加する必要があります。これは真に効果的な強制組み込みメカニズムです。
要約する
L1 はネットワークの「セキュリティ」と「検閲耐性」を確保するために多数のバリデーターに依存しています。ロールアップはトランザクションの作成に少数または単一のシーケンサーを使用しますが、その検閲耐性はさらに弱いです。したがって、ロールアップには、ユーザーがシーケンサーをバイパスしてトランザクションを履歴に書き込めるようにする強制包含メカニズムが必要です。これにより、シーケンサーによるレビューが行われてロールアップの使用や資金引き出しが不可能になるのを回避できます。
Force Inclusion を使用すると、ユーザーはトランザクションを履歴に強制的に書き込むことができますが、設計では、トランザクションをすぐに履歴に挿入し、すぐに有効にするかどうかを選択する必要があります。トランザクションの即時有効化を許可すると、L2 で受信を待機しているトランザクションが L1 で強制的に受信されたトランザクションの影響を受ける可能性があるため、シーケンサーに悪影響を及ぼします。
したがって、ロールアップの現在の強制包含メカニズムでは、最初に L1 に挿入されたトランザクションを待機状態にし、シーケンサーに反応してこれらの保留中のトランザクションを含めるかどうかを選択するための時間を与えます。
zkSync と Arbitrum は両方とも、L1 にキュー Queue を維持し、L1 からユーザーによって送信された L2 トランザクションまたは L2 へのメッセージを管理します。 Arbitrum は DelayedInbox と呼ばれ、zkSync は PriorityQueue と呼ばれます。
ただし、zkSync が L2 トランザクションを送信する方法は、L2 アドレスを使用して L1 にメッセージを送信する方法と似ています。L2 トランザクションに変換した後、イニシエーターは L2 アドレスになります。 L2 トランザクションを送信する Optimism の機能は、depositTransaction と呼ばれます。zkSync は、requestL2Transaction と呼ばれます。 Arbitrum は、完全な L2 トランザクションを生成して署名し、sendL2Message 関数を通じて送信します。Arbitrum は、L2 トランザクションの開始者として、L2 上の署名を通じて署名者を復元します。
StarkNet には現在強制インクルージョンのメカニズムがありません。zkSync は強制インクルージョンの半分のセットのようなものです。PriorityQueue があり、キュー内の各 L2 トランザクションにはインクルージョンの有効期間がありますが、実際にはこの有効期間は装飾用にすぎません。シーケンサーは、PriorityQueue に L2 トランザクションをまったく含めないことを選択できます
