如果我创建了一个智能契约,支付用户共享数据的费用,那么在智能契约出错的情况下,我如何才能更新这个智能契约,或者我是否希望更改为数据共享支付的金额?据我所知,我基本上必须在一个新的Ethereum地址创建一个新的智能契约,并以某种方式将我的用户重新连接到这个新的契约。如果是这样的话,这很像集中系统,在这里,聪明的契约编写者可以在他们愿意的时候更改规则(支付率)。显然我漏掉了什么..。能给我解释一下吗?谢谢!
发布于 2020-01-07 19:43:15
如果我创建了一个智能契约,向用户支付共享数据的费用,那么在出现错误的情况下,我如何才能更新这个智能契约
虽然升级已经部署的智能契约的代码是不可能的,但可以设置代理契约体系结构,使您可以像升级主逻辑一样使用新部署的合同。

代理架构模式是这样的,所有消息调用都会通过代理协议将它们重定向到最新部署的契约逻辑。要升级,将部署新版本的合同,并更新代理以引用新的合同地址。更多关于代理模式的信息
也许我想改变支付给数据共享的金额?
您不需要更新智能契约来更改为数据共享支付的金额。实现此功能的一个更好的方法是为收费设置公共状态变量,并公开ownerOnly函数以更新它们。
据我所知,我基本上必须在一个新的Ethereum地址创建一个新的智能契约,并以某种方式将我的用户重新连接到这个新的契约。如果是这样的话,这很像集中的系统,聪明的契约编写者可以在他们愿意的时候更改规则(支付率)。
这在某种程度上是正确的。但在区块链的情况下,所有事件都是透明的,合同的任何更改都将在分类账上显示出来。一些领先的dapps,如Kyber,Synthetix使用代理模式来确保它们能够在出现错误或安全问题时修复代码。您还必须考虑到,如果智能合同所有者正在部署代理合同,那么他们拥有多少权力。
发布于 2020-01-07 18:30:22
区块链确保你不能重写过去,所以你必须放弃修改它的想法。
支付用户共享数据的费用,我如何才能更新这个智能契约?
听起来你不想改变合同。相反,您希望您的用户同意一个过程,在这个过程中,不管是什么,他们都会得到当前的普遍薪酬。
将“合同”视为类似于法律协议的“合同”通常是错误的,就好像每个用户关系都是合同的一个单独实例一样。如果把它看作是一个可靠的执行过程,用户可以查看并看到您不能任意地更改它,这将更有帮助。
您的流程必须解决一些重要的问题:
如果您制定了这些业务流程,那么您可以在强制执行流程的智能契约中对它们进行编码。
如果未来协议的条款停留在您设置的参数之内,则无需修改smart合同。也就是说,你预先预料到任何人都会需要的灵活性。对于大多数意图和目的,您将没有改变智能契约的选择,而且许多保证参与者都来自于此属性。
必须在一个新的Ethereum地址创建一个新的智能契约,并以某种方式将我的用户重新连接到这个新的契约。
如果合同的有用性随着时间的推移而恶化,那么向新事物过渡的过程将是痛苦的,除非你提前制定了一个过渡过程。
想想你发射到深空的飞船,它飞得越快越好。你永远都赶不上,所以唯一能上船的东西就是你放在那里的东西。你还是可以跟它说话的。例如,你可以部署一个新的模块并集成它,但前提是宇宙飞船是为在飞行中更换组件而设计的。如果它没有响应命令,那就没有什么可说的了。
这又会让人感觉到集中的系统。
每一个改变代码甚至重要参数的机会(代价?)可能重新引入集中化。思考这个问题的一个好起点是“谁来决定?”
为权威用户或白名单保留某些功能并不少见,这几乎总是某种程度的集中决策。一个例外可能是当用户本身是一个与一个更包容、更民主的过程有关的契约--应用程序承认一个全能的用户,但该用户只表达一群参与者的集体意愿。
任何给定功能的治理设计和升级可能性的可取性都需要逐案考虑。因为我们有能力产生集中的权力,完全分散的进化或介于两者之间,所以重要的是要考虑权衡和证明每一个决定是正确的。
关注一个值得提升到永恒真理的过程几乎总是更好,而不是锁定到可升级的模式,如模块化设计、代理和永久存储。这也是至关重要的实践极端的质量保证,在你推出之前。
希望能帮上忙。
发布于 2020-01-07 18:24:26
一个具有所有所需功能的单块契约就是它现在的样子,没有办法改变/更新/升级它。您唯一的选择是部署一个新合同,并以某种方式让用户使用新合同(并从旧合同复制状态)--这是一项很大的工作。
这就是不同的契约模式。基本上,您想要的是将单个契约的不同部分分离成多个单独的契约,这些契约通过某种机制相互连接,每个契约可以通过某种机制单独升级。
例如,快速googling给出了一个很有前途的页面(虽然有点老了):https://github.com/fravoll/solidity-patterns。在那里,你应该特别看看“永恒的存储”模式。
https://ethereum.stackexchange.com/questions/78783
复制相似问题