1. 引言
随着Polygon社区开发者和内部团队的测试深入,当前版本的Polygon zkEVM不可避免地需更新和某些升级。
为激励开发者对Polygon zkEVM做battle-test,已启动了bug-bounty:
由于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升级