Web3系列教程之高级篇—10:构建可随时间升级的智能合约

Web3系列教程之高级篇—10:构建可随时间升级的智能合约

我们知道,以太坊上的智能合约是不能升级的,因为代码是不可变的,一旦部署就不能更改。但第一次写出完美的代码是很难的,作为人类,我们都很容易犯错。有时,即使是经过审计的合同,也会发现有错误,导致其损失数百万。

在本文中,我们将学习一些可以在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:

1. Diamond Implementation2. Transparent Implementation3. UUPS Implementation

然而,我们将只关注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: MIT pragma 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代理模式

UUPS代理模式是另一种在Proxy合同和Implementation合同之间分离责任的方式。在这种情况下,upgradeTo函数也是Implementation契约的一部分,并且通过代理被所有者使用delegatecall 。

在UUPS中,不管是管理员还是用户,所有的调用都被发送到Implementation Contract中。这样做的好处是,每次调用时,我们不必访问存储空间来检查开始调用的用户是否是管理员,这提高了效率和成本。另外,因为是Implementation Contract,你可以根据你的需要定制功能,在每一个新的Implementation中加入诸如Timelock、Access Control等,这在Transparent Proxy Pattern中是做不到的。

UUPS代理模式的问题

现在的问题是,因为upgradeTo函数存在于Implementation contract的一侧,开发者必须担心这个函数的实现,这有时可能很复杂,而且因为增加了更多的代码,增加了攻击的可能性。这个函数也需要在所有被升级的Implementation contract的版本中出现,这就引入了一个风险,如果开发者忘记添加这个函数,那么合同就不能再被升级了。

构建

让我们开发一个例子,你可以体验如何建立一个可升级的合同。在这个例子中,我们将使用UUPS可升级模式,当然你也可以用透明代理模式来开发一个。

• 要设置一个Hardhat项目,请打开终端并执行这些命令
npm init –yes npm install –save-dev hardhat
• 如果你使用的是Windows系统,请做这个额外的步骤,同时安装这些库 🙂
npm install –save-dev @nomiclabs/hardhat-waffle ethereum-waffle chai @nomiclabs/hardhat-ethers ethers
• 在你安装Hardhat的同一目录下运行。
npx hardhat
• 选择Create a basic sample project• 对已指定的Hardhat Project root按回车键• 如果你想添加一个.gitignore,请按回车键。• 按回车键Do you want to install this sample projects dependencies with npm (@nomiclabs/hardhat-waffle ethereum-waffle chai @nomiclabs/hardhat-ethers ethers)?

现在你有一个准备好的hardhat项目了!

• 我们将使用openzeppelin的库,它支持可升级的合同。要安装这些库,在同一个文件夹中执行以下命令。
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: MIT pragma 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: MIT pragma 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

阅读

• 在文章中提到了Timelock,要了解更多关于它的信息,你可以阅读以下文章[5]• 还提到了Access Control,你可以在这里[6]阅读更多关于它的信息

参考

• OpenZeppelin Docs[7]• OpenZeppelin Youtube[8]

引用链接

[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

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

Proudly powered by WordPress | Theme: HoneyWaves by SpiceThemes