协议升级

Sui 协议、框架和执行引擎经常进行扩展，包括新功能和错误修复。这些功能以新代码的形式添加，作为我们定期软件发布的一部分提供给验证器运营商。然而，Sui 协议要求所有 Sui 验证器在执行每个交易的结果上达成一致。

这带来了以下挑战：在无法确保所有运营商同时升级其软件的情况下，如何发布改变交易执行的代码？此外，在功能发生变化后，如何确保所有 Sui 交易历史都可以重放？

为解决这个问题，Sui 使用了一个称为协议升级的过程。

协议升级过程

用于协议升级的过程概述如下步骤：

Sui 开发人员编写新功能的代码，但使用“功能标志”限制对该功能的访问 - 这是一个最初设置为 false 的布尔配置变量。
从称为 ProtocolConfig 的结构中检索功能标志的值。
开发人员创建 ProtocolConfig 结构的新版本，其中新功能标志设置为 true。
构建并发布 Sui 验证器软件的新版本，供验证器和完整节点运营商使用。
当验证器进程启动时，它继续使用先前版本的 ProtocolConfig（其中标志为 false）。这样，无论验证器是否安装了新软件，所有验证器都保持相同的行为。
随着验证器的升级，它们向验证器委员会的其余部分发出信号，表示它们准备切换到新版本的配置（其中标志已启用）。
如果足够多的验证器投票切换到新的协议版本，则新版本将在下一轮开始时生效。
新功能现在开始生效。

完整节点遵循类似的过程，但它们不参与投票。相反，它们遵循验证器记录的操作。

当验证器切换到新的协议版本时，它们通过在特殊的轮末事务中记录新版本号来完成。完整节点在重放链历史时执行此事务，因此能够在正确的时间切换到新的协议版本。

并非所有新的 Sui 功能都以更改验证器代码的形式出现。还有对 Sui 框架的更改。例如，Sui 开发人员定期向框架中添加新的本机函数，以向智能合约公开新功能。框架更新的过程类似于协议升级。

但是，与使用功能标志不同，Sui 对象用于协调框架更改。Sui 框架是一个具有 ID 0x2 的特殊对象。框架的 Move 源代码内置到验证器二进制文件中。

如果验证器注意到其内置框架与对象 0x2 中的框架不同，它向其他验证器发出信号，表示它希望将框架升级到新版本。就像对 ProtocolConfig 的更改一样，如果足够多的验证器同意执行升级，则新框架对象将写入当前轮的末尾。然后，在新轮执行的交易中使用框架的新版本。