理論と実践：Ether Rollupにおける検閲に強いトランザクションはどのようにトリガーされるのか？

著者: NIC Lin, Head of Taipei Ethereum Meetup

Originally title: "Introducing Rollup's Force Inclusion Mechanism"

つい昨日、数え切れないほどの数百万人に衝撃を与える出来事が起こりました：Metamaskの親会社であるConsensysによって立ち上げられたEtherの第2層であるLineaが、自主的に閉鎖されました。Metamaskの親会社であるConsensysによって立ち上げられたEtherLineの第2階層が自主的に閉鎖され、公式にはVelocoreのハッキングの影響を減らすために行われたと主張している。そしてこれは、ハッキングの被害を軽減するために公式によって調整された前回のBNBチェーンのシャットダウンを彷彿とさせる。こういった話が出るたびに、Web3が提唱する分散型の価値観が疑われる。

もちろん、上記の事件の核心的な理由は、インフラ自体の不完全さにある。十分に分散化されていない: チェーンが十分に分散化されているのであれば、ただ停止するだけではいけません。イーサのレイヤー2のユニークな構造により、レイヤー2のほとんどは中央集権的なシーケンサーに依存しています。近年、非中央集権的なシーケンサーを求める議論が高まっていますが、レイヤー2の存在意義とその構造を考えると、レイヤー2のシーケンサーはそれほど非中央集権的なものにはならないと考えるのが妥当でしょう。そして、BSC チェーンよりも分散化されていないかもしれません。もしそれが本当なら、私たちはどうすればいいのでしょうか？

実際、レイヤー 2 にとって、非中央集権的なシーケンサーから生じる最も直接的な害は、検閲への抵抗と活動です。トランザクションを処理するエンティティ（シーケンサー）の数が非常に少ない場合、シーケンサーはあなたにサービスを提供するかどうかの問題で絶対的な権力を握っています。検閲に対するLayer2の抵抗にどう対処するかは、明らかに重要なトピックです。

過去数年の間に、主要なイーサネットレイヤー2は、LoopringやDegate、StarkExの強制退出やエスケープポッド機能、Arbitrumやその他のOP Rollupの強制インクルージョン機能など、反検閲問題に対するさまざまな解決策を打ち出してきました。これは、特定の条件下で、シーケンサーが任意のユーザーからの取引要求を不当に拒否するのを防ぐためのチェックとバランスを作成します。

本日の記事では、台北イーサネットワーク協会のNIC Linが4つの主流なロールアップの反検閲トランザクション機能を個人的に実験し、ワークフローと操作方法の観点から強制包含メカニズムの設計を徹底的に分析しました。イーサリアムコミュニティや、巨額の資産を手にしている大口投資家にとって特に価値がある。

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

トランザクション検閲 抵抗力はブロックチェーンにとって非常に重要であり、ブロックチェーンが恣意的にユーザー主導のトランザクションを検閲し拒否できるのであれば、それはWeb2サーバーと変わりません。Etherの現在のトランザクション検閲耐性は多数のValidatorに由来しているため、誰かがBobのトランザクションを検閲してブロックチェーンから排除したい場合、ネットワーク内のValidatorの大半を買収しようとするか、ネットワーク全体をスパムしてBobのトランザクションよりも手数料の高いゴミのようなトランザクションを送り続け、ブロック上のスペースを奪うかのどちらかになります。いずれにせよ、コストは非常に高くなります。

注：イーサリアムの現在のPBSアーキテクチャでは、トランザクションを検閲するコストはかなり低くなります。

しかし、Rollupはどうでしょうか。Rollupは安全であるためにたくさんのValidatorを必要としませんし、仮にRollupがブロックを生成する中央集権的な役割（Sequencer）しか持っていなかったとしても、L1と同じくらい安全でしょう。しかし、セキュリティと検閲耐性は2つの異なるものであり、RollupがEtherと同じくらい安全であっても、中央集権的なシーケンサーが1つあるだけで、やろうと思えばどのユーザーのトランザクションも検閲することができます。

シーケンサーはユーザーの取引を処理するのを拒否することができ、その結果、ユーザーの資金はロールアップから出るのを保留されることになる

強制包含メカニズム

その要件について

