我们知道，以太坊上的智能合约是不能升级的，因为代码是不可变的，一旦部署就不能更改。但第一次写出完美的代码是很难的，作为人类，我们都很容易犯错。有时，即使是经过审计的合同，也会发现有错误，导致其损失数百万。
在本文中，我们将学习一些可以在Solidity中使用的设计模式，以编写可升级的智能合约。
为了升级我们的合同，我们使用了一种叫做Proxy Pattern的东西。Proxy这个词对你来说可能听起来很熟悉，因为它不是一个web3的原生词。
从本质上讲，这种模式的工作原理是，一个合同被分成两个合同--Proxy Contract和Implementation Contract。
Proxy Contract负责管理合同的状态，涉及持久性存储，而Implementation Contract负责执行逻辑，不存储任何持久性状态。用户调用Proxy Contract，Proxy Contract进一步对实现合同进行delegatecall，这样它就可以实现逻辑。记得我们在以前的文章中学习过delegatecall。
当Implementation Contract可以被替换时，这种模式就变得有趣了，这意味着执行的逻辑可以被另一个版本的Implementation Contract所替换，而不影响存储在代理中的合同的状态。
主要有三种方式，我们可以替换/升级Implementation Contract:
然而，我们将只关注Transparent和UUPS，因为它们是最常用的。
要升级Implementation Contract，你必须使用一些方法，比如upgradeTo(address)，这基本上会把Implementation Contract的地址从旧的变成新的。
但重要的部分在于我们应该把upgradeTo(address)函数放在哪里，我们有两个选择，要么把它放在Proxy Contract中，这基本上是Transparent Proxy Pattern的工作方式，要么把它放在Implementation Contract中，这就是UUPS合同的工作方式。
关于这个Proxy Pattern，另一个需要注意的是，Implementation Contract的构造函数永远不会被执行。
当部署一个新的智能合约时，构造器内的代码不是合约运行时字节码的一部分，因为它只在部署阶段需要，并且只运行一次。现在，因为当Implementation Contract 被部署时，它最初没有连接到Proxy Contract，因此，任何在构造器中发生的状态变化现在在Proxy Contract中不存在，而Proxy Contract是用来维护整体状态的。
因为Proxy Contracts不知道构造函数的存在。因此，我们不使用构造函数，而是使用一个叫做initializer函数的东西，一旦Implementation Contract与之相连，它就会被Proxy Contract调用。这个函数所做的正是构造函数应该做的事情，但是现在它被包含在运行时字节码中，因为它的行为就像一个普通的函数，并且可以被Proxy Contract调用。
使用OpenZeppelin合约，你可以使用他们的Initialize.sol合约，确保你的initialize函数只被执行一次，就像一个构造函数一样
// contracts/MyContract.sol// SPDX-License-Identifier: MITpragma solidity ^0.6.0;import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";contract MyContract is Initializable { function initialize( address arg1, uint256 arg2, bytes memory arg3 ) public payable initializer { // "constructor" code... }}上面给出的代码来自Openzeppelin的文档[1]，它提供了一个例子，说明initializer修改器如何确保初始化函数只能被调用一次。这个修改器来自Initializable Contract
我们现在将详细研究代理模式
透明代理模式是一种简单的方法来分离Proxy合同和Implementation合同之间的责任。在这种情况下，upgradeTo函数是Proxy合同的一部分，而Implementation可以通过在Proxy上调用upgradeTo来升级，从而改变未来函数调用的委托位置。
不过也有一些注意事项。可能有这样一种情况：Proxy Contract和Implementation Contract有一个名称和参数相同的函数。想象一下，如果Proxy Contract有一个owner()函数，Implementation Contract也有。在透明代理合约中，这个问题由Proxy Contract来处理，Proxy Contract根据msg.sender全局变量来决定用户的调用是在Proxy Contract本身还是在Implementation Contract中执行。
所以如果msg.sender是代理的管理员，那么代理将不会委托调用，如果它理解的话，将尝试执行调用。如果它不是管理员地址，代理将把调用委托给Implementation Contract，即使它与代理的某个函数相匹配。
我们知道，owner的地址必须存储在存储器中，而使用存储器是与智能合约互动的最低效和最昂贵的步骤之一，每次用户调用代理时，代理会检查用户是否是管理员，这给大多数发生的交易增加了不必要的气体成本。
UUPS代理模式是另一种在Proxy合同和Implementation合同之间分离责任的方式。在这种情况下，upgradeTo函数也是Implementation契约的一部分，并且通过代理被所有者使用delegatecall 。
在UUPS中，不管是管理员还是用户，所有的调用都被发送到Implementation Contract中。这样做的好处是，每次调用时，我们不必访问存储空间来检查开始调用的用户是否是管理员，这提高了效率和成本。另外，因为是Implementation Contract，你可以根据你的需要定制功能，在每一个新的Implementation中加入诸如Timelock、Access Control等，这在Transparent Proxy Pattern中是做不到的。
现在的问题是，因为upgradeTo函数存在于Implementation contract的一侧，开发者必须担心这个函数的实现，这有时可能很复杂，而且因为增加了更多的代码，增加了攻击的可能性。这个函数也需要在所有被升级的Implementation contract的版本中出现，这就引入了一个风险，如果开发者忘记添加这个函数，那么合同就不能再被升级了。
让我们开发一个例子，你可以体验如何建立一个可升级的合同。在这个例子中，我们将使用UUPS可升级模式，当然你也可以用透明代理模式来开发一个。
npm init --yesnpm install --save-dev hardhatnpm install --save-dev @nomiclabs/hardhat-waffle ethereum-waffle chai @nomiclabs/hardhat-ethers ethersnpx hardhat现在你有一个准备好的hardhat项目了!
npm i @openzeppelin/contracts-upgradeable @openzeppelin/hardhat-upgrades @nomiclabs/hardhat-etherscan --save-dev用以下代码替换你的hardhat.config.js中的代码，以便能够使用这些库。
require("@nomiclabs/hardhat-ethers");require("@openzeppelin/hardhat-upgrades");require("@nomiclabs/hardhat-etherscan");module.exports = { solidity: "0.8.4",};首先，在contracts目录下创建一个新文件，名为LW3NFT.sol，并在其中添加以下几行代码
//SPDX-License-Identifier: MITpragma solidity ^0.8.4;import "@openzeppelin/contracts-upgradeable/token/ERC721/ERC721Upgradeable.sol";import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";import "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";contract LW3NFT is Initializable, ERC721Upgradeable, UUPSUpgradeable, OwnableUpgradeable { // Note how we created an initialize function and then added the // initializer modifier which ensure that the // initialize function is only called once function initialize() public initializer { // Note how instead of using the ERC721() constructor, we have to manually initialize it // Same goes for the Ownable contract where we have to manually initialize it __ERC721_init("LW3NFT", "LW3NFT"); __Ownable_init(); _mint(msg.sender, 1); } function _authorizeUpgrade(address newImplementation) internal override onlyOwner { }}让我们试着更详细地了解这份合同中所发生的事情。
如果你看一下LW3NFT导入的所有合约，你就会明白为什么它们很重要。首先是Openzeppelin的Initializable契约，它为我们提供了initializer修改器，确保initializer函数只被调用一次。initializer函数是需要的，因为我们不能在Implementation Contract中拥有一个构造器，在这种情况下，Implementation Contract就是LW3NFT的契约
它导入了ERC721Upgradeable和OwnableUpgradeable，因为原始的ERC721和Ownable合约有一个构造函数，不能用于代理合约。
最后，我们有UUPSUpgradeable Contract ，它为我们提供了upgradeTo(address)函数，在UUPS代理模式的情况下，它必须被放在Implementation Contract上。
在合同的声明之后，我们有一个带有initialize修饰的initialize函数，我们从Initializable合同中得到。initialize修饰符确保initialize函数只能被调用一次。还请注意，我们初始化ERC721和Ownable合约的新方式。这是初始化可升级合约的标准方式，你可以在这里看一下这个函数[2]。之后，我们就用通常的mint函数来造币。
function initialize() public initializer { __ERC721_init("LW3NFT", "LW3NFT"); __Ownable_init(); _mint(msg.sender, 1);}另一个有趣的功能是_authorizeUpgrade，我们在正常的ERC721合约中没有看到这个功能，当开发者从Openzeppelin导入UUPSUpgradeable Contract时，需要实现这个功能，它可以在这里[3]找到。现在，为什么这个函数必须被覆盖，这很有趣，因为它让我们有能力在谁能真正升级给定的合同上添加授权，它可以根据要求改变，但在我们的案例中，我们只是添加了一个onlyOwner修改器。
function _authorizeUpgrade(address newImplementation) internal override onlyOwner {}现在让我们在contracts目录下创建另一个新文件，名为LW3NFT2.sol，这将是LW3NFT.sol的升级版。
//SPDX-License-Identifier: MITpragma solidity ^0.8.4;import "./LW3NFT.sol";contract LW3NFT2 is LW3NFT { function test() pure public returns(string memory) { return "upgraded"; }}这个智能合约要简单得多，因为它只是继承了LW3NFT合约，然后添加了一个名为test的新函数，它只是返回一个upgraded的字符串。
很容易吧？
Wow ，好了，我们已经写完了Implementation Contract，现在我们还需要写 Proxy Contract吗？
好消息是，不，我们不需要写Proxy Contract，因为当我们使用Openzeppelin的库来部署Implementation Contract时，Openzeppelin会自动部署和连接一个Proxy Contract。
因此，让我们尝试这样做，在你的test目录中创建一个新的文件，命名为proxy-test.js，让我们用代码尝试一下
const { expect } = require("chai");const { ethers } = require("hardhat");const hre = require("hardhat");describe("ERC721 Upgradeable", function () { it("Should deploy an upgradeable ERC721 Contract", async function () { const LW3NFT = await ethers.getContractFactory("LW3NFT"); const LW3NFT2 = await ethers.getContractFactory("LW3NFT2"); let proxyContract = await hre.upgrades.deployProxy(LW3NFT, { kind: "uups", }); const [owner] = await ethers.getSigners(); const ownerOfToken1 = await proxyContract.ownerOf(1); expect(ownerOfToken1).to.equal(owner.address); proxyContract = await hre.upgrades.upgradeProxy(proxyContract, LW3NFT2); expect(await proxyContract.test()).to.equal("upgraded"); });});让我们看看这里发生了什么，我们首先使用getContractFactory函数获得LW3NFT和LW3NFT实例，这是我们到现在为止一直在教的所有文章都通用的。在这之后，最重要的一行出现了。
let proxyContract = await hre.upgrades.deployProxy(LW3NFT, { kind: "uups",});这个函数来自于你安装的@openzeppelin/hardhat-upgrades库，它基本上是使用upgrades类来调用deployProxy函数，并指定种类为uups。当该函数被调用时，它将部署Proxy Contract、LW3NFT Contract并将它们连接起来。关于这个的更多信息可以在这里[4]找到。
请注意，initialize函数可以用任何其他名字，只是deployProxy默认调用initialize函数，但你可以通过改变默认值来修改它
部署后，我们通过调用代币ID 1的ownerOf函数来测试合约是否真的被部署，并检查NFT是否真的被铸造。
现在，下一部分来了，我们要部署LW3NFT2，这是LW3NFT的升级版合同。
为此，我们再次执行@openzeppelin/hardhat-upgrades库中的upgradeProxy方法，该方法将LW3NFT升级并替换为LW3NFT2，而不改变系统的状态。
proxyContract = await hre.upgrades.upgradeProxy(deployedLW3NFT, LW3NFT2);为了测试它是否真的被替换，我们调用了test()函数，并确保它返回 "upgraded"，尽管该函数在最初的LW3NFT合同中并不存在。
你今天学会了如何升级一个智能合约。
LFG
[1] Openzeppelin的文档: https://docs.openzeppelin.com/upgrades-plugins/1.x/proxies#the-constructor-caveat
[2] 这个函数: https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable/blob/master/contracts/token/ERC721/ERC721Upgradeable.sol#L45
[3] 这里: https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable/blob/master/contracts/proxy/utils/UUPSUpgradeable.sol#L100
[4] 这里: https://docs.openzeppelin.com/upgrades-plugins/1.x/api-hardhat-upgrades
[5] 以下文章: https://blog.openzeppelin.com/protect-your-users-with-smart-contract-timelocks/
[6] 这里: https://docs.openzeppelin.com/contracts/3.x/access-control
[7] OpenZeppelin Docs: https://docs.openzeppelin.com/upgrades-plugins/1.x/proxies
[8] OpenZeppelin Youtube: https://www.youtube.com/watch?v=kWUDTZhxKZI
| 留言与评论（共有 0 条评论） “” |
