文章阅读页通栏

存储可升级的以太坊智能合约

来源: 区块网 作者:考拉
这是“可升级的智能合约:存储亮点和挑战”系列文章的第一篇。我们将更深入地研究可升级的智能合约、它们的功能和可供开发人员使用的存储选项。 ......
这是“可升级的智能合约:存储亮点和挑战”系列文章的第一篇。我们将更深入地研究可升级的智能合约、它们的功能和可供开发人员使用的存储选项。

可升级的以太坊智能合约

以太坊区块链上的智能合约是不可变的。一旦部署了智能合约,就不可能更改合约地址的代码。您可以完全删除一个合约,或者更准确地说,如果这个函数最初是用代码编写的,那么一个智能合约可能会自我销毁。一方面,信任问题得到了解决,用户可以确保一切都完全由算法控制。另一方面,现在修复bug是毫无疑问的。

因此,可升级的以太坊智能合约拯救了我们。等等,什么?我们刚刚说过,以太坊中没有这样的合约(不像EOS)。然而,可升级的智能合约是可以模拟的。其思想是智能合约地址和代码保持不变,代码将执行转发给另一个合约,然后返回其结果。在本例中,主智能合约称为代理。在变量中保存另一个合约地?#20998;?#21518;,我们可以像更改合约状态一样轻松地更改它,而代码仍然是不可变的。最终可以有多个智能合约版本;迁移是通过记录新版本地址来进行的。

存储可升级的智能合约状态

与任何其他软件类似,开发人员必须在发布新版本时解决数据迁移问题。对于代理,智能合约应该存储在哪里?我们有三种完全不同的方法。

为每个版本分别存储

第一?#22336;?#27861;意味着每个版本分别将其状态存储在?#32422;?#30340;存储中。这确保了最大程度的隔离和控制,排除了冲突,同时增加了将单独的记录迁移到存储中所引起的复?#26377;?#21644;GAS成本。让我们假设一个基本的代币合约正在开发中。在这?#26234;?#20917;下,核心数据就是平衡:

mapping (address => uint256) private _balances;

不能直接?#26377;?#29256;本中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;

}

此时还会出?#21046;?#20182;问题:不能根据任何请求立即进行迁移,因为可能需要将数据记录到存储中,而且仅在视?#24049;?#25968;中不能使用数据记录。因此,所有对balance的请求,即使是内部的,都必须通过balanceOf和setBalance函数来执行。

在最坏的情况下,对仅限视图的函数的调用将遍历整个代币版本链,收集数据,但并不能记录与最新版本相关的操作结果,因为它们没有修改权限。从最新版本之外的其他版本调用这些函数是可能的,但意义不大。

同时在最新的代币代码版本中为当前用户迁移数据和记录操作结果,需要调用能够更改最新版本状态的函数。因此,对任何其他函数的进一步调用都不需要经过整个代币版本链。仅允许代理合约调用更改最新版本状态的函数。

作为数据库的合约

可以建议另一种存储方式。让我们看看在传统的程序中如何处理这个问题。数据是从代码中分离出来的!此外,当涉及到复杂的程序和系统?#20445;?#25968;据存储在SQL或NoSQL存储中。

为此目的编写的特殊智能合约可以用作存储。因此,无论当前代币代码版本如何,数据都将始终保存在此合约的存储中。这个合约的代码可以移到库中,但是现在不在日程上。不需要将数据从一个存储迁移到另一个存储;相反,存储访问权限从一个版本转移到另一个版本。然而,使用这种类型的存储并非没有问题。它将需要定义一个可用于任何版本的代币智能合约的接口,例如sql或WORD文档。谈到这种存储类型的示例,请查看EOS表。

让我们将结构、字段名和数据类型统一到数据方案中。存储智能合约代码可以?#21024;?#24577;部分(无论当前数据模式如何,都不会更改的代码)和动态部分(依赖于模式的代码)组成。动态部分包含许多样板代码,因此自动生成它是有意义的,因为它是在协议缓冲区或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特性使其成为可能。它在目标地?#20998;?#34892;代码,但是使用执行了一个delegatecall指令的合约的存储。

调用以前合约版本的函数没有什么意义,因为它们只不过是“代码片段?#20445;?#25152;有状态都存储在代理合约中。Delegatecall用于调用库合约。库代码很容易通过?#21018;?#23450;位必要的数据。然而,该指令可能?#28304;?#29702;合约构成潜在威胁。不幸的是,正式的Solidity文档几乎没有警告我们:“如果状态变量是通过低级委托访问的,那么两个合约的存储布局必须对齐,以便被调用的合约能够正确地按名称访问调用合约的存储变量。”

结论

我们研究了可升级的智能合约开发,并研究了3种数据存储方法。下次我们将深入探讨委派任务和可能出现的问题。

关键词: 以太坊  智能合约  
0/300
? 拳皇命运官方实力排名
18095期14场胜负彩开奖 广东今晚36选7中奖结果 无插件直播足球 福彩3d图山西彩民乐 江西时时诈骗案件 微信捕鱼赢现金手机版下载 浙江体彩6十1走势图2元网 广东时时开奖公告 14场胜负彩19077 老时时360冷热