Polygon zkEVM协议治理、升级及其流程

1. 引言

随着Polygon社区开发者和内部团队的测试深入，当前版本的Polygon zkEVM不可避免地需更新和某些升级。

为激励开发者对Polygon zkEVM做battle-test，已启动了bug-bounty：

Rewards by Threat Level

由于zk-Rollup生态系统还处于萌芽阶段，预计升级频率会随着时间的推移而下降。与此同时，Polygon打算将其升级管理从目前的集中化方式转变为更加分散的工作方式。

Polygon致力于与以太坊关于L2治理的规范和价值观保持一致。正如Polygon的三大治理支柱中所概述的那样，这些治理的逐步变化将遵循Polygon改进提案（PIP）。具体的三根治理支柱是指：

当前，中心化体现在：

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个地址列表：

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系列博客

相关阅读:
LangChain 2模块化prompt template并用streamlit生成网站实现给动物取名字
Java不支持协程？那是你不知道Quasar！
Java GUI实现桌球小游戏
SpringBoot 自动配置
mybatis在实际项目中常见的排坑配置
Android11 Launcher添加网格布局设置（3x3,4x4,5x5）
15——go语言中的流程控制
View绘制流程的源码所得
五：Dubbo中Provider参数配置及源码讲解
精灵宝可梦属性克制表（精灵属性相克图）

原文地址：https://blog.csdn.net/mutourend/article/details/134486860