本文介绍了OpenZeppelin的升级插件,该插件集成了Hardhat和Foundry,用于在以太坊上部署和管理可升级合约。插件支持部署和升级合约,管理代理管理员权限,并易于在测试中使用,支持UUPS、透明和信标代理模式。
将升级集成到你现有的工作流程中。 用于 Hardhat 和 Foundry 的插件,用于在 Ethereum 上部署和管理可升级合约。
部署可升级合约。
升级已部署的合约。
管理代理管理员权限。
轻松在测试中使用。
升级插件只是用于部署和保护可升级智能合约的一整套 OpenZeppelin 工具的一部分。查看完整的资源列表。 |
请参阅 Hardhat Upgrades 或 Foundry Upgrades 的文档。
这些插件提供了用于管理合约的可升级部署的函数。
例如,deployProxy
执行以下操作:
当你调用 upgradeProxy
时:
部署新的 实现合约。请注意,Hardhat 插件首先检查是否存在已部署的具有相同字节码的实现合约,如果已部署则跳过此步骤。
升级代理以使用新的实现合约。
Hardhat 插件会跟踪你在项目根目录下的 .openzeppelin
文件夹中部署的所有实现合约,以及代理管理员。你将在那里找到每个网络一个文件。建议你将所有网络(开发网络除外)的文件提交到源代码控制(你可能会将它们视为 .openzeppelin/unknown-*.json
)。
Foundry 插件不跟踪实现合约,但要求你 定义参考合约,以便验证新版本的实现的升级安全性。
这些插件支持 UUPS、transparent 和 beacon 代理模式。UUPS 和 transparent 代理单独升级,而任何数量的 beacon 代理可以通过升级它们指向的 beacon 同时进行原子升级。有关可用不同代理模式的更多详细信息,请参阅 代理 的文档。
对于 UUPS 和 transparent 代理,请使用 deployProxy
和 upgradeProxy
。对于 beacon 代理,请使用 deployBeacon
、deployBeaconProxy
和 upgradeBeacon
。有关示例,请参阅 Hardhat Upgrades 和 Foundry Upgrades 的文档。
Transparent 代理定义了一个 admin 地址,该地址有权升级它们。默认情况下,admin 是在后台部署的 代理管理员合约。请记住,代理的 admin 只能升级它,但不能与实现合约交互。阅读 Transparent 代理和函数冲突 以获取有关此限制的更多信息。
代理管理员合约还定义了一个 owner 地址,该地址有权操作它。默认情况下,如果提供了 transparent 代理的部署期间使用的 initialOwner
地址是代理管理员的所有者,否则是部署期间使用的外部拥有的帐户。你可以通过调用 Hardhat 插件中的 admin.transferProxyAdminOwnership
函数,或者在使用 Foundry 时调用代理管理员合约的 transferOwnership
函数来更改代理管理员的所有者。
不要重用已部署的 ProxyAdmin 。在 @openzeppelin/contracts 版本 5.x 之前,提供给 transparent 代理的地址是 initialAdmin ,而不是新部署的 ProxyAdmin 的 initialOwner 。重用 ProxyAdmin 将禁用合约中的可升级性。 |
UUPS 和 beacon 代理不使用 admin 地址。UUPS 代理依赖于可以被覆盖的 _authorizeUpgrade
函数来包含对升级机制的访问限制,而 beacon 代理只能由其相应 beacon 的所有者升级。
一旦你将升级代理或 beacon 的权利转移到另一个地址,你仍然可以使用本地设置来验证和部署实现合约。这些插件包括一个 prepareUpgrade
函数,该函数将验证新实现是否升级安全并且与之前的实现兼容,并使用你的本地 Ethereum 帐户进行部署。然后,你可以从 admin 或 owner 地址执行升级本身。你还可以使用 defender.proposeUpgrade
或 defender.proposeUpgradeWithApproval
函数在 OpenZeppelin Defender 中自动设置升级。
- 原文链接: docs.openzeppelin.com/up...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!