以太坊可更新智能合约研究与开发综述

原文地址：https://ethfans.org/posts/ethereum-upgradeable-smart-contract-strategies

这篇文章是对以太坊可更新智能合约领域里的研究和开发的综述。它意图成为一篇便利的资源帖，集中迄今为止的研究，并推进技术讨论。此外，我已经创建了一个关于不同策略的优缺点比较的简要表格，下面会放出来。如果你正在研究或者开发领域工作或者观摩，请对本文作出评论，给出你对这份表格和我对不同策略的描述的支持、反对或是其它意见。

除了几个月前我自己为 AvanceHub 项目贡献的部分以外，这篇文章没有加入新的技术开发和研究。本文中对不同策略进行了排序，但这不应被解读成它们的接受度以及我或者是开发者社区的偏爱。作为 indorse.io 项目的一部分，本文将从对我们的可更新策略的介绍开始，我们认为这是有必要的。

在文章底部可以看到一份比较综合的列表，里面包含了我认为迄今为止重要的研究和发展。

策略	优点	缺点
代理合约（Proxy Contract）	1. 使用这种策略，不需要重新设计就可以更新合约	1. 代理的合约代码将不会反映出它存储的状态；2. 无法改变目标合约的字段，但可以添加新字段；3. 合约的交互界面必须保持原样；
将逻辑与数据分离	1. 数据可以从数据合约中正常读取；2. 用在数据合约中的数据结构可以更新和添加	1. 合约必须被分成数据合约和逻辑合约；2. 合约交互界面必须保持原样；3. 变更复杂的数据类型（例如，结构体）的方式比较复杂；
将逻辑与数据分离，并使用"key-value"对	1. Key-value更加普遍也更加点；2. 用在数据合约中的数据结构可以更新和添加	1. 合约必须被分成数据合约和逻辑合约；2.合约交互界面必须保持原样；3. 因为数据储存在 Key-value 对中，读取数据的过程非常抽象；
部分可更新智能合约系统	1. 让合约系统的简单部分变成不可更改的，以维系信任	1. （显然）不可更新的合约代码永远也不能更新

100% 可更新机制

使用更多的智能合约基础设施，创建一套完全可以更新逻辑的智能合约是有可能的。这种策略有两个分支：代理、逻辑与数据分离为不同合约。而分离合约中的数据和逻辑有两种方式。

所有这些方法解决的基本问题都是如何更新智能合约的逻辑、同时维持通往合约状态的通道。

我没有看过这些策略中的任何一个用于生产或是通过合理的安全审计。在下文中我哦哦给出了这些策略如何生效的简短描述，但我推荐大家到文末阅读最新的资源，以充分地熟悉它们的工作原理（尤其是，如果你正要开始跑进可更新合约的兔子洞的话）。

代理合约

一个代理合约使用 delegatecall 操作码，将函数调用请求发送给一个可以被更新的哦目标合约。因为 delegatecall 会保持函数调用的状态，目标函数的逻辑是可以被更新的，并且状态会保留在代理合约中以供可更新目标合约的逻辑使用。也因为 delegatecall， msg.sender 将保持代理合约调用者的身份。

因为最近的拜占庭硬分叉让一个函数调用返回值的大小变得可知，这种方法现在变成普遍的了（比起 Nick Johnson 初次提议的时候）。你可以在 Daonomic 的资源中看到普遍代理合约的一个例子，当然，该文同时也是一篇值得阅读的好文章，讲到了这种机制的更多细节。

逻辑与数据分离

这种方法包括将智能合约分成一个带有合适 getter 和 setter 的数据合约，包含了数据（变量、结构体、映射，等等）；以及一个逻辑合约，包含了如何更新数据的所有业务逻辑。逻辑合约通过 setter 更新数据，数据合约只允许逻辑合约调用 setter。这让在保持数据储存在同一个地方的同时让逻辑可以被替换，允许一个完全可更新的系统。

这样的话合约就可以更新，通过指定用户使用新的逻辑合约（通过一个 resolver 比如 ENS实现）、更新数据合约的许可以使新的逻辑合约可以运行 setter。

观看 @Thomas Wiesner 的视频以获得对这种机制更好的理解。

逻辑与数据分离并使用 Key-value 形式的数据

这种策略与上一个方法有相似的工作原理，但是不使用在一般情况下你的合约使用的最终需要的数据结构（结构体、映射，等等），所有的数据都被抽象并且以基本的 Key-value 的形式存储。使用一个围绕 sha256 哈希算法的标准命名系统来发现数据的值。

观看 David Rugendyke 的文章以获得对这种机制的更深入的理解。

部分可更新的策略

创建一个完全可更新的合约听起来很棒，但它要在信任问题上要求一个大妥协：合约的不可更改性。使用部分可更新的合约系统在很多情况下也许是有意义的。

在这种策略中，智能合约的核心功能可以变成不可更新的。其他的也许更不基础或者更加复杂（因此更有可能要求更新）的组件则使用一个可更新的策略来实现。

我已经看到了这种策略的一些好例子，当然如果你知道别的也请告诉我：