您好,登录后才能下订单哦!
本篇内容介绍了“以太坊智能合约开发时升级策略是什么”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!
目前有两种主要策略用来实现可升级的智能合约:
使用代理合约
将逻辑和数据分离成不同的合约。
这两种方法要解决的根本问题是如何更新合同的逻辑,同时仍然保留对合同状态的访问。
代理合约使用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进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。