以太坊智能合约升级策略
发布于 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开发,可以访问汇智网提供的在线互动教程:

回到顶部