目前主流有三种合约升级方法
- transparent 方式;(通用,业务逻辑和代理逻辑解耦合,比较贵)
- uups 方式;(代理逻辑集成到了业务逻辑,通过继承来实现,便宜)
- beacon 方式;(更加高级,一个信号,升级多个合约)
本次采用 transparent 方式,具体实现思路即,引入一个代理合约 Proxy(蓝色),用户仅与这个代理合约进行交互,由代理合约去与业务合约进行交互,因此在业务合约发生变化(升级)的时候,用户无感,并且历史数据也能够保留下来,如下图所示:
既然业务合约可以随意切换,那用户数据就只能存储在代理合约中了,在实际进行业务处理时,数据读写都是从代理合约来的,即数据与逻辑分离,其实现的核心便是 delegatecall 关键字。在此之前,先对 solidity 提供的三个合约调用方法:call、staticdall、delegatecall 进行对比说明
- call:主要是进行常规的合约调用,比如进行合约向普通EOA进行转账时,语法为:to.call{value: value}(""),此时目标合约中的msg.sender是调用者,即Caller Contract;
- staticcall:与call类似,但是它不会修改合约状态,单纯调用计算而已,原理同上;(不常用)
- delegatecall:这个是专门为代理合约 Proxy 准备的,作用是帮助用户 User 来调用 Target Contract 合约
delegatecall 特点:
1、从 Target Contract 角度来看:msg.sender 是 user,而不是 Proxy,即 Proxy 对 user 的请求进行了透传;
2、在 Target Contract 被调用时,使用的是 Proxy 的上下文,即执行合约带来的状态变化会存在 Proxy 中,而不是 Target Contract 之中
(注:由于 Transparent 模式升级时,implementation 和 proxy 不用相互关心彼此的 storage 数据,因此这种模式被称为:unstructed storage)
存储冲突问题
在 solidity 中,状态变量存储在 slot 中,slot 可以理解为 key-value 存储空间,evm 为每个合约代码提供了最多 2^256个 slot,每个 slot 可以最多存储 32 字节数据。状态变量一般是从 slot 0 开始进行存储的,在使用 delegatecall 的时候,由于需要在 Proxy 的 slot 中存储目标合约中指定的数据结构,此时如果 proxy 的 storage 布局与目标合约的 storage 布局不相同,那么就会出现存储冲突(Storage collisioin)的问题。
slot 0 分别存储的是逻辑合约地址 _imp 和管理员地址 _owner,出现存储冲突。
解决存储冲突问题
在代理合约 Proxy 中,一共需要指定两个状态变量:
- 逻辑合约地址 implementation,用来指明被代理的合约;
- Admin,代理合约的管理员,有权限进行合约升级;
因此,如果不进行特殊处理,则一定会出现存储 slot 冲突,我们可以将 Proxy 中的默认 slot 留出来,不要占用,而是在代理合约使用指定的 slot 来存储逻辑合约 _imp 和 admin 地址,这个解决方案也叫 EIP-1967
# implementation slot 生成规则:
bytes32(uint256(keccak256('eip1967.proxy.beacon')) - 1),
# admin slot 生成规则:
bytes32(uint256(keccak256('eip1967.proxy.admin')) - 1)),
升级规则
1 在升级的合约中,如果有新变量的添加,那么新的状态变量只能在原始合约状态末尾依次往后添加,否则也会导致状态变量布局不一致,出现存储冲突;
2 如果一个合约定义为可升级的,那么这个合约不能有构造函数,需要使用initialize 函数来代替初始化工作。因为我们需要将部署时的数据存储在 Proxy 合约中,如果提供了构造函数,这些数据就会错误地写在逻辑合约中。
WorldCup 升级改造
首先在 node_modules 目录下安装合约升级地标准库,以使用初始化函数
npm i @openzeppelin/contracts-upgradeable
创建 WorldCupV1.sol,在原有 WorldCup 基础上修改代码
//1. 导入标准包
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
//2. 继承
contract WorldCupV1 is Initializable {
//3. 将构造函数替换为初始化函数 constructor(uint256 _deadline)
function initialize(uint256 _deadline) public initializer {
admin = msg.sender;
require(
_deadline > block.timestamp,
"WorldCupLottery: invalid deadline!"
);
deadline = _deadline;
}
}
再创建升级后的合约 WorldCupV2.sol,修改如下:
event ChangeDeadline(uint256 _prev, uint256 _curr);
uint256 changeCount
// 1. 增加函数,支持修改deadline
function changeDeadline(uint256 _newDeadline) external {
require(_newDeadline > block.timestamp, "invalid timestamp!");
// 2.增加新事件
emit ChangeDeadline(deadline, _newDeadline);
// 4.状态变量
changeCount++;
deadline = _newDeadline;
}
安装升级插件,在配置文件中导入
$ npm install --save-dev @openzeppelin/hardhat-upgrades
// hardhat.config.js
require('@openzeppelin/hardhat-upgrades');
编写升级脚本,创建 scripts/deployAndUpgrade.ts:
const { ethers, upgrades } = require("hardhat");
async function main() {
const TWO_WEEKS_IN_SECS = 14 * 24 * 60 * 60;
const timestamp = Math.floor(Date.now() / 1000)
const deadline = timestamp + TWO_WEEKS_IN_SECS;
console.log('deadline:', deadline)
// Deploying
const WorldCupv1 = await ethers.getContractFactory("WorldCupV1");
const instance = await upgrades.deployProxy(WorldCupv1, [deadline]);
await instance.deployed();
console.log("WorldCupV1 address:", instance.address);
console.log("deadline1:", await instance.deadline())
console.log('ready to upgrade to V2...');
// Upgrading
const WorldCupV2 = await ethers.getContractFactory("WorldCupV2");
const upgraded = await upgrades.upgradeProxy(instance.address, WorldCupV2);
console.log("WorldCupV2 address:", upgraded.address);
await upgraded.changeDeadline(deadline + 100)
console.log("deadline2:", await upgraded.deadline())
}
main();
部署升级合约
npx hardhat run scripts/upgrade/deployAndUpgrade.ts --network goerli
我们还没 verify 业务合约 WorldCupV1 和 WorldCupV2,然后与当前的代理合约 Proxy 关联起来,我们通过 internal Txns 可以找到 WorldCupV2 的合约地址:
都对其进行 verify,并查看数据,发现都是空的
关联合约
找到代理合约-> More Options -> Is this a proxy? -> Verify -> Save
然后再回到当前页面刷新后,页面上多了两个按钮:Read as Proxy 和 Write as Proxy 如图:
我们最终暴露给用户的地址就是这个代理合约,用户的所有操作都相当于在读写着两个新方法,这两个方法会被 Proxy 传递到逻辑合约中,并把执行结果返回到代理合约中
TransparentProxy 合约关系
通过hardhat-upgrade包执行部署后,一共会自动部署三个合约:
- 代理合约:TransparentUpgradebleProxy
- 代理合约的管理员合约:proxyAdmin
- 业务合约:implementation
当我们使用脚本执行合约升级的时候,此时内部交互为:
- 自动部署 WorldCupV2 合约
- 调用 ProxyAdmin 的 upgrade 方法,进行升级