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 升级对整体合约结构都进行了重构
引入了 RollupManger 合约管理所有二层网络信息；
修改了桥合约和 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 模块
此次升级修改了区块与 batch 的打包逻辑。在 Etrog 之前，每个二层的区块都只包含一笔交易，且区块时间和区块所在的 batch 时间是一致的。这样的设计与以太坊的模式差别较大，对于链上应用而言，常用的依照区块遍历交易的逻辑非常不兼容。因此在 Etrog 升级后，整个二层区块的打包逻辑都进行了调整，改为了固定时间出块，且单个区块能够包含多笔交易，改善了历史版本中的不兼容问题。
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 乃至整个区块链行业发展的边界。
