区块链
可升级的以太坊智能合约
以太坊区块链上的智能合约是不可变的。一旦部署了智能合约,就不可能更改合约地址的代码。您可以完全删除一个合约,或者更准确地说,如果这个函数最初是用代码编写的,那么一个智能合约可能会自我销毁。一方面,信任问题得到了解决,用户可以确保一切都完全由算法控制。另一方面,现在修复bug是毫无疑问的。
因此,可升级的以太坊智能合约拯救了我们。等等,什么?我们刚刚说过,以太坊中没有这样的合约(不像EOS)。然而,可升级的智能合约是可以模拟的。其思想是智能合约地址和代码保持不变,代码将执行转发给另一个合约,然后返回其结果。在本例中,主智能合约称为代理。在变量中保存另一个合约地址之后,我们可以像更改合约状态一样轻松地更改它,而代码仍然是不可变的。最终可以有多个智能合约版本;迁移是通过记录新版本地址来进行的。
存储可升级的智能合约状态
与任何其他软件类似,开发人员必须在发布新版本时解决数据迁移问题。对于代理,智能合约应该存储在哪里?我们有三种完全不同的方法。
为每个版本分别存储
第一种方法意味着每个版本分别将其状态存储在自己的存储中。这确保了最大程度的隔离和控制,排除了冲突,同时增加了将单独的记录迁移到存储中所引起的复杂性和GAS成本。让我们假设一个基本的代币合约正在开发中。在这种情况下,核心数据就是平衡:
mapping (address =》 uint256) private _balances;
不能直接从新版本中balance调用;为了实现它,必须首先从以前的版本迁移数据。注意,迁移只能执行一次。
mapping (address =》 uint256) private _balances;
// previous version of a token smart contract
ERC20 private _previous;
// flag indicates that migration of certain user balance was performed
mapping (address =》 bool) private _migrated;
function balanceOf(address owner) public view returns (uint256) {
return _migrated[owner] ? _balances[owner] : _previous.balanceOf(owner);
}
function setBalance(address owner, uint256 new_balance) private {
_balances[owner] = new_balance;
if (!_migrated[owner])
_migrated[owner] = true;
}
此时还会出现其他问题:不能根据任何请求立即进行迁移,因为可能需要将数据记录到存储中,而且仅在视图函数中不能使用数据记录。因此,所有对balance的请求,即使是内部的,都必须通过balanceOf和setBalance函数来执行。
在最坏的情况下,对仅限视图的函数的调用将遍历整个代币版本链,收集数据,但并不能记录与最新版本相关的操作结果,因为它们没有修改权限。从最新版本之外的其他版本调用这些函数是可能的,但意义不大。
同时在最新的代币代码版本中为当前用户迁移数据和记录操作结果,需要调用能够更改最新版本状态的函数。因此,对任何其他函数的进一步调用都不需要经过整个代币版本链。仅允许代理合约调用更改最新版本状态的函数。
作为数据库的合约
可以建议另一种存储方式。让我们看看在传统的程序中如何处理这个问题。数据是从代码中分离出来的!此外,当涉及到复杂的程序和系统时,数据存储在SQL或NoSQL存储中。
为此目的编写的特殊智能合约可以用作存储。因此,无论当前代币代码版本如何,数据都将始终保存在此合约的存储中。这个合约的代码可以移到库中,但是现在不在日程上。不需要将数据从一个存储迁移到另一个存储;相反,存储访问权限从一个版本转移到另一个版本。然而,使用这种类型的存储并非没有问题。它将需要定义一个可用于任何版本的代币智能合约的接口,例如sql或WORD文档。谈到这种存储类型的示例,请查看EOS表。
让我们将结构、字段名和数据类型统一到数据方案中。存储智能合约代码可以由静态部分(无论当前数据模式如何,都不会更改的代码)和动态部分(依赖于模式的代码)组成。动态部分包含许多样板代码,因此自动生成它是有意义的,因为它是在协议缓冲区或Apache Thrift中实现的。我碰巧在ETHBerlin hackathon上处理过一个类似的任务,即开发以太坊柱状数据存储原型。
数据项描述如下结构:
struct Cafe {
string name;
uint32 latitude;
uint32 longitude;
address owner;
}
我们为GitHub生成一个“驱动程序”。驱动程序调用来自Github的静态代码,例如,`CDF.writeString`,`CDF.chunkDataPosition‘和其他函数。
正如我已经提到的,该解决方案涵盖了其他问题,并作为外部存储操作的一个示例。目前,我所知道的以太网智能合约存储中没有SQL / NoSQL存储的工作实现。对于可变智能合约中的数据存储问题而言,这似乎是一个很有意思的解决方案。
状态存储在用作DB的合约中,并通过调用而不是delegatecall指令调用。应该保护对写入调用的访问,并且只能用于代理协议。此DB合约的公共代码可以移动到库中。
委托调用并在代理合约中存储数据
最后,第三个选项是在代理合约存储中存储数据。如果代理是独立的智能合约,特定的代码版本如何访问数据?EVM delegatecall特性使其成为可能。它在目标地址执行代码,但是使用执行了一个delegatecall指令的合约的存储。
调用以前合约版本的函数没有什么意义,因为它们只不过是“代码片段”,所有状态都存储在代理合约中。Delegatecall用于调用库合约。库代码很容易通过指针定位必要的数据。然而,该指令可能对代理合约构成潜在威胁。不幸的是,正式的Solidity文档几乎没有警告我们:“如果状态变量是通过低级委托访问的,那么两个合约的存储布局必须对齐,以便被调用的合约能够正确地按名称访问调用合约的存储变量。”
结论
我们研究了可升级的智能合约开发,并研究了3种数据存储方法。下次我们将深入探讨委派任务和可能出现的问题。
全部0条评论
快来发表一下你的评论吧 !