什么是可升级的以太坊智能合约

可升级的以太坊智能合约

以太坊区块链上的智能合约是不可变的。一旦部署了智能合约，就不可能更改合约地址的代码。您可以完全删除一个合约，或者更准确地说，如果这个函数最初是用代码编写的，那么一个智能合约可能会自我销毁。一方面，信任问题得到了解决，用户可以确保一切都完全由算法控制。另一方面，现在修复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种数据存储方法。下次我们将深入探讨委派任务和可能出现的问题。