本来、シーケンサーは取引データをL1のロールアップコントラクトにパッケージするためのものなので、ユーザが自分で取引をロールアップコントラクトに挿入できるような設計をコントラクトに組み込んだ方がよいでしょう。この仕組みは「フォース・インクルージョン」と呼ばれる。シーケンサーがL1レベルでユーザーを検閲できない限り、ユーザーがL1レベルでトランザクションを強制的に挿入するのを防ぐことはできない。このように、ロールアップはL1の検閲耐性を継承している。

シーケンサーは、多額の費用がかからない限り、ユーザーのL1取引をレビューすることはできません

強制取引はどのように機能すべきでしょうか？

トランザクションが強制包含によってロールアップ契約に直接書き込まれることを許可する場合 (つまり、即座に有効になる)、ロールアップのステータスは即座に変更されます。たとえば、ボブが強制包含によって「1,000 DAIをキャロルに送金する」というトランザクションを挿入した場合、ロールアップのステータスは即座に変更されます。例えば、BobがForce Inclusionメカニズムを使って「1000DAIをCarolに送金する」というトランザクションを挿入した場合、そのトランザクションが直ちに有効になれば、最新の状態でのBobの残高は1000DAI少なくなり、Carolの残高は1000DAI多くなる。

フォース・インクルージョンがトランザクションをロールアップ契約に直接書き込んで、すぐに反映させることができれば、状態はすぐに変わります。

シーケンサーがこの時点でチェーンの下のトランザクションも収集し、次のトランザクションバッチをロールアップ契約に送信している場合、ボブのフォースインクルージョンによって即座に影響を受ける可能性がある。これは避けるべき問題であるため、Rollupは強制包含トランザクションを即座に有効にせず、代わりにユーザーがL1上の待機キューにトランザクションを挿入し、「準備完了」状態に入ることを可能にする。

Sequencerは、オフチェーントランザクションをRollup契約にパッケージするときに、これらのトランザクションをトランザクションシーケンスに含めるかどうかを選択し、Sequencerが「準備完了」状態のトランザクションを無視し続けている場合、ユーザーはウィンドウが期限切れになった後、これらのトランザクションをキューに含めるように強制することができます。もしSequencerが "ready "状態のこれらのトランザクションを無視し続けているのであれば、ウィンドウが終了した時点で、ユーザーはこれらのトランザクションを強制的にRollup契約に入れることができる。

シーケンサーは待ち行列のトランザクションをいつ「ドロップバイ」するかを決定できる

Sequencer can still refuse to process transactions in the wait queue

Sequencer can still refuse to process transactions in the wait queue

シーケンサーが長期間拒否した場合、時間が経てば誰でも強制インクルージョン機能を使ってトランザクションをロールアップ契約に強制することができます

次はOptimismを順番に取り上げます、Arbitrum、StarkNet、zkSyncを順に取り上げます。

Optimismの強制包含メカニズム

まず、Optimismの入金プロセスを紹介しますが、これはOptimismに入金するという意味だけではありません。"このDepositは、単にOptimismにお金を預けるだけでなく、ユーザーがL2に送信するメッセージを送信し、L2ノードは新たに預けられたメッセージを受信すると、そのメッセージをL2トランザクションに変換して実行し、メッセージで指定された受信者に送信します。

ユーザーによるL1 DepositからL2へのメッセージ

L1CrossDomainMessenger Contract

ユーザーがETHまたはERC-20トークンをOptimismに入金したい場合。

ユーザーがETHまたはERC-20トークンをOptimismに入金したいとき、そのユーザーはフロントエンドのウェブページを介してL1のL1StandardBridgeコントラクトとやり取りし、入金する金額とそれらの資産を受け取るL2アドレスを指定します。

次にL1StandardBridge契約は、L1CrossDomainMessenger契約の次のレベルにメッセージを渡します。L1CrossDomainMessenger契約は、L1とL2が互いに通信するためのコンポーネントとして機能します。その後、L1StandardBridgeはこの共通通信コンポーネントを使用して、L2上のL2StandardBridgeと通信し、誰がL2でトークンを鋳造できるか、または誰がL1からトークンのロックを解除できるかを決定します。

