以太坊智能合约升级策略
发布于 4 天前 作者 2596887568 175 次浏览 来自 分享

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

100％可升级机制

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

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

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

代理合约

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

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

分离逻辑和数据合约

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

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

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

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

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

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

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

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

部分可升级策略

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

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

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

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

其他挑战

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

结论

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

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

参考资源

思路与观点

代理合约

分离逻辑和数据合约

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

原文链接

如果你希望马上开始学习以太坊DApp开发，可以访问汇智网提供的在线互动教程：

回到顶部