zkEVM シリーズ（2）：Polygon zkEVM の Sequence と Bridge に関するさらなる技術的詳細

著者: 0xhhh、EthStorage （Twitter:@hhh69251498)

polygon zkEVMに関する最初の記事では（zkEVMシリーズ（1）｜Polygon zkEVMの全体構造と取引実行プロセス）、Polygon zkEVMの全体構造と取引実行プロセスをまとめ、Polygon zkEVMが計算のスケーラビリティを実現しつつL1のセキュリティを継承する方法を分析しました；この記事では、前回の記事で構築したフレームワークに基づき、polygon zkEVMのSequencerとBridgeに関するさらなる技術的詳細を掘り下げ、将来の潜在的な分散型Sequencerアーキテクチャの異なる特徴についても探討します。

一、zkEVM Bridgeの詳細解析

前回の記事では、Polygon zkEVMの紹介の過程で、実際には非常に重要な部分が欠けていました。それはPolygon zkEVMのネイティブブリッジです。（注：この記事ではL2はRollupを特指し、L1はEthereumを特指します。）

1. クロスチェーンデータ状態管理

Polygon zkEVMはL1とL2それぞれにExit Treeを維持しており、それぞれL1 Exit Merkle treeとL2 Exit Merkle treeと呼ばれています。しかし、これら2つの木をより良く管理するために、Polygon zkEVMはこれら2つの木を賢く結合しました。以下の図のように:

つまり、L1 Exit Tree RootをGlobal Exit Treeの左葉ノードとして、L2 Exit Tree RootをGlobal Exit Treeの右葉ノードとして使用します。ただし、ここでL1 Tree RootとL2 Tree RootはSparse Merkle Tree（SMT）であり、Global Exit TreeはBinary Merkle Treeです。

L1/L2 Exit Treeの葉ノードの基本情報は以下の通りです:

2. クロスチェーンプロセス

Polygon zkEVMのコントラクト設計では、BridgeとConsensusコントラクトをできるだけ分離しています。現在、L1にデプロイされているコントラクトは主に3つに分かれています。以下の図のように:

注意が必要なのは、彼らの間に継承関係はなく、すべて独立したコントラクトであり、PolygonZkEVMBridgeとPolygonZkEVMはPolygonZkEVMGlobalExitRootを呼び出してGlobal Exit Tree Rootを更新または検証します。

1） L1 → L2のクロスチェーンプロセス

L1 → L2のクロスチェーンプロセスは、上図のオレンジ色で示された3つのステップに対応しています：

以下のコード中のBatchDataの構造体におけるglobalExitRootに対応しています:

PolygonZkEVMBridgeのL2コントラクト

https://testnet-zkevm.polygonscan.com/tx/0x2a742f2f8a7b8635a76cc70b4574bebb1a81b2c0c1a618188773a1f8f2283bb8

https://testnetzkevm.polygonscan.com/address/0x39e780d8800f7396e8b7530a8925b14025aedc77#code

2）L2 → L1のクロスチェーンプロセス

ユーザーはL2にデプロイされたBridgeコントラクト(PolygonZkEVMBridge.sol)のBridge()関数を呼び出してL2-Bridge-Txを送信します。これにより、L2 Exit Treeに新しいノードが追加され、その後L2 Exit Tree RootとGlobal Exit Tree Rootが順次更新されます。

次に、SequencerはこのL2-Bridge-TxをあるBatchに入れてL1のコンセンサスおよびDAコントラクト（PolygonZkEVM.sol）に送信します。

その後、AggregatorがtrustedVerifyBatches()を呼び出してL1にvalidity proofを提出する際、実際にはL2 Exit RootもInputとしてアップロードされます。これは以下の関数のNewLocalExitRootに相当し、L2に新しいBridgeToL1の取引があることを示していますが、これらの取引は現在L1で引き出すことができず、この新しいNewLocalExitRootが検証されるのを待つ必要があります。

次に、この入力されたNew Local ExitRootも検証回路の一部として使用され、この検証ロジックはL2で発生したこれらの新しいBridgeToL1の取引がL2Exit Tree Rootを現在提出されたNew Local ExitRootに変更するかどうかを確認します。