開発者がL1とL2の間で相互運用し、状態を同期するコントラクトを開発する必要がある場合、L1CrossDomainMessengerコントラクトの上に構築することができます。

ユーザーのメッセージはCrossDomainMessenger契約を通してL1からL2に渡されます  注意：この記事の一部の

OptimismPortalコントラクト

L1CrossDomainMessengerコントラクトは、メッセージを一番下のOptimismPortal

に送信します。を一番下のOptimismPortalコントラクトに送信し、次のパラメータを持つTransactionDepositedというイベントをスローします。"、"Receiver"、および関連する実行パラメータ。

L2 Optimismノードは次に、OptimismPortalコントラクトによってスローされるTransaction Depositedイベントをリッスンし、イベント内のパラメータをL2トランザクションに変換し、トランザクションによって開始される。このトランザクションの開始者はDepositedイベントパラメータで指定された「送信者」であり、トランザクションの受信者はイベントパラメータの「受信者」であり、他のトランザクションパラメータは上記イベントのパラメータから導出される。

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

例えば、あるユーザーがL1StandardBridgeコントラクトを介してデポジットした0.01ETHトランザクションを示します。0.01ETH、このメッセージとETHはOptimismPortalコントラクト（アドレス0xbEb5...06Ed）まで移動し、数分後にL2トランザクションに変換されました:

メッセージのイニシエータはL1CrossDomainMessengerコントラクトです；メッセージは、L1StandardBridgeがBoBから0.01ETHのデポジットを受け取ったというものです。これはその後、追加の0.01ETHをL2StandardBridgeに送信するなどの処理をトリガーし、L2StandardBridgeはそれをBobに渡します。

具体的にどのように起こるのか

Optimismのロールアップコントラクトにトランザクションを強制したい場合、達成したいことは次のとおりです。L2上の自分のL2アドレスから開始され、実行される」トランザクションが実行できるのであれば、自分のL2アドレスを持つOptimismPortalコントラクトに直接メッセージを送信することです（OptimismPortalコントラクトは実際にはL1にありますが、OPはL2にあることに注意してください）。OPのアドレス形式はL1のアドレス形式と同じですが、L2アカウントと同じアドレスを持つL1アカウントで上記の契約を直接呼び出すことができます)。

コントラクトがTransaction Depositedイベントをスローした後、L2トランザクションの「イニシエータ」はL2アカウントになり、トランザクションフォーマットは通常のL2トランザクションと同じになります。

Transaction Depositedイベントから変換されたL2トランザクションでは、開始者はBob自身となり、受信者はUniswapコントラクトとなり、Bob自身がL2トランザクションを開始した場合と同じように、指定された量のETHを伴います

仮に、次のようなものがあったとする。OptimismのForce Inclusion関数を呼び出す場合、OptimismPortalコントラクトのdepositTransaction関数を直接呼び出し、L2で実行したいトランザクションのパラメータを入力したいと思うでしょう

簡単なForce Inclusion実験を行いました。L2の私のアドレス(0xeDc1...6909)から「force inclusion」というテキストメッセージで自己送金するというものです。

これは私がOptimismPortalコントラクトを通してdepositTransaction関数を実行したL1トランザクションで、それが投げるTransaction Depositedイベントで、fromとtoが両方とも私自身であることがわかります

Data 列の不透明な値の残りは、「いくら ETH が預け入れトランザクション関数の呼び出しにアタッチされたか」、「いくら ETH がETH"、"L2トランザクションイニシエータがレシーバに送信しているETHの量"、"L2 Transaction GasLimit"、および "L2レシーバへのデータ"。「など。

上記の情報をデコードすると、次のようになります:

"Deposit Transaction "を呼び出した人がどれだけのETHをアタッチしたか: 0、L1からETHを貯めていないから。L2にETHを預ける。

"L2トランザクションのイニシエーターは、レシーバーにいくらETHを送らなければならないか": 5566 (wei)

L2トランザクションのガスリミット。": 50000

"L2 Receiverへのデータ": 0x666f72636520696e636c7573696f6e、これはワードである。文字列 "force inclusion "の16進エンコード

それから変換されたL2トランザクションが表示されるのに時間はかからなかった。「force inclusion "という文字列だった。このトランザクションはL2で自分が開始したものではなく、L1トランザクションのDepositedイベントから変換されたものであることを示している。

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

