智能合约开发时升级策略

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

100％可智能合约开发升级机制

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

• 使用代理合约
• 将逻辑和数据分离成不一样的合约。

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

代理智能合约

代理合约使用delegatecall操做码将函数调用转发到可更新的目标合约。 因为delegatecall保留了函数调用的状态，所以能够更新目标合约的逻辑，而且状态将保留在代理合约中以供更新后的目标合约的逻辑使用。 与delegatecall同样，msg.sender将保持代理合约的调用者身份。

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

智能合约开发分离逻辑和数据

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

• 包含数据（变量，结构，映射等）以及getter/setter的数据合约
• 包含如何更新这些数据的业务逻辑的逻辑合约

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

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

查看Thomas Wiesne的视频以更好地了解这一机制。

使用键值对数据模型分离逻辑和数据合约

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

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

部分智能合约开发时可升级策略

建立一个彻底可升级的合约听起来不错，但须要一个很大的妥协：保证合约的不可变性。 所以在不少状况下 实现部分可升级的合约多是更合理的选择。

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

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

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

其余挑战

• 在全部状况下，都须要对是否保持智能合约的不变性进行取舍。
• 建立可选的可升级智能合约系统对用户来讲是可能而且有价值的，可是增长了复杂性。
• 对Solidity编译器的更改可能会破坏新旧合约之间的兼容性。
• 制定可升级策略时须要考虑gas开销。

结论

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

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