このValidity Proofが検証に合格すると、L1のGlobal Exit RootManagerはL2 Exit Tree RootとGlobal Exit Tree Rootを更新します： globalExitRootManager.updateExitRoot(newLocalExitRoot);

この時、ユーザーはL1にデプロイされたBridgeコントラクト（PolygonZkEVMBridge.sol）のClaimAsset()関数を呼び出し、対応するMerkle Pathを提供して引き出しを行うことができ、クロスチェーン取引が完璧に終了します。

二、Polygon zkEVMはどのように検閲に耐えるか

前回の記事では、Trusted Sequencerについて紹介しました。これは公式が運営するSingle Sequencerであり、基本的にL2ネットワークの取引はこのTrusted Sequencerに提出され、タイムリーなSequencer Finalityを得ることができます。

実際には、ユーザーは別の方法で直接取引をL1のコントラクトに提出することもでき、Trusted Sequencerを介さずに全体のネットワークが一定の検閲耐性を持つことを保証します。

1. 実行プロセス

1）ユーザーはL1コントラクトのForce Batch関数を呼び出し、この関数を通じてユーザーは自分が実行したいL2取引を直接L1のコントラクトに送信できます。

2）コントラクト内では、これらのTransactionsがBatchにパッケージ化され、コントラクト内のForce BatchesのMappingに記録されます。

3）Trusted SequenceはForce Batchesに新しいForce Batchがあることを検知すると、それをローカルノードに同期し、次回L1にBatchesを提出する際にこのForceBatchを含めます。

4）ただし、ここには特別な状況が存在します。Trusted Sequenceがダウンした場合や、意図的に特定のユーザーが提出したForce Batchを提出しない場合、5日後にユーザーは自分でL1コントラクトのSequenceForceBatches()関数を呼び出し、このForceBatchをL1コントラクトのSequenced Batchesに入れることができます。つまり、このForce BatchのRollup内での取引順序がL1コントラクトによって最終的に決定され、Trusted SequenceもこのForce Batchの取引順序を変更することはできません。（実際、すべてのRollupはこのような特性を持ち、検閲耐性を提供します。例えば、ArbitrumのSequence InboxやInboxなど）。

ただし、できるだけForce Batchの方法でRollupの取引を提出しないことをお勧めします。なぜなら、この方法でL1に自分の取引を提出する際に取引内容が露出してしまい、この時点では取引順序がまだ確認されていないからです（SequenceがForceBatchを同期し、Batch()を再度L1に提出するまで取引順序が真に確認されることはありません）。同時に、取引をキャンセルすることもできなくなり、この時点で非常に高い確率で先行取引される可能性があります。

これは本当に検閲に耐えることができるわけではありません。なぜなら、Force Batchの方法には先行取引のリスクがあるからです。ユーザーは本当にこの機能を使用するのでしょうか？

2. Sequencerの真の状態

上記から、SequenceはL1からForce Batchの取引をローカルノードに同期して実行することがわかります。したがって、Sequenceの真の状態は以下の図のようになります:

Bnはユーザーが直接Sequenceに提出した取引の実行結果を示します；

FBnはSequenceがForce Batchの取引を同期して実行した結果を示します。

https://zkevm.polygon.technology/

三、L2ネットワークに存在する3種類のFinality

次に、Polygonの全体構造を振り返り、今後の分散型Sequencerの考察のための基盤を整えます。私たちは以下に注目する必要があります。

SequencerとAggregatorにとって、彼らの状態はSyschronizerを通じてL1コントラクトから同期されており、彼らの間には直接の通信はありません。

1) 3種類のFinality

したがって、現在のネットワークには3種類の異なる程度のFinalityが存在すると考えられます。これをSequencer Finality、DA Finality、Verified Finalityと名付けます。

a. 第一のSequencer Finalityは、いくつかの文献でSoft Finalityとも呼ばれていますが、私はSequencer Finalityと呼ぶ方が適切だと思います。このFinalityは実際にはSingle Sequencerによる状態の約束です。

