目前主流有三种合约升级方法
- 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 方法，进行升级