L2コントラクトを呼び出したい場合は、L2コントラクトを呼び出すために、強制インクルードメソッドを使用します。強制インクルージョンによってL2コントラクトを呼び出し、異なるデータを送信したい場合は、前のデポジット・トランザクション関数にパラメータを1つずつ入力するだけです。がL2トランザクションに変換されるとき、イニシエータはL2アカウントになります。

SequencerWindow

前述のOptimism L2ノードは、Transaction DepositedイベントをL2トランザクションに変換します。Sequencingに関連しているので、Sequencerだけが前述のイベントをL2トランザクションに変換するタイミングを決定できる。

TransactionDepositedイベントをリッスンするとき、シーケンサーは必ずしもすぐにイベントをL2トランザクションに変換するわけではありません。シーケンサーウィンドウは現在24時間です。つまり、ユーザーがL1から大金を入金したり、フォースがトランザクションを含めると、それがL2のトランザクション履歴に含まれるまで最悪24時間かかります。

Arbitrum's Force Inclusion Mechanism

Optimism では、L1 Deposit オペレーションは Transaction Deposited イベントをスローします。しかしアービトラムでは、L1で発生する操作（入金やL2へのメッセージの受け渡しなど）は、単にイベントを投げるのではなく、L1のキューに格納されます。

シーケンサーには、上記のキューにあるトランザクションをL2のトランザクション履歴に組み込むための期間が与えられており、もしシーケンサーがその時間の終わりまでに何もしていなければ、誰でもシーケンサーの代わりにそれをしに行くことができます。

Arbitrum はL1コントラクトでキューを維持します。

アービトラムはL1コントラクトでキューを維持し、シーケンサーがキュー内のトランザクションを積極的に処理しなければ、時が来れば誰でもキュー内のトランザクションを強制的にL2のトランザクション履歴に含めることができます

アービトラムの設計では、L1で発生した入金などのオペレーションは、その名の通りオペレーションが遅延するコントラクトであるDelayed Inboxコントラクトで実行され、別のコントラクトはオペレーションが遅延するコントラクトになります。もう1つのコントラクトは Sequencer Inbox で、これは Sequencer が L2 トランザクションを直接 L1 にアップロードする場所である。シーケンサーがL2トランザクションをアップロードするたびに、Delayed Inboxから保留中のトランザクションをいくつか取り出し、トランザクション履歴に書き込むことができる。

Sequencer writes a new transaction along with the transaction from the DelayedInboxComplicated design and poor references

読者がシーケンサーとフォースインクルージョンに関する公式のArbitrumの章を直接参照すると、フォースインクルージョンが一般的にどのように機能するのか、またパラメータや関数名の一部について言及されていることがわかります：

ユーザーはまずDelayedInboxセクションに行きます。DelayedInboxコントラクトでsendUnsignedTransaction関数を呼び出し、シーケンサーが約24時間以内にインクルードしなければ、ユーザーはSequencerInbox関数を呼び出すことができます。コントラクトのforceInclusion関数を呼び出します。それから、Arbitrumは公式ドキュメントに関数へのリンクを添付していないので、自分で契約コードの対応する関数を調べなければなりません。

sendUnsignedTransaction関数を見つけると、nonceとmaxFeePerGasの値を埋めなければならないことがわかります。どのアドレスのnonceと、どのネットワークのmaxFeePerGasを記入するのがベストでしょうか？Natpsecでさえ、参照するドキュメントがない。

sendL1FundedUnsignedTransaction、sendUnsignedTransactionToFork、sendContractTransaction、sendL1FundedContractTransaction、これらの関数の違いや使い方、パラメーターの記入方法などを説明する文書はなく、Natpsecさえもありません。

正しい使い方がわかるか試行錯誤しながら、パラメータを埋めてトランザクションを送信しようとしますが、そのとき、これらの関数はすべてL1アドレスに対してAddressAliasingを行い、最終的にL2でトランザクションを開始したときに、Senderのアドレスが異なることに気づき、L2アドレスは動きません。

sendL2Message