Sequencerはユーザーの取引を受け取った後、実行して得られた状態を提供します。これは最も安全でない状態ですが、現在の公式Single Sequencerのシナリオでは、安全性を保証しながら極めて優れたユーザー体験を提供できます。現在の単一SequencerのRollupネットワークでは、ほぼすべてのユーザーが即時確認の喜びを体験できます。しかし、Single Sequencerの最大のリスクはSequencerのダウンであり、これによりL2ネットワーク全体が基本的に麻痺する可能性があります。ただし、DA層はEthereum上にあるため、L2ネットワークのダウン前の状態を部分的に回復することができます。ただし、その部分はL1に送信されなかったL2取引は回復できません。

b. 第二のDA Finalityは、これらの取引がL1のDA層コントラクトに提出されたことを示し、この時点で取引の順序も確定しています。

Trusted SequencerはSequence Batchを呼び出して取引をL1に送信しており、この場合、取引はDA層に含まれています。Polygonの設計では、単一のTrusted Sequencerの理由により、L1コントラクトにDAのためにアップロードされた取引はすべて有効な取引であることが保証されます。私たちは、取引がTrusted SequencerによってL1コントラクトにアップロードされた時点で、この取引はRollupネットワークによって承認され、その後AggregatorがValidity Proofを提供することで、この取引が本当にRevertできないことを保証します（L1 Reorgを除く）。

c. 第三のVerified Finalityは、この取引がValidity Proofの検証を通過したことを指し、真のFinalityに属します。一部の文献ではこれをHard Finalityとも呼んでいます。

AggregatorがDA層にアップロードされた取引のバッチに対して提供したValidity Proofがコントラクトによって検証に合格した時点で、これらの取引はRevertできないと考えられます（L1 Reorgを除く）。前回の記事で述べたように、現在DA層に提出された取引がValidity Proofの検証を通過するまでの時間は30分であり、AggregatorはValidity Proofを提供することで十分なMatic報酬を得ることができます。

2) Aggregatorの状態同期のトレードオフ

ここで、Validity Proofを提供することが利益になると仮定すると、Aggregatorにとって最良の取引の同期方法は、L1のDA層コントラクトで同期するのではなく、直接Trusted Sequencerとrpcリンクを確立し、Trusted Sequencerから最新の取引を取得することです。これにより、Validity Proofの生成がより迅速になり、DAコントラクトから取引を取得するAggregatorよりも競争優位性が得られます。なぜなら、Validity Proofの提供は先着順であり、バッチの取引には単一の集約されたvalidity proofが必要であり、最初にValidity Proofを提出したAggregatorは対応する取引のMatic報酬を得ることができ、他のAggregatorが生成したValidity Proofは報酬を得ることができません。

ただし、現在実際にはPolygonはTrusted Sequencerと同様の役割を果たしており、Validity Proofの生成と提出の作業を処理するTrusted Aggregatorも存在します。https://zkevm.polygon.technology/

四、Sequencerの未来

次に、分散型Sequencerに関する考察を続けます。最初の質問は、なぜ分散型Sequencerが必要なのかということです。なぜなら、私たちはRollupがEthereumの計算能力を拡張しつつ、Ethereumのセキュリティと分散化の程度を継承することを望んでいるからです。しかし、現在のSingle Sequencerのソリューションは明らかにEthereumの分散化の目標を達成できません。分散型Sequencerの未来を描く前に、まずSequencerの作業を振り返りましょう。Polygon zkEVMを例にとると、現在Trusted Sequencerは取引の処理をFCFSに従って行い、先に到着した取引が先に処理され、並行Mempoolもプライベートであり、ユーザーの取引がMEVにさらされないようにしています。

一定量の取引が収集されると、それらをBatchにパッケージ化してL1コントラクトの対応するDAの位置にアップロードします。前回の記事でも述べたように、これらのSequencerがアップロードしたBatchは、実際には後のBatchが前のBatchのハッシュを含むことで取引の順序が確定しています。したがって、Sequencerの作業はL1 Proposerの作業に似ており、一連の取引を提案し、取引の順序を確認します。

私たちはPolygon zkEVMから分散型Sequencerの紹介を始めたので、まずPolygon zkEVMの分散型SequencerソリューションであるProof Of Efficiency（効率証明）を紹介します。

