Etrog 升級概覽

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 、證明提交記錄等二層鏈的實時狀態信息。另外，對於 Validium 而言，batch 內的原始交易數據不會記錄在共識合約內，而是通過一個額外的 committee 合約在鏈下的 DA 節點組內保存。通過結合這些基本信息和實時狀態信息，任意一個人都能完整恢復一份二層鏈的狀態。

橋合約

另一方面，橋合約則使用一組退出根狀態管理、記錄所有一層和二層之間的跨鏈狀態，並通過 Lock/Mint 的模式完成一二層之間的資產流動。退出根的子節點由橋合約和共識合約同時更新，前者維護一層到二層的 deposit 交易狀態，後者通過 ZK 證明的提交維護二層到一層到 withdraw 狀態。

Etrog 升級在合約層面上帶來的最大改動是引入了一套多網絡方案，使用一套合約支持多個，而非原來的單個二層網絡的管理和維護，同時依靠新引入的 Unified Bridge 打通這些二層網絡之間的資產互操作性，爲整體生態的未來發展提供了更好的基礎。

由於原本的合約結構並不支持多網絡的部署，Etrog 升級對整體合約結構都進行了重構

  1. 引入了 RollupManger 合約管理所有二層網絡信息；

  2. 修改了橋合約和 GlobalExitRoot 的結構，使其能夠維護所有網絡的跨鏈狀態，以保證不同二層網絡間的資產互操作。

詳細合約結構可參考

對於運行在 Etrog 版本以下的 Polygon zkEVM 二層網絡而言，這些修改對合約數據具有很強的破壞性，因此對應的升級方案是一個不小的挑戰。這裏我們依舊從共識合約和橋合約兩部分分別詳細介紹升級方案背後的具體細節。

共識合約

Etrog 升級在共識合約部分最大的改動就是引入了一個全新的 RollupManager 合約。由於新版本中大部分的權限管理等合約操作集中在新引入的 RollupManager 合約內，因此在 Polygon 官方的升級方案中，會將原有的 Polygon zkEVM 代理的實現更新爲 RollupManager 合約，同時將一個新部署的子網絡合約 PolygonZkEVMExistentEtrog 作爲原網絡的新共識合約，並在新 RollupManger 合約的初始化調用時寫入 Rollup 網絡的全局信息。該 PolygonZkEVMExistentEtrog 相比於 Etrog 升級後通常的二層網絡合約 PolygonZkEVMEtrog 多實現了一個 initializeUpgrade 方法，用於升級過程中的過渡邏輯。

爲了保證升級後代理合約變量的 slot 一致，RollupManager 繼承了一個專門用於存放舊版變量的 LegacyZKEVMStateVariables 合約。另一方面，爲了保證升級前後 batch 狀態的一致，RollupManager 也在初始化的時候進行了一系列操作，將歷史數據重新賦值到新的合約中，並按照升級後的規則在一層產生了一個 forcedBatch 作爲 Etrog 升級的過渡 batch，供節點處理。

橋合約

Etrog 升級給橋合約提供了自定義 gas token 的功能，同時也修改了 globalExitRoot 的生成方案，保證原有數據一致的情況下兼容多個二層鏈的退出根的更新，以實現多二層間的資產互操作。

節點更新

在節點方面，Etrog 升級主要更新了 sequencer、synchronizer 兩個模塊，同時也更新了合約 abi，用於和新版本的合約進行交互。

sequencer 模塊

  1. 此次升級修改了區塊與 batch 的打包邏輯。在 Etrog 之前，每個二層的區塊都只包含一筆交易，且區塊時間和區塊所在的 batch 時間是一致的。這樣的設計與以太坊的模式差別較大，對於鏈上應用而言，常用的依照區塊遍歷交易的邏輯非常不兼容。因此在 Etrog 升級後，整個二層區塊的打包邏輯都進行了調整，改爲了固定時間出塊，且單個區塊能夠包含多筆交易，改善了歷史版本中的不兼容問題。

  2. synchronizer 模塊

Etrog 的改動則分爲兩塊。首先是適配新版合約的事件及相應處理邏輯，包括如何處理過渡 batch，如何處理新的 batch/proof 提交事件及 info_tree 更新事件等。另一部分則是對整體的同步邏輯做了重構。在 Etrog 前的版本，同步邏輯整體是串行的。對於 permissionless 的節點而言，需要等待一層數據按照 batch 順序完全同步完成後纔會繼續從主節點同步待提交的數據。這使得這些節點和主節點的數據之間總是會存在一個延遲。Etrog 升級將這部分邏輯完全進行了重構，將一層、二層的同步任務拆分到了各自的線程之中進行管理，在解決上述延遲問題的同時，也加快了一層數據的同步效率。

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，使其適配 Valdium 的合約接口，替代原有的 Rollup 合約接口。

注意，如果選擇跳過 Etrog，直接升級到 Eldberry 版本以上，由於 batch 數據的處理方式不同，節點需要進行一些額外的修改。在合約升級的過程中，一層產生的過渡 forcedBatch 仍是以 Etrog 版本的方式生成的，節點在處理該 batch 時不能使用默認的 Eldberry 的處理器，而是需要重新使用 Etrog 版本的處理器，否則會產生不兼容問題。

升級流程

在升級前，需要預先在一層和二層網絡上分別部署好所有新版本的合約，包括 RollupManager、ValidiumExistentEtrog、GlobalExitRootV2、BridgeV2 等。具體可參照官方升級腳本，將 zkEVM 相關合約替換爲 Validium 相關合約即可。相關合約部署完成後，即可預生成一層上升級 CDKValidium 的 Proxy 的交易數據，調用新實現的 initialize 方法完成上述的數據重新賦值及過渡 batch 的生成等操作。之後由 Timelock 合約的相關權限地址調用 schdule 方法預約升級交易，並等待 timelock 合約的鎖定時間。類似於一層上的操作，在二層上也需要預生成橋合約的升級交易數據，在二層的 Timelock 合約中預約升級交易。

由於 RollupManager 的 initialize 邏輯中需要檢查 Proof 是否提交到最新，以保證升級前後 batch 的執行和證明在同一版本下，因此在到達鎖定時間之後，仍需要對可信節點做一些調整。爲了儘量減少升級中的停機時間，可以提前預設好 sequencer 服務中的 StopSequencerOnBatchNum 參數，使其在到達該 batch 後停止交易的打包，以留足時間給 batch 和對應證明的提交。另一方面，由於新舊版 Validium 在 pool_db 的 migration 文件上有所修改，需要手動、或在節點代碼中將數據庫內 'supernets-0001.sql' 的相關記錄處理掉，以對齊新版本節點的數據庫結構。

在 Proof 提交到最新，且數據庫整理完畢後，即可使用一層 Timelock 合約的相關權限地址調用 execute 方法執行之前預約的升級操作，更新所有配置文件，並同時更新可信節點的所有服務版本。在可信節點恢復服務，並重新開始打包交易後，所有 permissionless 節點也需要更新配置文件，並用使用新版本代碼重啓服務。而二層的升級操作也可以在到達 Timelock 所設置的時間後執行 execute 方法，完成二層橋合約的升級。

作爲Polygon CDK 生態內的重要組成部分，Lumoz一直關注Polygon CDK的每一次升級，展開多次調研、開發和優化，並以通俗易懂的方式向公衆解讀升級背後的細節，希望能全面梳理並補全 CDK Validium 早期版本向 Etrog 版本的升級路徑，從而有效拓寬 Polygon CDK 乃至整個區塊鏈行業發展的邊界。

#MATIC