ちょうど昨日、Metamaskの親会社であるConsensysが開発したイーサリアム レイヤー2ソリューションであるLineaが積極的にシャットダウンするという衝撃的な出来事が発生しました。公式の理由は、Velocoreハッキング事件の影響を軽減することでした。この事件は必然的に、ハッキングの損失を最小限に抑えるために公式の調整の下でBSCチェーン(BNBチェーン)もシャットダウンされた以前のケースを思い起こさせます。これらの出来事は、Web3が提唱する分散型の価値に疑問を抱かせることがよくあります。

前述の出来事の背後にある主な理由は、インフラストラクチャの不完全さ、特に分散化の欠如にあります。ブロックチェーンが十分に分散化されていれば、そう簡単にシャットダウンすることはできないはずです。イーサリアム レイヤー2の独特な構造により、ほとんどのレイヤー2ソリューションは集中型シーケンサーに依存しています。近年、分散型シーケンサーに関する議論が高まっているにもかかわらず、レイヤー2の目的と構造を考えると、レイヤー2シーケンサーが高レベルの分散化を達成する可能性は低いと想定できます。実際、BSCチェーンよりも分散化されていない可能性があります。この場合、何ができるでしょうか?レイヤー2の場合、非分散型シーケンサーの最も差し迫ったリスクは、検閲抵抗性と活性の欠如です。トランザクションを処理するエンティティ(シーケンサー)が数個しかない場合、彼らはあなたにサービスを提供するかどうかについて絶対的な力を持っています:彼らはあなたの取引を自由に拒否することができ、あなたは頼みの綱を失います。レイヤー2 での検閲抵抗の問題に取り組むことは、明らかに重要なトピックです。過去数年間、さまざまなイーサリアム レイヤー2ソリューションがこの問題に取り組むためのさまざまなアプローチを提案してきました。例えば、Loopring、Degate、StarkExは強制撤退と脱出ハッチ機能を導入し、Arbitrumやその他のOptimistic RollupsはForce Inclusion機能を実装しています。これらのメカニズムは、シーケンサーにチェックを課して、ユーザートランザクションの恣意的な拒否を防ぐことができます。今日の記事では、台北イーサリアム協会のNIC Linが、4つの主要なロールアップの検閲に強いトランザクション機能を実験し、ワークフローと運用方法に焦点を当てたフォースインクルージョンメカニズムの詳細な分析を提供し、彼の直接の経験を共有します。この分析は、イーサリアムコミュニティと大規模な資産保有者にとって特に価値があります。

トランザクション検閲と強制包含

トランザクションにおける検閲抵抗は、どのブロックチェーンにとっても重要です。ブロックチェーンがユーザーのトランザクションを恣意的に検閲し、拒否できるのであれば、Web2サーバーと何ら変わりはありません。イーサリアムの取引検閲抵抗は、現在、多数のバリデータによって保証されています。誰かがボブのトランザクションを検閲し、ブロックチェーンに含まれるのを防ぎたい場合は、ネットワークのバリデータの大部分に賄賂を贈るか、ボブよりも高い手数料のガベージトランザクションでネットワークにスパムを送信し、ブロックスペースを占有する必要があります。どちらの方法も非常にコストがかかります。

注:イーサリアムの現在の提案者とビルダーの分離(PBS)アーキテクチャでは、トランザクションを検閲するコストが大幅に削減されます。例えば、トルネードキャッシュ取引に対するOFACの検閲に準拠しているブロックの割合を見ることができます。現在の検閲抵抗は、OFACやその他の政府機関の管轄外にある独立したバリデータとリレーに依存しています。

しかし、ロールアップはどうでしょうか?ロールアップでは、セキュリティを確保するために多数のバリデータは必要ありません。ロールアップにブロックを生成する一元化されたエンティティ (シーケンサー) が 1 つしかない場合でも、レイヤー 1 (L1) と同じくらい安全です。ただし、セキュリティと検閲抵抗は別の問題です。ロールアップは、イーサリアムと同じくらい安全ですが、集中型シーケンサーが1つしかない場合は、ユーザーのトランザクションを検閲できます。

Sequencer はユーザーのトランザクションの処理を拒否し、その結果、ユーザーの資金がロックされ、ロールアップを離れることができなくなります。

強制インクルージョンメカニズム

ロールアップに多数の分散型シーケンサーを要求する代わりに、レイヤー 1 (L1) の検閲抵抗を直接活用する方が効果的です。