それからたまたまGoogle検索をして、Arbitrum自身がL1からL2トランザクションを送信する方法（別名Force Inclusion）を実演するスクリプトを含むチュートリアルライブラリを持っていることに気づきました。)そして、上記の関数の代わりにsendL2Messageという関数がリストアップされており、持ち込むメッセージパラメータはL2アカウントで署名されたトランザクションであることに気づきました。

「Force Inclusion経由でL2に送信」されるメッセージが「署名されたL2トランザクション」であることを誰が知っていたのでしょうか？そして、いつ、どのようにこの機能を使うかを説明する文書やNatspecはありません。

結論：Arbitrum用の強制トランザクションを手動で生成するのは少し厄介ですので、公式チュートリアルからArbitrum SDKを実行することをお勧めします。 Arbitrumには、他のRollupsのような明確な開発者向けドキュメントやコードノートがなく、関数の用途やパラメーターの多くが説明されていないため、予想以上にコストがかかります。関数やパラメータの多くが説明されていないため、開発者がそれらにアクセスして使用するには予想以上に時間がかかる。Arbitrum DiscordでArbitrumの人たちにも聞いてみましたが、満足のいく回答は得られませんでした。

Discordで尋ねたところ、sendL2Messageを見るように言われただけで、他の関数が何をするのか（Force Inclusionのドキュメントで言及されているsendUnsignedTransactionでさえも）、何をするのか、どのようにするのか、いつするのかを説明しようとはしませんでした。

StarkNetのForceInclusionメカニズム

悲しいことに、StarkNetにはまだForceInclusionメカニズムがありません。公式フォーラムにはCensorshipとForceInclusionについて論じた記事が2つあるだけです。

失敗したトランザクションを証明できない

上記の理由は、StarkNetのゼロ知識証明システムには失敗したトランザクションを証明する方法がないからです。なぜなら、誰かが悪意を持って（あるいは意図せずに）失敗した証明不可能なトランザクションを強制的にインクルードした場合、StarkNetは単に立ち往生してしまうからです： トランザクションが強制的にインクルードされた後、証明者は失敗したトランザクションを証明しなければなりませんが、それをする方法がないからです。

そしてStarkNetはv0.15.0で失敗したトランザクションを証明する機能を導入する予定です。

zkSyncのForceInclusionメカニズム

zkSyncのL1->L2メッセージングとForce Inclusionメカニズムは、MailBoxコントラクトのユーザーはL2アドレス、calldata、追加ETHの量、L2GasLimit値などを指定します。requestL2TransactionはこれらのパラメーターをL2トランザクションにまとめ、優先キュー（PriorityQueue）に入れます。PriorityQueue）、シーケンサーは（commitBatches関数を介して）L1にアップロードされたトランザクションにパッケージ化され、L2トランザクションレコードに一緒に含まれるように、方法によって優先順位キューから取り出されるトランザクションの数を示します。

zkSyncは、Arbitrumのように1つのトランザクションを埋めるのではなく、関連する関数を呼び出すためにオリジネーターのL2アドレス（これはL1アドレスと同じです）を取り、情報（callee、calldataなど）を埋めるという点で、Force Inclusion形式のOptimismと非常によく似ています。L2トランザクションに署名した。しかし、設計はArbitrumと同じで、L1でキューQueueを維持し、Sequencerにユーザーによって提出された保留中のトランザクションをQueueから直接取り出し、トランザクション履歴に書き込ませる。このトランザクションのように、公式のzkSyncブリッジを経由してDeposit ETHに行くと、MailBoxコントラクトのrequestL2Transaction関数が呼び出され、このDeposit ETH L2トランザクションを優先キューに入れ、NewPriorityRequestイベントをスローします。コントラクトはL2トランザクション情報をバイト列にエンコードしているため、読み取るのは容易ではない。そのため、代わりにこのL1トランザクションのパラメータを見ると、パラメータ内のL2レシーバーがトランザクションのイニシエーターでもあることがわかる（自分自身への入金であるため）。しばらくして、このL2トランザクションがSequeuncerによって優先キューから取り出され、トランザクションの履歴に含まれると、L2によって自分自身への入金に変換され、NewPriorityRequestイベントがスローされる。このトランザクションはL2によって自分自身へのデポジットに変換され、NewPriorityRequestイベントがスローされる。自分自身を自分自身へ送金するトランザクションに変換され、送金額はトランザクションのオリジネーターがL1のデポジットETHトランザクションで持ち込んだETHの額となる。