1. Proof-Of-Efficiency1) ソリューションの説明POEの設計では、誰でもSequencerになり、L1にRollup Blockを提出できるようにし、Rollupネットワークの取引の順序は取引がL1のRollup DAコントラクトに提出される順序に依存します。（Polygon zkEVMではBatchはBlockに相当します。）以下の図のように、ユーザーはどのSequencerに取引を送信するかを自由に選択でき、さらには自分自身がSequencerになることもできます。これらのSequencerは十分な取引を受け取った後、それらをBatchにパッケージ化し、L1に提出します。

これらのSequencerは利益の問題を考慮する必要があります:

Sequencerのコスト = L1ガスコスト + zkProof生成手数料

Sequencerの収入 = L2ガス手数料

したがって、Sequencerは少なくともどれだけの取引をBatchにまとめてL1に提出することが利益になるかを考慮する必要があります。しかし、Sequencerは別の問題、すなわちタイムリーさの問題も考慮する必要があります。もしSequencerの取引提出速度が遅すぎると、そのユーザーはより迅速な確認を提供する他のSequencerに流出する可能性があります。

2) ソリューションの実現可能性

まず、このソリューションが機能する核心的な理由は、PolygonのDA部分が状態の約束を行わず、取引の順序のみを確定していることです。状態の約束（Sequencerが取引実行後の新しい世界の状態を約束することですが、この状態はValidity ProofまたはFraud Proofによって検証されていない状態）はValidity Proofを提出する際にのみ提供されます。これがこのソリューションが実行可能である核心的な理由です。

実際、ArbitrumはDAコントラクトに取引を提出する際に状態の約束を行っていませんが、OptimismはDA層に取引を提出する際に状態の約束を持っています。したがって、理論的にはArbitrumもPOEを利用して分散型Sequencerを実現できますが、Optimismはそうではありません。

3) なぜ状態の約束を持つとPOEを利用できないのか？それは、複数のSequencerがほぼ同時にL1にBatchを提出する場合、実際にはどのSequencerもDAコントラクト上でL2の取引の順序がどうなるかを保証できないためです。したがって、状態の約束を持つと、Batch全体がValidity ProofまたはFraud Proofの検証に合格できない可能性が高くなります。

4) 無効取引をどのように処理するか？

無効取引とは、例えばアカウントのNonceが低すぎる、アカウントの残高がガス手数料を支払うのに不足している取引を指します。これらの取引はL1（Geth）ではブロックに含まれません。なぜなら、無効取引を含むブロックはすべて無効なブロックになり、バリデーターはそのようなブロックに投票せず、プロポーザーもそのようなブロックを提案しません。

現在のSingle Sequencerの状況では、L2ネットワークはこのような無効ブロックを識別する能力があり、L1 DAコントラクトにこのような取引を含めることを避けることができます。これにより、L1のブロックスペースの無駄を避けることができます。

しかし、POEを採用すると、Sequencerは実際にはこのような無効取引を識別する能力を失います。したがって、L1の取引検証による状態変更の過程でも、この状況を考慮する必要があり、Sequencerが無効取引を提出してもユーザーの手数料を得ることはできません。

5) Public Mempool（公共取引プール）？

POEを採用すると、これらの分散型Sequencerの間にPublic Mempoolが存在する場合、ユーザーの取引が異なるSequencerによって複数回提出されることになります。もちろん、最初に提出された取引のみが有効な取引であり、この取引のみがユーザーの手数料を得ることができます。

6) Sequencerが実行結果を予測できない理由

このようなPermissionless Sequencerのモデルでは、SequencerはユーザーにタイムリーなSequencer Finalityを提供できません。なぜなら、Sequencerが予測する最終的なオンチェーン取引の順序と実際の取引の順序には偏差が生じるからです。この偏差は、複数のSequencerがほぼ同時にL1のDAコントラクトに取引Batchを提出した場合に発生します。このような状況では、これらの取引Batchの実際の順序が予測順序と同じであることを保証するのは非常に難しいです。

したがって、Sequencerが自身の状態を同期する際には、L1のDAコントラクトから最新の提出された取引Batchを同期して実行し、最新の状態を取得します。他のSequencerから状態を同期するのではありません。

