本篇内容介绍了“以太坊智能合约开发时升级策略是什么”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
目前有两种主要策略用来实现可升级的智能合约：
使用代理合约
将逻辑和数据分离成不同的合约。
这两种方法要解决的根本问题是如何更新合同的逻辑，同时仍然保留对合同状态的访问。
代理合约使用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开销。
“以太坊智能合约开发时升级策略是什么”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站，小编将为大家输出更多高质量的实用文章！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