シーケンサーはトランザクション データをパッケージ化して L1 のロールアップ コントラクトに送信する必要があるため、ユーザーが自分でトランザクションをロールアップ コントラクトに挿入できる機能をコントラクトに追加できます。このメカニズムは「フォースインクルージョン」として知られています。シーケンサーが L1 レベルでユーザーを検閲できないロング、ユーザーが L1 でトランザクションを強制的に挿入するのを防ぐことはできません。このようにして、ロールアップはL1の検閲抵抗を継承できます。

Sequencer は、高いコストを支払わずにユーザーの L1 トランザクションを確認することはできません

強制トランザクションはどのように実装すべきか?

トランザクションを強制包含によってロールアップ コントラクトに直接書き込むことができる場合 (つまり、トランザクションはすぐに有効になります)、ロールアップの状態は即座に変化します。たとえば、Bob が強制包含メカニズムを使用して 1000 DAI を Carol に転送するトランザクションを挿入し、トランザクションがすぐに有効になった場合、更新された状態では Bob の残高は 1000 DAI 減少し、Carol の残高は 1000 DAI 増加します。

強制包含により、トランザクションをロールアップ コントラクトに直接書き込んですぐに有効にできる場合、ロールアップの状態は即座に変更されます。シーケンサーがオフチェーントランザクションを同時に収集し、次のバッチをロールアップコントラクトに送信する準備をしている場合、ボブが強制的に挿入したトランザクションによって中断される可能性があります。この問題を回避するため、ロールアップでは通常、強制包含トランザクションをすぐに有効にすることはできません。代わりに、ユーザーは最初にトランザクションを L1 の待機キューに挿入し、そこで「準備」状態に入ります。シーケンサーは、ロールアップ コントラクトに送信するオフチェーン トランザクションをパッケージ化するときに、これらのキューに入れられたトランザクションを含めるかどうかを選択できます。シーケンサーが "準備中" 状態のトランザクションを継続的に無視する場合、ウィンドウ期間が終了すると、ユーザーはこれらのトランザクションをロールアップ コントラクトに強制的に挿入できます。シーケンサーは、待機キューからトランザクションを「偶発的に含める」タイミングを決定できますが、それでもトランザクションの処理を拒否できます。シーケンサーが一貫して拒否する場合、一定期間が経過すると、誰でも強制包含機能を使用して、トランザクションをロールアップ契約に強制的に挿入できます。次に、4つの著名なロールアップ(Optimism、Arbitrum、StarkNet、zkSync)におけるフォースインクルージョンメカニズムの実装を紹介します。

シーケンサーは、待機キューからトランザクションを取得するタイミングを選択できます。

シーケンサーは、待機キュー内のトランザクションの処理を拒否できます。

シーケンサーがトランザクションの処理を一貫して拒否する場合、一定期間が経過すると、誰でも強制包含機能を使用してトランザクションをロールアップコントラクトに強制的に挿入できます。次に、フォースインクルージョンメカニズムが4つの著名なロールアップ(Optimism、Arbitrum、StarkNet、zkSync)でどのように実装されているかを紹介します。

Optimismのフォースインクルージョンメカニズム

まず、Optimismの入金プロセスについて説明しましょう。この入金プロセスには、Optimismへの資金の送金だけでなく、「L2へのユーザーメッセージ」の送信も含まれます。L2ノードは、新しく預けられたメッセージを受信すると、そのメッセージをL2トランザクションに変換して実行し、指定された受信者に配信します。

L1 から L2 にデポジットされたユーザーメッセージ

L1CrossDomainMessenger契約

ユーザーがトークンをOptimismに入金 ETHまたはERC-20したい場合、フロントエンドのWebページを介してL1のL1StandardBridgeコントラクトと対話し、入金金額とこれらの資産を受け取るL2アドレスを指定します。次に、L1StandardBridge コントラクトは、L1 と L2 間のプライマリ通信ブリッジとして機能する L1CrossDomainMessenger コントラクトにメッセージを転送します。L1StandardBridge は、この通信コンポーネントを使用して L2 の L2StandardBridge と対話し、L2 でトークンをミントしたり、L1 からトークンのロックを解除したりできるユーザーを決定します。L1 と L2 の間で状態を相互運用して同期するコントラクトを作成する必要がある開発者は、L1CrossDomainMessenger コントラクトの上にコントラクトを構築できます。

クロスドメインメッセンジャーコントラクトを介してL1からL2に送信されるユーザーメッセージ

