Lumoz、Etrogの大型アップグレードを完了
TechFlow厳選深潮セレクト
Lumoz、Etrogの大型アップグレードを完了
今回のアップデートにより、Polygon zkEVMとEthereumの互換性が向上し、ノードの実行および照会効率が大幅に最適化されました。また、Polygon CDKエコシステムの可能性も広がりました。
Web3業界の深掘り報道に専念し潮流を洞察
Etrog アップグレードの概要
Polygon CDK エコシステムの重要な構成要素として、LumozはこれまでPolygon CDKの各アップグレードに注目し、調査・開発・最適化を繰り返してきました。また、一般ユーザーにも理解しやすい形でアップグレードの詳細を解説することで、CDK Validium初期バージョンからEtrogバージョンへのアップグレード経路を体系的に整理・補完し、Polygon CDKひいてはブロックチェーン業界全体の発展の可能性を広げることを目指しています。
Polygon zkEVMのEtrogアップグレードは2024年2月に完了しました。これはPolygon zkEVMがメインネットにリリースされて以来、最も重要なアップグレードであり、低レベル回路において複数のプリコンパイル契約をサポートするとともに、チェーン自体のトランザクションバンドル化やブロック生成メカニズムの最適化を行い、さらにスマートコントラクトアーキテクチャ全体を再構築しました。これにより、今後のPolygon CDKエコシステムやAggLayer、Unified Bridgeといった新機能の基盤が整いました。全体として、このアップデートはPolygon zkEVMとEthereumとの互換性を高め、ノードの実行および照会効率を大幅に向上させるとともに、Polygon CDKエコシステムの可能性を大きく広げました。
本稿では、Polygon zkEVMのコントラクトおよびノードコードの視点から今回のアップグレードの技術的詳細を深く分析するとともに、オープンソースのRollupアップグレードスキームに基づき、CDK Validium初期バージョンからEtrogバージョンへのアップグレードパスを体系的に整理・補完します。
コントラクトの再構築
Etrogアップグレード以前、Polygon zkEVMのコントラクトは主にコンセンサスコントラクトとブリッジコントラクトの二つの部分から構成されていました。
コンセンサスコントラクト
コンセンサスコントラクトは、チェーンIDやバージョンなどの基本情報に加え、batchや証明提出記録など、レイヤー2チェーンのリアルタイム状態情報を記録します。またValidiumの場合、batch内の元のトランザクションデータはコンセンサスコントラクト内に記録されず、代わりに外部のcommitteeコントラクトを通じて、チェーン外のDA（データ可用性）ノードグループ内で保存されます。これらの基本情報とリアルタイム状態情報を組み合わせることで、誰でも完全にレイヤー2チェーンの状態を復元することが可能です。
ブリッジコントラクト
一方、ブリッジコントラクトは一連のエグジットルート状態を管理し、レイヤー1とレイヤー2間のすべてのクロスチェーン状態を記録し、Lock/Mint方式によって両レイヤー間の資産移動を実現します。エグジットルートの子ノードはブリッジコントラクトとコンセンサスコントラクトの両方によって更新され、前者はレイヤー1からレイヤー2へのdepositトランザクション状態を管理し、後者はZK証明の提出を通じてレイヤー2からレイヤー1へのwithdraw状態を管理します。
Etrogアップグレードによるコントラクト層での最大の変更点は、複数のネットワークを管理できる多ネットワーク方式を導入したことであり、従来の単一レイヤー2ネットワークの管理から、複数ネットワークの管理を可能にしました。さらに新たに導入されたUnified Bridgeによって、これらのレイヤー2ネットワーク間の資産相互運用性が確保され、エコシステム全体の将来の発展のためのより堅固な基盤が提供されました。
もともとのコントラクト構造では多ネットワークの展開をサポートしていなかったため、Etrogアップグレードでは全体のコントラクト構造が再設計されました：
-
すべてのレイヤー2ネットワーク情報を管理するRollupManagerコントラクトを導入；
-
ブリッジコントラクトおよびGlobalExitRootの構造を変更し、すべてのネットワークのクロスチェーン状態を維持できるようにして、異なるレイヤー2ネットワーク間の資産相互運用性を保証。
Etrogバージョン未満のPolygon zkEVMレイヤー2ネットワークを運営している場合、これらの変更はコントラクトデータに対して大きな破壊的影響を及ぼすため、対応するアップグレード計画は少なからぬ課題となります。以下では、引き続きコンセンサスコントラクトとブリッジコントラクトの二つに分けて、アップグレードスキームの具体的な詳細を詳しく説明します。
コンセンサスコントラクト
Etrogアップグレードにおけるコンセンサスコントラクトの最大の変更点は、全く新しいRollupManagerコントラクトの導入です。新版では権限管理などの多くのコントラクト操作が新しく導入されたRollupManagerコントラクトに集中しているため、Polygon公式のアップグレード計画では、既存のPolygon zkEVMプロキシの実装をRollupManagerコントラクトに更新し、新しくデプロイされたサブネットワークコントラクトPolygonZkEVMExistentEtrogを元のネットワークの新しいコンセンサスコントラクトとします。そして、新規RollupManagerコントラクトの初期化呼び出し時にRollupネットワークのグローバル情報を書き込みます。このPolygonZkEVMExistentEtrogは、通常のEtrogアップグレード後のレイヤー2ネットワークコントラクトPolygonZkEVMEtrogに比べ、アップグレード時の移行ロジック用にinitializeUpgradeメソッドを追加実装しています。
アップグレード後にプロキシコントラクトの変数スロットが一致するよう保証するため、RollupManagerは旧バージョンの変数を格納する専用のLegacyZKEVMStateVariablesコントラクトを継承しています。また、アップグレード前後でbatch状態が一致するよう保証するため、RollupManagerは初期化時に一連の操作を行い、履歴データを新しいコントラクトに再代入するとともに、アップグレード後のルールに従ってレイヤー1上に強制batch（forcedBatch）を生成し、これをEtrogアップグレードの移行用batchとしてノードが処理できるようにしています。
ブリッジコントラクト
Etrogアップグレードにより、ブリッジコントラクトにはカスタムガストークン機能が追加され、globalExitRootの生成方式も変更されました。これにより、既存データの一貫性を保ちつつ複数のレイヤー2チェーンのエグジットルート更新を可能にし、複数レイヤー2間の資産相互運用性を実現しています。
ノードの更新
ノードに関しては、Etrogアップグレードによりsequencerおよびsynchronizerモジュールが主に更新されるとともに、コントラクトABIも更新され、新バージョンのコントラクトと相互作用できるようになりました。
sequencerモジュール
-
今回のアップグレードでは、ブロックおよびbatchのバンドル化ロジックが変更されました。Etrog以前は、各レイヤー2ブロックには1件のトランザクションしか含まれておらず、ブロック時間とそのブロックが属するbatchの時間は一致していました。この設計はイーサリアムの方式とは大きく異なり、チェーン上のアプリケーションにとって、ブロックをたどってトランザクションを処理する一般的なロジックとの互換性が非常に低かったのです。そのためEtrogアップグレード後、レイヤー2ブロックのバンドル化ロジックは全面的に調整され、固定時間でブロック生成を行う方式に変更され、単一ブロックが複数のトランザクションを含めるようになりました。これにより、過去バージョンの互換性問題が改善されました。
-
synchronizerモジュール
Etrogにおける変更は二つに分けられます。第一に、新バージョンコントラクトのイベントおよび対応処理ロジックへの対応です。これには、移行用batchの処理方法、新しいbatch/証明提出イベントおよびinfo_tree更新イベントの処理などが含まれます。第二に、同期ロジック全体の再構築です。Etrog以前のバージョンでは、同期ロジックは全体的に逐次処理でした。permissionlessノードの場合、レイヤー1のデータがbatch順に完全に同期されるまで待機し、その後にプライベートノードから提出待ちのデータを同期していました。これにより、常にこれらのノードとプライベートノードの間に遅延が生じていました。Etrogアップグレードではこのロジックを完全に再構築し、レイヤー1およびレイヤー2の同期タスクをそれぞれ独立したスレッドで管理するように変更しました。これにより前述の遅延問題が解決されるとともに、レイヤー1データの同期効率も向上しました。
LumozによるCDK Validiumのアップグレード
通常のzkEVMネットワークは公式リポジトリのオープンソースコードを使用してアップグレード手順を完全に実行できますが、公式はValidiumのアップグレードスキームをサポートしていません。Lumozチームは調査および開発を経てValidiumのアップグレードスキームを完成させ、CDK Validiumに基づく複数のテストネットおよびMerlinメインネットのアップグレードに成功しました。本セクションでは、Validium特有のアップグレードパスについて紹介します。
コード実装
コントラクト面
Validiumのアップグレードスキームは基本的に公式Rollupの変更を参考にしており、Validiumコンセンサスコントラクト用のPolygonValidiumExistentEtrogコントラクトを実装します。このコントラクトはオリジナルのCDKValidiumコントラクトに基づき、zkEVMExistentEtrogと同様にinitializeUpgradeメソッドを実装しており、アップグレードトランザクションの実行中に履歴データを継承し、ノードが処理するためのアップグレード用batchを生成します。zkEVMとの違いは、新版CDK ValidiumのDataCommitteeアドレスが新しくデプロイされたPolygonValidiumExistentEtrogコントラクトによって管理されることです。そのためアップグレード手順中、元のCDKDataCommitteeアドレスをdataAvailabilityProtocol変数に再設定する必要があります。
ノード面
公式の新版ValidiumノードコードにはupdateEtrogSequenceイベントの処理ロジックが実装されていないため、直接使用することはできません。ただし、ここでもRollupの処理フローを参考にして実装することが可能です。また、コード内で依存しているコントラクトABIも修正し、Validiumのコントラクトインターフェースに適合させ、従来のRollupコントラクトインターフェースを置き換える必要があります。
注意点として、Etrogをスキップして直接Eldberryバージョン以上にアップグレードする場合、batchデータの処理方式が異なるため、ノード側でいくつかの追加修正が必要です。コントラクトアップグレード中にレイヤー1で生成される移行用forcedBatchは依然としてEtrogバージョンの方式で生成されるため、ノードがこのbatchを処理する際にはデフォルトのEldberryプロセッサではなく、再度Etrogバージョンのプロセッサを使用しなければならず、そうでなければ互換性のない問題が発生します。
アップグレード手順
アップグレード前に、レイヤー1およびレイヤー2ネットワーク上に、RollupManager、ValidiumExistentEtrog、GlobalExitRootV2、BridgeV2などすべての新バージョンコントラクトを事前にデプロイしておく必要があります。具体的には公式アップグレードスクリプトを参照し、zkEVM関連コントラクトをValidium関連コントラクトに置き換えればよいです。関連コントラクトのデプロイが完了したら、CDKValidiumのProxyのアップグレード用トランザクションデータをあらかじめ生成し、新しく実装されたinitializeメソッドを呼び出して上記のデータ再代入および移行用batchの生成などの操作を完了します。その後、Timelockコントラクトの関連権限アドレスがscheduleメソッドを呼び出してアップグレードトランザクションを予約し、Timelockコントラクトのロック期間を待機します。レイヤー1での操作と同様に、レイヤー2でもブリッジコントラクトのアップグレード用トランザクションデータを事前に生成し、レイヤー2のTimelockコントラクト内でアップグレードトランザクションを予約します。
RollupManagerのinitializeロジックでは、Proofが最新まで提出されていることを確認する必要があり、これによりアップグレード前後のbatchの実行および証明が同一バージョン下で行われることが保証されます。そのため、ロック期間に到達した後でも信頼できるノードに対していくつかの調整が必要です。アップグレード中の停止時間を最小限に抑えるために、sequencerサービス内のStopSequencerOnBatchNumパラメータを事前に設定し、指定されたbatch番号に達した後にトランザクションのバンドル化を停止させることで、batchおよび対応する証明の提出に十分な時間を確保できます。一方、新旧版Validiumはpool_dbのmigrationファイルに変更があるため、データベース内の「supernets-0001.sql」に関連するレコードを手動またはノードコード内で処理し、新バージョンノードのデータベース構造と一致させる必要があります。
Proofが最新まで提出され、データベースの整理が完了した後、レイヤー1のTimelockコントラクトの関連権限アドレスがexecuteメソッドを呼び出して事前に予約したアップグレード操作を実行し、すべての設定ファイルを更新するとともに、信頼できるノードのすべてのサービスバージョンも更新します。信頼できるノードがサービスを再開し、再びトランザクションのバンドル化を開始した後、すべてのpermissionlessノードも設定ファイルを更新し、新バージョンのコードを使用してサービスを再起動する必要があります。また、レイヤー2のアップグレード操作もTimelockが設定した時間が到来した後にexecuteメソッドを実行し、レイヤー2ブリッジコントラクトのアップグレードを完了します。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@LumozOrg
