Polygon zkEVM协议治理、升级及其流程
1. 引言
随着Polygon社区开发者和内部团队的测试深入，当前版本的Polygon zkEVM不可避免地需更新和某些升级。
为激励开发者对Polygon zkEVM做battle-test，已启动了bug-bounty：
- Rewards by Threat Level
由于zk-Rollup生态系统还处于萌芽阶段，预计升级频率会随着时间的推移而下降。与此同时，Polygon打算将其升级管理从目前的集中化方式转变为更加分散的工作方式。
Polygon致力于与以太坊关于L2治理的规范和价值观保持一致。正如Polygon的三大治理支柱中所概述的那样，这些治理的逐步变化将遵循Polygon改进提案（PIP）。具体的三根治理支柱是指：
- The First Pillar: Protocol Governance
- The Second Pillar: System Smart Contracts Governance
- 第三根治理支柱：Public Goods Funding
当前，中心化体现在：
- Admin Multisig Contract
- Security Council Multisig
以用户利益优先原则：
- 首先，zkEVM团队致力于保护系统的安全，以保护用户的资金。因此，任何感知到的对安全的威胁，无论大小，都需要被扼杀在萌芽状态。
- 其次，大多数升级通常包括优化、错误修复或更准确的有效gas定价公式。从而意味着总体上公平且交易成本更低。
2. 部署battle-tested合约
为支持未来zkEVM协议的新特性添加、bug修复或优化升级，以Transparent Upgradeable Proxy (TUP) 方式部署了如下合约：
- PolygonZkEVM.sol（共识合约）
- PolygonZkEVMGlobalExitRoot.sol
- PolygonZkEVMBridge.sol（bridge合约）
为了继承安全性，避免延长和使审计过程更加复杂，Polygon zkEVM团队选择使用OpenZeppelin的OpenZeppelin-upgrades库来实现此功能。
选择OpenZeppelin库的原因在于：
- OpenZeppelin是业内知名品牌，因其对以太坊标准的实现进行了审计和开源，其OpenZeppelin-upgrades库已经过审计和战斗测试。
- 此外，OpenZeppelin-upgrades不仅仅是一套合约，其还包括Hardhat和Truffle插件，以帮助进行代理部署、升级和管理员权限管理。
如下图所示，Open Zeppelin的TUP方式，使用delegated calls，隔离了协议实现的storage variables和fallback函数，支持对实现代码升级，而不需要修改storage状态或合约的公开地址。
根据OpenZeppelin的建议，部署了一个ProxyAdmin.sol的合约实例，其地址设置为proxy合约的admin。ProxyAdmin.sol也在openzeppelin-upgrades库中。Hardhat和Truffle插件使这些操作既安全又简单。
每个ProxyAdmin.sol实例都充当每个proxy的实际管理接口，管理帐户是每个ProxyAAdmin.sol实例的owner。
当zkEVM协议启动之后，ProxyAdmin.sol的所有权就转移给Admin role（管理员角色）。
3. Polygon zkEVM升级流程
为了保护仍处于测试版的Polygon zkEVM的安全，最好现在就抓住并防止任何可能的漏洞。
可升级性不是Polygon zkEVM的永久功能，而只是所谓Training Wheels的一部分。
升级通常会影响如下合约：
- PolygonZkEVM.sol（共识合约）
- PolygonZkEVMGlobalExitRoot.sol
- PolygonZkEVMBridge.sol（bridge合约）
经典升级是仅影响逻辑，而不影响网络状态。如，影响共识合约的升级，可将老的verifier合约更新为新的。此时，从更新开始，逻辑改变，状态保持不变。
3.1 安全参数
zkEVM团队为升级所采取的安全措施与以太坊的安全标准相当，涉及：
- Admin Multisig合约：避免单一账户控制升级。
- Timelock合约：在升级执行之前，给用户足够的时间延迟来取回资金。
- Transparent Upgradeable Proxy合约：源自OpenZeppelin库，已审计并经battle-tested。
3.2 升级流程
根据需要，在仍然允许升级的情况下，可提出升级提案。
在将提案发送到Timelock合约之前，该提案需要由三分之二的合格签署人通过Admin Multisig合同进行签署。
一旦满足Admin multisig合约的条件，包括至少附上两个签名，就可以使用Timelock合约schedule proposed升级。
zkEVM升级的时间延迟设置为10天，之后Admin会触发Timelock合约来执行升级。这意味着升级将作为正常交易提交给L1。
与Transparent Upgradeable Proxies一致，这确保了zkEVM的状态在逻辑更改时保持不变。
仍以之前的共识合约升级为例，下图展示了相应的Polygon zkEVM升级流程:
4. Admin Role及治理
Polygon zkEVM的Admin，包含了Polygon团队的3位开发者，这3位开发者会监督该zk-Rollup软件的任何升级。
无论做何种bug修复或更新，该Admin使用特殊的Admin Multisig合约来approve该修改——需要这3个Admin成员中的至少2个同意才行。在该修改执行之前，至少需要10天的等待期。10天的延迟，使得用户可仔细评估所提议的修改，并决定是否退出。名为Timelock的合约负责激活该10天延迟。
4.1 Admin合约详情
Admin拥有控制共识合约的以太坊账号，仅该账号可调用如下函数：
- setTrustedSequencer
- setForceBatchAllowed
- setTrustedSequencerURL
- setTrustedAggregator
- setTrustedAggregatorTimeout
- setPendingStateTimeout
- setMultiplierBatchFee
- setVeryBatchTimeTarget
- setAdmin
- deactivateEmergencyState
可更新zkEVM协议合约实现的，所有ProxyAdmin.sol实例，都属于该Admin账号。
此外，所有代理都归该Admin账号所有，使得其为唯一授权的账号——可对zkEVM协议合约做修改。而Security Council Multisig不具备该权限。
4.2 Timelock Controller
所谓Timelock Controller：
- 是一个智能合约，支持设置delay，在应用潜在风险的维护流程之前，给用户提供一定的时间来退出。
为改进用户安全性和信心，Timelock Controller已添加到zkEVM协议。
该Admin可使用Timelock Controller来schedule和commit L1中的维护操作交易，当特定的minDelay时长结束之后，会激活该timelock以执行这些维护操作交易。
Polygon zkEVM团队决定使用OpenZeppelin的TimelockController.sol合约来继承安全性，同时避免审计流程的延长和复杂化。已修改了合约中的getMinDelay函数，该修改见PolygonZkEVMTimelock.sol合约中。
当zkEVM合约系统处于紧急模式时，新的getMinDelay函数将设置minDelay时长为0，此时由Security Council Multisig接管。
在zk-Rollup部署之后，本协议的Admin role设置为PolygonZkEVMTimelock.sol合约地址的一个实例。
4.3 zkEVM合约治理
Admin承担着重要而关键的责任，这就是为什么它由三（3）名成员组成，而不是只有一个人。因此，PolygonZkEVMTimelock.sol合约实例的Admin Ethereum帐户被分配给某multisig合约作为zkEVM协议治理工具，从而实现一定程度的整体去中心化。
Polygon zkEVM L1合约的治理tree为：
仅当遵循如下流程时，才可执行协议维护操作：【由于协议合约的治理链，所有交易通常遵循如下流程】
- 1）维护操作交易被proposed并存储在governance multisig合约中。Polygon团队对此达成共识——是否应用这些维护操作。Voting继承自L1的安全性。
- 2）一旦达成某种决议，且同意执行这些维护操作，将触发governance multisig来将这些交易scheduled to be executed，仅当10天延迟结束后，才会执行这些交易。
- 3）一旦延迟时长结束，名为PolygonZkEVMTimelock.sol的Timelock合约将执行这些scheduled交易。
5. Security Council
除之前提及的治理问题和安全考量之外，对于像Polygon zkEVM这样的年轻L2系统来说，还有一个重要元素：
- Security Council Multisig
由于可能存在严重的bug或其它安全问题，因此需要立即升级，因此允许紧急升级是一种良好的安全做法。
也就是说，这些合约不是采用三选二的Admin Multisig合约并等待Timelock合约施加的延迟，而是通过部署所谓的Security Council Multisig来绕过这些合约。
然而，至关重要的是要强调，Security Council Multisig是一项临时措施，一旦Polygon zkEVM经过充分的战斗测试，它最终将被淘汰。
尽管最终目标是朝着完全去中心化的Polygon zkEVM迈进，但在zkRollup的早期阶段，使用Security Council Multisig是不可避免的。
这是安全和权力下放之间的权衡。因此，为了长期安全起见，这是一个深思熟虑的决定，即在早期阶段进行更集中的开发，以实现更分散的后期阶段。
尽管安全理事会成员总是有可能耍无赖和勾结，但75%的门槛加上至少33%的外部成员签名大大降低了风险。
5.1 了解Security Council Multisig
Security Council为负责监督Polygon zkEVM初始化阶段安全性的委员会。
rollup的security council具有双重责任：
- 确保系统在紧急状态下及时停止，以及
- 确保在实际可行的情况下尽快实施紧急升级。
因此，security council使用了一种特殊的multisig合约，该合约取代了通常的Admin Multisig合约和Timelock合约。
5.2 Security Council成员组成
Security Council通常由一定数量的有生物的社区成员组成，这些个体或公共公司代表可保持匿名。
这些人是对以太坊生态系统的福利有既得利益的个人或组织，通常是从知名的以太坊开发者和研究人员中挑选出来的。
Polygon zkEVM的安全理事会由八（8）名成员组成，其中四名成员是Polygon团队内部成员，而其他成员必须来自Polygon外部。
最低要求，即使在L2Beat 报告中也提到了，是这些人必须有足够的知识和能力，才能对multisig批准的行动做出最佳判断。
这些成员并非完全匿名，因为他们的地址是公开的。他们的地址可以在Etherscan中检查。
以下是Polygon zkEVM安全理事会的8个地址列表：
- 0xFe45baf0F18c207152A807c1b05926583CFE2e4b
- 0xaF46a0ddf80DFFB49C87656625E65A37499B261D
- 0xBDc235cC9d6Baa641c5ae306bc83962475A5FEFf
- 0x4c1665d6651ecEfa59B9B3041951608468b18891
- 0x3ab9f4b964eE665F7CDf1d65f1cEEc6196B0D622
- 0x49c15936864690bCd6af0ecaca8E874adFF30E86
- 0x9F7dfAb2222A473284205cdDF08a677726d786A0
- 0x21887c89368bf918346c62460e0c339113801C28
5.3 何为Security Council Multisig？
Security Council Multisig为由Polygon zkEVM Security Council部署的multisig合约，当触发紧急状态或需紧急升级时，需执行该合约。
Security Council Multisig合约为6-out-of-8 multisig，合约成功部署需附加Security Council中的6个签名。
同时规定，所附加的6个签名中，至少有2个签名是来自Polygon团队之外的4个成员。
参考资料
[1] Polygon zkEVM协议可升级性
[2] Polygon zkEVM升级流程
[3] Polygon zkEVM的管理员及治理
[4] Polygon zkEVM安全委员会
附录：Polygon Hermez 2.0 zkEVM系列博客
- ZK-Rollups工作原理
- Polygon zkEVM——Hermez 2.0简介
- Polygon zkEVM网络节点
- Polygon zkEVM 基本概念
- Polygon zkEVM Prover
- Polygon zkEVM工具——PIL和CIRCOM
- Polygon zkEVM节点代码解析
- Polygon zkEVM的pil-stark Fibonacci状态机初体验
- Polygon zkEVM的pil-stark Fibonacci状态机代码解析
- Polygon zkEVM PIL编译器——pilcom 代码解析
- Polygon zkEVM Arithmetic状态机
- Polygon zkEVM中的常量多项式
- Polygon zkEVM Binary状态机
- Polygon zkEVM Memory状态机
- Polygon zkEVM Memory Align状态机
- Polygon zkEVM zkASM编译器——zkasmcom
- Polygon zkEVM哈希状态机——Keccak-256和Poseidon
- Polygon zkEVM zkASM语法
- Polygon zkEVM可验证计算简单状态机示例
- Polygon zkEVM zkASM 与 以太坊虚拟机opcode 对应集合
- Polygon zkEVM zkROM代码解析（1）
- Polygon zkEVM zkASM中的函数集合
- Polygon zkEVM zkROM代码解析（2）
- Polygon zkEVM zkROM代码解析（3）
- Polygon zkEVM公式梳理
- Polygon zkEVM中的Merkle tree
- Polygon zkEVM中Goldilocks域元素circom约束
- Polygon zkEVM Merkle tree的circom约束
- Polygon zkEVM FFT和多项式evaluate计算的circom约束
- Polygon zkEVM R1CS与Plonk电路转换
- Polygon zkEVM中的子约束系统
- Polygon zkEVM交易解析
- Polygon zkEVM 审计及递归证明
- Polygon zkEVM发布公开测试网2.0
- Polygon zkEVM测试集——创建合约交易
- Polygon zkEVM中的Recursive STARKs
- Polygon zkEVM的gas定价
- Polygon zkEVM zkProver基本设计原则 以及 Storage状态机
- Polygon zkEVM bridge技术文档
- Polygon zkEVM Trustless L2 State Management 技术文档
- Polygon zkEVM中的自定义errors
- Polygon zkEVM RPC服务
- Polygon zkEVM Prover的 RPC功能
- Polygon zkEVM PIL技术文档
- Polygon zkEVM递归证明技术文档（1）【主要描述了相关工具 和 证明的组合、递归以及聚合】
- Polygon zkEVM递归证明技术文档（2）—— Polygon zkEVM架构设计
- Polygon zkEVM递归证明技术文档（3）——代码编译及运行
- Polygon zkEVM递归证明技术文档（4）—— C12 PIL Description
- Polygon zkEVM递归证明技术文档（5）——附录：借助SNARKjs和PIL-STARK实现proof composition
- eSTARK：Polygon zkEVM的扩展STARK协议——支持lookup、permutation、copy等arguments（1）
- eSTARK：Polygon zkEVM的扩展STARK协议——支持lookup、permutation、copy等arguments（2）
- eSTARK：Polygon zkEVM的扩展STARK协议——支持lookup、permutation、copy等arguments（3）
- Polygon zkEVM的Dragon Fruit和Inca Berry升级