7) L2のMEVがL1に流出する

取引は誰でもSequencerになってRollupネットワークの取引を提出でき、取引Batchの取引は実際にはL1の通常の取引と変わらないため、実際にはMEV Boostの全プロセスを経ることになります。つまり、L2ネットワークのMEVはすべてMEV Boostモジュールに流出します。

8) Aggregatorの設計

POEの設計では、AggregatorもPermissionlessですが、Validity Proofは実際には正しい取引が1つあればよいので、最初に取引の正しいValidity Proofを提出したAggregatorのみが報酬を得ることができます。したがって、Aggregatorとしては、提出するValidity Proofの証明範囲、提出時間、およびValidity Proofを提出することで得られるMatic報酬との関係を天秤にかけ、最も競争力のある戦略を見つけ出す必要があります。

このような自由市場競争戦略を利用することで、取引に対応するValidity Proofの生成速度を最速にすることができるようです。

https://ethresear.ch/t/proof-of-efficiency-a-new-consensus-mechanism-for-zk-rollups/119888 )

8）まとめ

POEは完全にPermissionLessなネットワークをもたらし、全体のネットワークはダウンのリスクを持たない可能性がありますが、L1のDAコントラクトには無効取引（例えば同じNonceの取引）が含まれる可能性があり、MEVはすべてL1ネットワークによって取得され、DA FinalityとVerified Finalityのみを提供できます。

2. Based Rollup

Based Rollupは、RollupネットワークのSingle Sequencerの作業をEthereumのプロポーザーに委任することを期待しています。これにより、各プロポーザーがL1のブロックを提案する際に有効なRollupブロックを含める必要があります。

したがって、L1ネットワークのBlock Builderは、L2の取引を受け入れるためにRollupのフルノードを実行し、最大の価値を持つRollup Blockを構築する必要があります。

このようなソリューションの利点は、L1のセキュリティと分散化の程度を最大限に継承できることですが、Sequencer FinalityとVerified Finalityのみを提供でき、L2のMEVもすべてL1に流出し、Ethereumクライアントのコードを変更する必要があるため、L1のセキュリティに影響を与える可能性があります。

3. Shared Sequencing

Shared Rollupは、Based RollupがRollup Blockの構築と提出の作業をEthereumのプロポーザーに委任するのに対し、この作業をShared Sequencersの委員会に委任します。

3.1. 具体的なプロセスは以下の通りです:

a. 異なるRollupのユーザーは、Shared Sequencersが存在するネットワークに直接Rollupの取引を送信できます。
b. Shared Sequencersは内部でBFTコンセンサスを実行し、各ラウンドでSequencer Leaderを選出して取引を並べ替え、対応するRollup Blockを構築します。
c. その後、これらのRollup Blockを異なるRollupネットワークのL1上のDAコントラクトに提出します。
d. 異なるRollupネットワークは、L1のDAコントラクトを通じてネットワーク内の最新の取引を同期し、その後、Validity ProofまたはFraud Proofの検証プロセスに入ります。

3.2. Shared Sequencerアーキテクチャの潜在的な影響

1) 複数のRollupネットワークが1つのShared Sequencer Committeeを共有します。
2) 単一のRollupの観点から見ると、公式が運営するSingle SequencerをこのShared Sequencer Committeeに委任しただけです。
3) 各ラウンドでShared Sequencer CommitteeからSequencer Leaderが選出され、このShared Sequencersネットワークに接続されたRollup Blockの構築を担当し、これらのRollup Blockを順次EthereumのDAコントラクトに提出します。
a. 例えば、AがArbitrum上のUSDCをOptimismにクロスチェーンする必要がある場合、通常のプロセスでは、まずArbitrumでLockを行い、Lockが成功した後にOptimismでArbitrumのLock Proof（例：Merkle Tree Path + Tree Root）を提出し、Optimismで対応するUSDC資産をMintします。
b. ユーザーがShared Sequencersにこのような取引を提出すると、各ラウンドのSequencer Leaderは実際にArbitrum Lockの操作とOptimism Mintの操作を同時にRollup Blockで実行できます。これにより、ユーザー体験が大幅に向上します。
c. しかし、同じRollupネットワークのユーザー体験のようにはできません。例えばMint時には、依然としてLock Proofを提供する必要があります。
d. したがって、Shared Sequencersネットワークに接続されたRollupは、ほぼ完全に同期したシステムであると考えられます。
e. ほぼ完全に同期したシステムにはどのような利点があるのでしょうか？
f. 原子的なクロスチェーンサービスを提供できます。なぜなら、各ラウンドで選出されたSequencer Leaderは、すべてのRollup取引を並べ替える権限を持っているため、原子的なクロスチェーン取引を構築する能力があります。

