【摘要】 可升级的智能合约不可能更改地址代码 确保算法控制一切
这是“可升级的智能合约:存储亮点和挑战”系列文章的第一篇。我们将更深入地研究可升级的智能合约、它们的功能和可供开发人员使用的存储选项。
可升级的以太坊智能合约
以太坊区块链上的智能合约是不可变的。一旦部署了智能合约，就不可能更改合约地址的代码。您可以完全删除一个合约，或者更准确地说，如果这个函数最初是用代码编写的，那么一个智能合约可能会自我销毁。一方面，信任问题得到了解决，用户可以确保一切都完全由算法控制。另一方面，现在修复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种数据存储方法。（考拉）