注:この記事の一部の画像では、CrossDomainMessengerはCrossChainMessengerと表記されています。

OptimismPortal契約

次に、L1CrossDomainMessenger コントラクトは、最下位層である OptimismPortal コントラクトにメッセージを転送します。メッセージの処理後、OptimismPortalコントラクトは、「送信者」、「受信者」、その他の関連する実行の詳細などのパラメータを含むTransactionDepositedというイベントを発行します。L2 の Optimism ノードは、OptimismPortal コントラクトからこの TransactionDeposited イベントをリッスンし、イベントのパラメーターを L2 トランザクションに変換します。このトランザクションのイニシエーターはイベントで指定された「送信者」であり、受信者はイベントで言及された「受信者」であり、その他のトランザクションの詳細もイベントのパラメータから導き出されます。

L2 ノードは、OptimismPortal が発行する Transaction Deposited イベントのパラメーターを L2 トランザクションに変換します。

たとえば、ユーザーがL1StandardBridgeコントラクトを通じて0.01 ETHを入金すると、メッセージとETHがOptimismPortalコントラクト(アドレス0xbEb5...数分後、これは L2 トランザクションに変換され、メッセージの送信者は L1CrossDomainMessenger コントラクト、受信者は L2 の L2CrossDomainMessenger コントラクトであり、メッセージの内容は L1StandardBridge が Bob から 0.01 ETH 入金を受信したことを示しています。これにより、L2StandardBridge の 0.01 ETH ミンティングなどの追加プロセスがトリガーされ、その後 Bob に転送されます。

トリガーする方法

Optimismのロールアップコントラクトにトランザクションを強制的に含める場合、目標は「L2のL2アドレスから開始および実行された」トランザクションが正常に実行されるようにすることです。これを実現するには、L2 アドレスを使用して OptimismPortal コントラクトにメッセージを直接送信する必要があります (OptimismPortal コントラクトは実際には L1 にありますが、OP アドレス形式は L1 アドレス形式と一致するため、L2 アカウントと同じアドレスの L1 アカウントを使用してこのコントラクトを呼び出すことができます)。このコントラクトによって発行されるトランザクション デポジット イベントから派生した L2 トランザクションの「送信者」は、お客様の L2 アカウントとなり、トランザクション形式は標準の L2 トランザクションと一致します。

Transaction Depositedイベントから派生したL2トランザクションでは、ボブ自身がイニシエーターとなり、レシーバーはUniswapコントラクトとなり、ボブが自分でL2トランザクションを開始するかのように、指定されたETHが含まれます。

OptimismのForce Inclusion機能を使用するには、OptimismPortalコントラクトのdepositTransaction関数を直接呼び出し、L2で実行したいトランザクションのパラメータを入力する必要があります。私は簡単なフォースインクルージョン実験を行いました。このトランザクションの目的は、私のアドレス(0xeDc1...6909)に「強制インクルージョン」というメッセージを含めます。これは、OptimismPortalコントラクトを介してdepositTransaction関数を呼び出して実行したL1トランザクションです。Transaction Depositedイベントからわかるように、送信者と受信者の両方が私自身です。

不
透明な Data カラムの残りの値は、「depositTransaction 関数を呼び出す人がどれだけETHアタッチしているか」、「L2 トランザクション イニシエーターが受信者に送信するETH量」、「L2 トランザクション GasLimit」、「L2 受信者のデータ」などの情報をエンコードします。この情報をデコードすると、次の詳細が表示されます:「デポジットを呼び出した人がどれだけのETHをアタッチしたかトランザクション」:L1からL2にETHをデポジットしていないため、0。「L2トランザクションイニシエーターが受信者に送信したいETHの量」:5566(ウェイ);「L2トランザクションガスリミット」:50000;"Data for the L2 receiver": 0x666f72636520696e636c7573696f6e は、文字列 "force inclusion" の 16 進数のエンコードです。その後まもなく、変換されたL2トランザクションが現れました:5566 ウェイを自分自身に転送するL2トランザクションで、データフィールドに文字列「強制包含」が含まれています。さらに、[その他の属性] セクションの最後から 2 番目の行で、TxnType (トランザクションの種類) がシステム トランザクション 126 (システム) として表示され、このトランザクションが L2 で開始されたのではなく、L1 トランザクションの Deposited イベントから変換されたことを示しています。

変換された L2 トランザクション

Force Inclusionを介してL2コントラクトを呼び出し、異なるデータを送信する場合は、depositTransaction関数にパラメータを入力するだけです。depositTransaction 関数を呼び出すときは、L2 アカウントと同じ L1 アドレスを使用することを忘れないでください。このようにして、入金イベントがL2トランザクションに変換されると、イニシエーターはL2アカウントになります。[シーケンサー] ウィンドウ トランザクション デポジット イベントを L2 トランザクションに変換する Optimism L2 ノードは、実際にはシーケンサーです。これにはトランザクションの順序付けが関係するため、イベントを L2 トランザクションに変換するタイミングを決定できるのは Sequencer だけです。Sequencer は TransactionDeposited イベントをリッスンするときに、必ずしもイベントをすぐに L2 トランザクションに変換するわけではありません。遅延が発生する場合があります。この遅延の最大期間は、シーケンサー ウィンドウと呼ばれます。現在、Optimismメインネットのシーケンサーウィンドウは24時間です。これは、ユーザーがL1からお金を入金したり、トランザクションに強制インクルージョンを使用したりすると、最悪のシナリオでは、24時間後にL2トランザクション履歴に含まれることを意味します。

アービトラムのフォースインクルージョンメカニズム

Optimismでは、L1入金操作によってTransaction Depositedイベントがトリガーされ、あとはシーケンサーが操作を含めるのを待つだけです。ただし、Arbitrum では、L1 での操作 (資金の入金や L2 へのメッセージの送信など) は、単にイベントを発行するのではなく、L1 のキューに格納されます。Sequencer には、これらのキューに入れられたトランザクションを L2 トランザクション履歴に含めるための特定の期間があります。シーケンサーがこの期間内にインクルージョンを完了できなかった場合は、誰でもシーケンサーに代わってインクルードを完了できます。

Arbitrum は L1 コントラクトでキューを維持します。Sequencerが一定期間内にQueue内のトランザクションを処理できなかった場合、誰でも強制的にL2トランザクション履歴に含めることができます。Arbitrumの設計では、預金などのL1の操作は、Delayed Inboxコントラクトを経由する必要があり、名前が示すように、これらの操作は有効になる前に遅延されます。別のコントラクトであるシーケンサー受信トレイでは、シーケンサーが L2 トランザクションを L1 に直接アップロードします。シーケンサーは、L2 トランザクションをアップロードするたびに、遅延受信トレイから保留中のトランザクションを取得し、トランザクション履歴に含めることもできます。

Sequencer が新しいトランザクションを書き込むときに、DelayedInbox からのトランザクションを含めることもできます。

複雑な設計と標準物質の不足

シーケンサーとフォース インクルージョンに関する Arbitrum の公式ドキュメントを参照すると、フォース インクルージョンの仕組みに関する一般的な説明と、いくつかのパラメーター名と関数名が記載されています。 ユーザーはまず、DelayedInbox コントラクトで sendUnsignedTransaction 関数を呼び出します。約 24 時間以内に Sequencer にインクルードされない場合、ユーザーは SequencerInbox コントラクトで forceInclusion 関数を呼び出すことができます。ただし、公式ドキュメントにはこれらの関数へのリンクがないため、コントラクトコードで自分で調べる必要があります。sendUnsignedTransaction 関数を見つけると、ノンス値と maxFeePerGas 値を自分で入力する必要があることがわかります。それは誰のノンスですか?maxFeePerGasのネットワークはどれですか?どのように正しく記入すればよいですか?参照ドキュメントはなく、NatSpec もありません。また、Arbitrumコントラクトには、sendL1FundedUnsignedTransaction、sendUnsignedTransactionToFork、sendContractTransaction、sendL1FundedContractTransactionなど、多くの類似した関数があります。これらの関数の違い、使用方法、またはパラメーターの記入方法を説明するドキュメントは、NatSpec でさえありません。

パラメーターを入力し、試行錯誤のアプローチでトランザクションを送信してみて、正しい使用法を見つけようとします。しかし、これらすべての機能が アドレス エイリアシングを L1 アドレスに適用するため、L2 上のトランザクションの送信者がまったく異なるアドレスになり、L2 アドレスが非アクティブなままになることがわかりました。その後、Googleの検索結果に偶然出くわし、Arbitrumには、L1からL2トランザクションを送信する方法(基本的には強制インクルージョン)を示すスクリプトを含むチュートリアルライブラリがあることが明らかになりました。このチュートリアルでは、前述していない関数 sendL2Message をリストします。驚いたことに、必要なメッセージパラメータは、実際にはL2アカウントを使用した署名されたL2トランザクションです。「強制包含によって L2 に送信されたメッセージ」が実際には「署名された L2 トランザクション」であることを誰が知っていたでしょうか。さらに、この機能をいつどのように使用するかを説明するドキュメントやNatSpecはありません。

結論:Arbitrumで強制トランザクションを手動で生成するのは非常に複雑です。公式のチュートリアルに従い、Arbitrum SDKを使用することをお勧めします。他のロールアップとは異なり、Arbitrumには明確な開発者向けドキュメントとコード注釈がありません。多くの関数には、その目的やパラメーターの説明がないため、開発者はそれらを統合して使用するために予想よりもはるかに多くの時間を費やしています。Arbitrum Discordでも助けを求めましたが、満足のいく回答は得られませんでした。Discordで質問したとき、彼らは私にsendL2Messageを見るように指示しただけで、他のメソッドの機能(sendUnsignedTransactionのような強制インクルージョンのドキュメントに記載されているものを含む)、それらの目的、それらの使用方法、またはそれらをいつ使用するかについては説明しませんでした。

StarkNetのForceInclusionメカニズム

残念ながら、StarkNetには現在、Force Inclusionメカニズムがありません。公式フォーラムには、検閲と強制インクルージョンを論じた記事が2つしかありません。失敗したトランザクションを証明できない理由は、StarkNetのゼロ知識証明システムは失敗したトランザクションを証明できないため、強制インクルージョンは許可されないためです。誰かが悪意を持って(または意図せずに)失敗した証明不可能なトランザクションを強制的に含めた場合、StarkNetは行き詰まります:トランザクションが強制的に含まれると、証明者は失敗したトランザクションを証明しなければなりませんが、証明できません。StarkNetは、バージョンv0.15.0で失敗したトランザクションを証明する機能を導入する予定であり、その後、強制包含メカニズムをさらに実装する必要があります。

zkSyncのL1->L2メッセージ送信と強制包含のメカニズムは、MailBoxコントラクトのrequestL2Transaction関数を介して処理されます。ユーザーは、L2アドレス、コールデータ、接続するETHの量、L2GasLimit値、およびその他の詳細を指定します。requestL2Transaction 関数は、これらのパラメータを L2 トランザクションに結合し、PriorityQueue に配置します。Sequencer がトランザクションをパッケージ化して (commitBatches 関数を介して) L1 にアップロードすると、L2 トランザクション レコードに含めるために PriorityQueue から取得するトランザクションの数が示されます。フォースインクルージョンの観点では、zkSyncは、署名されたL2トランザクションを必要とするArbitrumのようにではなく、イニシエーターのL2アドレス(L1アドレスと同じ)を使用して関連する関数を呼び出し、必要な詳細(呼び出し先、calldataなど)を入力するOptimismに似ています。ただし、設計上は Arbitrum と似ており、どちらも L1 でキューを維持し、Sequencer はユーザーが直接送信した保留中のトランザクションをキューから取得してトランザクション履歴に書き込みます。

このトランザクションのようにzkSyncの公式ブリッジを入金 ETHすると、MailBoxコントラクトのrequestL2Transaction関数が呼び出されます。この関数は、デポジット ETH L2 トランザクションを PriorityQueue に配置し、NewPriorityRequest イベントを発行します。コントラクトはL2トランザクションデータをバイト列に変換するため、簡単には読み取れません。ただし、このL1トランザクションのパラメータを見ると、L2受信者がトランザクションのイニシエーターでもあることがわかります(自分自身への入金であるため)。しばらくして、Sequencer がこの L2 トランザクションを PriorityQueue から取り出してトランザクション履歴に含めると、L2 トランザクションに変換され、自分宛てに転送されます。送金金額は、L1デポジットETHトランザクションでイニシエーターによって添付されたETH金額になります。 L1 Depositトランザクションでは、イニシエーターと受取人の両方が0xeDc1...6909 の場合、金額は 0.03 ETH で、呼び出しデータはありません。 L2では、0xeDc1...6909 はそれ自体に転送されます。トランザクション・タイプ (TxnType) は 255 で、システム・トランザクションを示します。次に、以前にOptimismで強制トランザクション関数を試したのと同じように、zkSyncのrequestL2Transaction関数を呼び出して自己転送トランザクションを開始しました:ETHはアタッチされておらず、calldataには文字列「強制包含」のHEXエンコーディングが含まれていました。その後、これは L2 トランザクションに変換され、"force inclusion" の 16 進数文字列を含む calldata を使用して自分自身に転送されます: 0x666f72636520696e636c7573696f6e。 SequencerがPriorityQueueからトランザクションを取得してトランザクション履歴に書き込むと、対応するL2トランザクションに変換されます。requestL2Transaction 関数を使用すると、ユーザーは L2 アドレスと同じ L1 アカウントで L1 にデータを送信でき、L2 受信者、添付する ETH の量、および通話データを指定できます。ユーザーが他のコントラクトを呼び出したり、別のデータを含めたりする場合は、requestL2Transaction 関数にパラメーターを入力するだけです。 ユーザー向けの強制インクルージョン機能はまだありません PriorityQueueに置かれたL2トランザクションは、シーケンサーによってインクルードされるまでの待機期間が計算されますが、zkSyncの現在の設計には、ユーザーが強制できるForce Inclusion機能がありません。これは、部分的な解決策にすぎないことを意味します。"含めるための待機期間" がある場合でも、最終的には Sequencer がそれを含めるかどうかを決定し、Sequencer は期間が経過した後に含めるか、PriorityQueue からのトランザクションを含めないかを決定します。今後、zkSyncでは、待機期間後にSequencerにトランザクションが取り込まれなかった場合、L2のトランザクション履歴に強制的に含めることができる機能を追加していく予定です。これは、真に効果的なフォース・インクルージョン・メカニズムです。 Summarize

L1は、ネットワークの「セキュリティ」と「検閲抵抗」を確保するために、多数のバリデータに依存しています。ただし、ロールアップは、トランザクションが少数または 1 つのシーケンサーによって書き込まれるため、検閲抵抗が弱くなります。したがって、ロールアップには、ユーザーがシーケンサーをバイパスしてトランザクションを履歴に書き込み、シーケンサーによる検閲によってロールアップが使用できなくなり、ユーザーが資金を引き出すのを防ぐための強制インクルージョンメカニズムが必要です。強制インクルージョンにより、ユーザーはトランザクションを履歴に強制的に書き込むことができますが、設計では「トランザクションを履歴にすぐに挿入してすぐに有効にできる」かどうかを選択する必要があります。即時効果が許容されると、L2 の保留中のトランザクションが L1 からの強制的インクルードされたトランザクションによって影響を受ける可能性があるため、シーケンサーに悪影響を及ぼします。したがって、ロールアップの現在の強制包含メカニズムでは、まず L1 から挿入されたトランザクションが待機状態になり、シーケンサーが対応してこれらの保留中のトランザクションを含めるかどうかを決定する時間枠が与えられます。zkSync と Arbitrum はどちらも L1 にキューを保持し、L2 トランザクションまたは L1 から L2 に送信されるメッセージを管理します。Arbitrum ではこれを DelayedInbox と呼んでいます。zkSync はこれを PriorityQueue と呼んでいます。ただし、zkSyncのL2トランザクションの送信方法は、L2アドレスを使用してL1からメッセージを送信するOptimismに似ており、L2トランザクションに変換されると、イニシエーターはL2アドレスになります。OptimismでL2トランザクションを送信するための関数はdepositTransactionと呼ばれます。zkSyncでは、requestL2Transactionと呼ばれます。対照的に、Arbitrum は完全な L2 トランザクションを生成して署名し、sendL2Message 関数を介して送信します。L2 では、Arbitrum は署名を使用して、署名者を L2 トランザクションのイニシエーターとして復元します。StarkNetには現在、フォースインクルージョンメカニズムがありません。zkSyncには、PriorityQueueがあり、Queue内の各L2トランザクションには包含の有効期間がありますが、この有効期間は現在、見せかけのものです。実際には、Sequencer は PriorityQueue の L2 トランザクションを含めないことを選択できます。

免責事項:

1. この記事は[Geek Web3]から転送され、原題は「Theory and Practice: How to trigger censorship-resistant transactions in イーサリアム Rollup?」、著作権帰属は原著者[NIC Lin, Head of Taipei イーサリアム Meetup]です。 転載に異議がある場合は、Gate Learn Team、チームは関連する手順に従ってできるだけ早く処理します。

2. 免責事項:この記事で表明された見解や意見は、著者の個人的な見解を表しているにすぎず、投資アドバイスを構成するものではありません。

3. 記事の他の言語バージョンは、Gate Learnチームによって翻訳されています。Gate.io を参照せずに、翻訳された記事をコピー、配布、または盗用することは禁止されています。