4) クロスチェーンMEVの観点から

各ラウンドのLeader SequencerはすべてのRollup Blockの並べ替え権限を持っているため、理論的にはすべてのクロスチェーンMEVを捕獲できます。したがって、Shared SequencerはMEV BoostのようなMEVアーキテクチャを導入または直接接続する必要があると感じます。なぜなら、現在、各Rollupネットワークのブロック間隔はEthereumのブロック間隔よりもはるかに速いからです。例えば、Optimismは2秒ごとにブロックを生成し、Arbitrumは最速で0.25秒ごとにブロックを生成します。したがって、各ラウンドのSequencer LeaderがRollup Blockを構築する計算量は実際には少なくありません。したがって、エコシステムが成熟すると、最大の価値を持つRollup Blockを構築するための相応のMEVアーキテクチャが必要になると感じます。

5) 分散化と生存性の観点からShared Sequencersを見ると

Shared Sequencer Committeeは内部でBFTコンセンサスを使用して、各ラウンドでSequencer Leaderを選出し、すべてのRollup Blockを提案するため、分散化と生存性は現在のSingle Sequencerソリューションよりもはるかに強力です。

6) エコシステムの観点から

a. 異なるRollupは、より良い共存の理由を持ち、ユーザーはさまざまなRollupネットワーク間で資産を簡単に移動でき、Ethereumエコシステムの負荷バランスを実現できます。
b. 異なるShared Sequencerを構築しているプロジェクトにとっては、死活的な競争となる可能性があります。なぜなら、ユーザーの観点と現在の各RollupがSingle Sequencerである観点から見ると、Shared Sequencerの分野では勝者総取りの問題が発生する可能性があるからです。

7) Finalityの観点から

本質的には依然としてSingle Sequencerであるため、Sequencer FinalityとVerified Finalityは元のままとなります。

3.3. 潜在的リスク

Rollup間は必ずしも同型Rollupではないため、例えばArbitrumとpolygon zkEVM間のクロスチェーンでは、Arbitrumとpolygon zkEVMの取引に対するVerified Finalityが一致しないことを意味します。例えば、Polygon zkEVM上のmint取引がVerified Finalityを取得した（Validity Proofを提出した）場合、同時にArbitrum上のLock取引はDA Finalityしか取得していない（7日間のチャレンジ期間を待つ必要がある）ため、この時点でArbitrumの取引を成功裏にRevertした場合、Polygon zkEVM上で無コストで多くのクロスチェーン資産をMintしたことになります。

3.4 まとめ

利点:

a. MEVはRollupネットワークによって取得され、さらに多くのクロスチェーンMEVを取得できます。
b. ユーザーのクロスRollup体験が向上し、Rollup間の競争関係が共生関係に変わります。各Rollupは独自の価値を提供し、他のRollupネットワークと組み合わせてユーザーにさまざまなカスタマイズされたサービスを提供するネットワークを形成します。
c. Single Sequencerに比べてネットワークの分散化の程度が大幅に向上し、ネットワークの安定性が大幅に向上します。特定のSequencer Leaderがブロックを生成しない場合、迅速に新しいSequencer Leaderに切り替えてブロックを生成します。
d. ネットワークの3種類のFinalityは元のSingle Sequencerと一致しています。劣位: 本質的には依然としてSingle Sequencerのモデルであり、新しい攻撃ベクトルを導入しています。

五、まとめ

この記事では、Polygon zkEVMのブリッジとSequencerに関するさらなる技術的詳細を詳しく構造化しました。次回の記事は最後の記事となり、zkEVMの技術的詳細をさらに解剖しますので、ぜひご期待ください。