合同变更登记

Question

如果我将智能合同存储在第10项中，则更改后的合同将存储在下一个块上，或者合同的状态将存储在第10项中(在这种情况下，旧状态将被删除？)

Answer 1

这在概念上是错误的。一个隐藏的假设可能是，修改代码是一种选择。

我将解释默认条件，然后讨论一些棘手的解决办法。

默认情况

合同是不变的。你不能修改它们。如果你能随意改变它们，它们就不会是合同了。从合同中产生的信任很大程度上是因为知道没有人，甚至作者也不能改变任何事情。

即使是一个微小的缺陷也可能有一些不寻常的后果，这意味着需要重新关注质量保证，因为在合同发布后，可能很难或者不可能更改代码行。

工作流

不用说，在开始和开发过程中总是有大量的迭代。Mainnet不是进行实验的地方。像ganache和私有链这样的工具--您可以用一个节点来设置--是合适的。当您认为它已经为公开发布做好准备时，您可以在testnet上部署它。这些都是在主板上发布合同时，应该是一个隆重场合的前兆。通常情况下，这将关闭代码进一步发展的大门。它被描述为发射了一艘宇宙飞船。从那时起，船上的东西是你力所能及的。

新合同是新实例

您可以使用相同的源代码来部署同一契约的另一个版本。它获得自己的地址，并遵循相同的逻辑。它不会取代或干扰原来的。在某些情况下，用户库已经迁移到新实例。这通常包括读取原始的完整数据集，将数据写入新的实现，并将用户重定向到新的契约。这可能会令人困惑，也会引起争议。

可升级合同

有几种可升级合同的方法。模块化设计是一个良好的开端。契约可以保存组件契约的地址并来回传递消息。地址是数据(address myServantl)，因此它们可能是可变的，并且可以用来为可能的升级创建工作流。

永恒的存储模式将不可变的数据从可能修改的逻辑契约中分离出来。ENS名称服务可以帮助分类哪些逻辑契约是“官方”的。

有些代理契约模式使用不可升级的入口点，使用DELEGATECALL将所有操作委托给可互换的实现契约。

图书馆和模块化设计的无数其他组合是可能的。

TL;DR;

合同可升级到您设计升级过程的程度。默认情况下，仅在附加的宇宙中不存在可升级性。

Meta关注

大多数可升级的模式意味着有特权的用户可以随意更改合同的规则。这意味着重新引入一种非平凡的集中化程度。看看这个：https://medium.com/consensys-diligence/upgradeability-is-a-bug-dba0203152ce

无信任升级

不信任的升级模式严重制约了作者的权威。作为(出于某种原因)有权为每个人决定的合同owner，特权用户(或组织或DAO)只能提议升级。个人用户决定是否愿意接受它。如果升级解决了一个重大问题或实质性地改进了问题，这就是一个解决方案。如果作者希望每个人切换到一个新的版本，偷他们的钱，用户将被期望拒绝它。它允许这样的情况:一些用户希望升级，而有些用户不想升级。

作为软件架构师，您的任务是在这些选项中选择项目的最佳属性组合。例如，许多情况不应该升级。考虑一个值标记。如果可以改变规则，这可能是一个缺陷。在其他情况下，用户同时使用不同版本的逻辑是不明智的。在某些情况下，无信任将为产品代码的定期迭代提供升级路径。

https://github.com/rob-Hitchens/TrustlessUpgrades

在此基础上，任何事情都不能改变，然后仔细考虑理由和方法，特别是在决定使用哪种可升级模式时应该存在的权威和权限限制。

希望能帮上忙。