以太坊智能合约升级策略

本文是对以太坊中可升级智能合约领域的各种实现策略的总结，目的是汇总迄今为止的相关资源，以帮助我们在设计智能合约时，考虑如何对其进行升级和更新。

100％可升级机制

目前有两种主要策略用来实现可升级的智能合约：

这两种方法要解决的根本问题是如何更新合同的逻辑，同时仍然保留对合同状态的访问。

代理合约使用delegatecall操作码将函数调用转发到可更新的目标合约。由于delegatecall 保留了函数调用的状态，因此可以更新目标合约的逻辑，并且状态将保留在代理合约中以供更新后的目标合约的逻辑使用。与delegatecall一样，msg.sender将保持代理合约的调用者身份。

由于最近的拜占庭硬分叉，现在可以获取函数调用的返回大小了，因此与Nick Johnson 首次提出的方法相比，目前这种方法可以通用。在Daonomic的文章中可以看到一个通用代理合约的例子，你可以更详细地了解这个机制。

这中方法到将智能合约拆分两个合约：

逻辑合约通过setter更新数据，而数据合约只允许逻辑合约调用setter。这允许在保持数据不变的同时更换实现逻辑，从而实现完全可升级的系统。

通过引导用户使用新的逻辑合约（通过诸如ENS的解析器）并更新数据合约的权限来允许新的逻辑合约执行setter，就可以实现合约的更新。

查看[@Thomas Wiesner](https://github.com/tomw1808)的视频以更好地了解这一机制。

这种策略的工作原理与上述类似，只是不使用最终期望数据结构（struct，mapping等）来定义合约数据模型，所有数据都被抽象化并存储在键值对中，然后使用一个标准的命名系统以及sha256散列算法用于查找数据值。

可以查阅David Rugendyke的文章以更好地理解这种机制。

创建一个完全可升级的合约听起来不错，但需要一个很大的妥协：保证合约的不可变性。因此在很多情况下实现部分可升级的合约可能是更合理的选择。

在此策略中，智能合约的核心功能可以保留为不可升级。其他可能不太完整或更复杂的组件则采用可升级策略实施。

这方面已经有一些很好的案例：

以太坊名称服务ENS：ENS核心合约是一个非常简单的合约，不能更改。域名注册商则可以由管理员升级。域名注册商是一个合约工厂，如果使用一个新的域管理器，它可以与以前的所有数据状态重新链接，而不会有太多麻烦。
0xProject ：603DEX（去中心化交易所）核心智能合约可以完全升级，而代理合约（每个用户一个）保持不变。 0x“代理”合约（不同于前面介绍的代理策略）包含用户资金和相关设置。由于这个原因，它不是0x合约系统的可升级部分。

没有一个策略是完美的，选择正确的策略取决于要实施的智能合约。所有策略都非常复杂，智能合约设计人员应该对他们所选择的可升级策略非常了解，以避免安全漏洞。

为了创建一个可升级的智能合约，代理机制似乎是最好的全面策略，因为它允许程序员将可升级机制与合约设计区分开来，这使得一切变得更容易，并且会产生更少的错误，而错误是我们需要升级合约的主要原因。
在最简单的核心逻辑不变的情况下，采用部分升级策略也是保持用户信任的好主意。
首先设计不可升级的智能合约系统，然后制定可升级的策略，这是一种实用且理想的方式。