L1Depositトランザクション、トランザクションのイニシエータとレシーバはどちらも0xeDc1...6909、金額は0.03ETH、calldataは空

L2には0xeDc1の量があります。...6909の自己送金があり、トランザクションタイプ(TxnType)は255で、これはシステムトランザクションです

それから、以前OPの強制トランザクション関数の実験で行ったように、zkSyncのrequestL2Transaction関数を直接呼び出して自己送金を行いました：ETHなしで、calldataは "force inclusion "文字列のHEXエンコーディングをもたらします。

その後、calldataの「force inclusion」16進文字列：0x666f72636520696e636c7573696f6e.

シーケンサーがPriorityQueueからトランザクションを取り出し、トランザクション履歴に書き込むとき、それはL2上の対応するL2トランザクションに変換されます

requestL2Transaction関数を通して、ユーザーはL2アドレスと同じL1アカウントを使ってL1で情報を提出することができます。L2の受信者、添付されたETHの量、calldataを指定し、ユーザーが異なるデータで他のコントラクトを呼び出したい場合は、requestL2Transaction関数にパラメータを1つずつ入力することで同じことが行われます。

強制インクルード機能はまだありません

シーケンサーにインクルードされるL2トランザクションの待ち時間は、L2トランザクションが優先キューに置かれた後に計算されますが、現在のzkSync設計には強制インクルード機能はありません。しかし、現在の zkSync デザインには、ユーザーが強制できる強制インクルード関数は存在しないため、中途半端な仕事にしかなりません。つまり、「インクルード待ち時間」はありますが、実際には「インクルードするかしないかはシーケンサー次第」です。シーケンサーは有効期限まで待つか、優先キューにそれ以上のトランザクションをインクルードすることはできません。

将来的には、zkSyncは、有効期限が切れたがSequeuncerによってまだインクルードされていないトランザクションを、ユーザーがL2トランザクション履歴に強制的にインクルードできるようにする機能を含むべきです。

まとめ

L1は、ネットワークを「安全」で「検閲に強い」状態に保つために、多数の検証者に依存しています。Rollupは数人、あるいは一人のシークエンサーによって書かれているので、検閲耐性はさらに低い。

ロールアップは、ユーザーがシーケンサーを迂回して取引を履歴に書き込むことを可能にするフォース・インクルージョン機構を必要とします。 シーケンサーが取引をレビューすることを防ぎ、ロールアップの資金の使用や引き出しを不可能にします。インクルージョンは、ユーザーが取引を強制的に履歴に入れることを可能にしますが、取引を即座に履歴に入れるかどうかを選択できるように設計されています。取引の即時反映を許可すると、L2で取り込みを待機している取引が、L1で強制的に取り込まれる取引によって影響を受ける可能性があるため、シーケンサーに悪影響を及ぼします。

そのため、現在の Rollup の強制取り込みメカニズムでは、L1 上に挿入されたトランザクションが最初に待機状態に入ることを許可し、Sequencer に、これらの待機中のトランザクションを取り込むかどうかを反応し選択する時間のウィンドウを与えます。

zkSyncとArbitrumの両方は、L1から送信されたL2トランザクションまたはユーザーによるL2へのメッセージを管理するキューをL1に維持します。OptimismがL2トランザクションを送信する方法は、どちらもL2アドレスからL1へメッセージを送信するという点で、Optimismと似ており、L2トランザクションに変換された後、L2トランザクションの発信元はそのL2アドレスになる。Arbitrumは完全なL2トランザクションを生成し、それに署名し、sendL2Message関数を通してそれを送信する。

StarkNetはまだForce Inclusionメカニズムを持っていません。zkSyncは中途半端なForce Inclusionを行い、PriorityQueueがあり、各QueueのL2トランザクションには包含期間があります。PriorityQueueがあり、各QueueにはL2トランザクションの有効期限がありますが、この有効期限は現時点では装飾的なものでしかなく、シーケンサーは実際にはPriorityQueueにL2トランザクションをまったく含めないことを選択できます