升级互联网计算机协议

互联网计算机协议结合了运行在世界各地数据中心的特殊节点机器的计算能力，为智能合约软件和数据创建一个无缝且可扩展的环境。由于该平台可以为用户提供交互式 Web 内容，因此可以使用智能合约构建网站、企业系统、大众市场互联网服务、泛行业平台、DeFi 等。

乍一看，升级似乎是一个简单的问题。然而，传统区块链的升级表明，实现协议升级可能需要数月至数年的时间。首先，社区必须同意采用新版本的协议；接下来，必须商定应该应用升级的时间点；最后，所有客户端软件都需要升级以支持新的协议版本。

由于这是一项如此艰巨的任务，因此传统上协议升级通常被实现为链的分叉，互联网计算机区块链旨在通过以下方式缓解这种情况：

• 在网络神经系统（“NNS”）中提供一个综合治理系统，社区可以使用它来投票决定是否应该执行协议升级。

一旦治理系统触发升级：

• 互联网计算机协议内置了对调度升级的支持，这意味着每个子网的共识层根据子网参与者之间的协议自主决定何时应该执行升级。

  
  

• 互联网计算机的节点内置支持下载和应用升级，无需人工干预，如果治理系统指示这样做，升级包包含运行节点所需的整个软件堆栈，在验证包内容与社区投票运行的版本相对应后，节点然后自动重启到协议的新版本。

事实上，自推出以来，互联网计算机已经进行了几次重大升级，每个子网的用户感知停机时间很少，可以使用设置为“更新子网副本版本”的过滤器“NNS 功能”在 ic.rocks 上显示到目前为止所有子网升级的完整列表。

在设计和实施协议升级解决方案时，有几个挑战，互联网计算机区块链运行分布式和去中心化协议的事实使得很难确定系统的当前状态。此外，没有全球时间，因为节点可能会经历时钟漂移并且可能远远落后于其他节点。

本文描述了我们对这些问题的解决方案以及我们如何能够实现以下目标：

• 允许对互联网计算机协议进行任意更改

• 保留所有状态

• 最大限度地减少停机时间

• 自主推出升级

在深入研究技术细节之前，让我们先讨论一下升级是如何触发的。

触发升级

在互联网计算机，有一个名为注册表的组件，这是为实现容器智能合同在网络神经系统的子网（“NNS”）。本质上，它存储互联网计算机的所有配置信息。它被实现为一个版本化的键值存储，其中每个突变在注册表中显示为一个新版本。

网络在每个子网的基础上升级，每个子网在注册表中都有一个记录，指示哪些节点构成子网以及它们应该运行什么协议版本。

为了触发升级，网络只需更改它要升级的子网的版本信息。一个子网是否应该升级到某个版本是由治理系统中的投票决定的，而不是由个人决定的。

请注意，注册表包含所需的配置，并且 NNS 子网实际上并不知道子网中运行的是哪个版本。

执行升级

互联网计算机协议分为四层：

• 一个 P2P 层，它进行网络连接。

• 共识层，同意消息的顺序。

• 消息路由层，确保消息到达它们的目的地容器。

• 以及一个执行层，它在收到消息时执行容器。

互联网计算机协议升级负责升级这四层，容器升级具有不同的升级机制，我们的开发人员指南中对此进行了描述。

互联网计算机在每个子网中执行状态机复制，状态机复制的思想是，如果每个状态转换都由一系列有序输入触发并且转换函数是确定性的，则保证每个诚实节点上的状态相同。

在互联网计算机中，状态机的输入是用户发送的更新调用以及来自其他子网的容器间消息，其中的状态包括托管在互联网计算机上的容器的状态，输入的顺序由共识保证，正在执行的状态机是消息路由层、执行层和容器代码。

为了在高度 h 建立状态，我们必须采用前一个高度 (h - 1) 的状态并将来自区块 h 的输入消息应用到该状态。如前所述，这些区块中的输入是通过共识达成的。对于状态机复制，我们正在执行的代码在处理高度为 h 的区块时需要是确定性的。

升级可以改变状态机，包括执行层和消息路由层。因此，网络需要确保升级在任何地方同时运行，相对于区块高度。

升级还可以改变共识层的细节，例如公证是如何发生的。因此，升级必须在相同的区块高度上执行，否则可能会使用不同且潜在冲突的公证方案来对相同高度的区块进行公证。

最后，升级还可能需要在升级期间对网络细节进行协议破坏性更改，这可能会使不同版本的节点无法进行通信。为了达成共识，所有诚实节点都需要能够相互通信，这再次意味着升级需要在所有节点机器上在相同的区块高度上执行。

请注意，节点不会在同一物理时间到达区块高度 h，因为互联网计算机是一个没有全局时间的分布式系统。

理论上，有些节点甚至可能真的很落后，例如几个星期，这意味着在一段时间内，子网中的节点将运行不同的互联网计算机版本，网络需要能够应对。

到目前为止，整个过程如下所示：有子网 A，它运行互联网计算机版本 1（“v1”），然后在注册表版本 r 触发升级到 v2，子网 A 中的节点最终将同意在某个区块高度 h 的注册表版本 r 上使用新的互联网计算机版本。

运行 v1 的节点将创建区块和计算状态直到并包括该高度 h，并且运行 v2 的节点在高度 h+1 接管。

在状态 h 和 h+1 之间，需要在两个版本之间进行状态交接，即需要有高度为 h 的状态的快照。

请注意，由于这两个版本明显分开，我们可以想象网络运行甚至从版本 h+1 开始完全不同的共识算法，因为 v2 协议和 v1 协议之间从来没有直接通信。

在互联网计算机中，我们已经可以使用一个概念来做到这一点：追赶包（“CUP”），它们包含恢复共识所需的所有相关信息。此外，高度 h 的 CUP 指的是注册表版本，该版本又指示哪个互联网计算机版本将运行高度大于 h。

它们由子网签名，因此可以通过子网阈值签名来验证它们的完整性。在升级上下文中对 CUP 的一个要求是它们必须能够从旧版本 (v1) 和新版本 (v2) 读取，因此 CUP 需要向后和向前兼容。

一个挑战是网络需要确保子网中的每个节点运行正确的互联网计算机版本，所有诚实节点必须参与版本 v1，直到创建切换 CUP，然后作为 v2 节点加入并开始作为 v2 生成区块。

如果某些诚实的节点运行的互联网计算机版本不正确，则整个子网可能会卡住。

为了让节点决定它应该运行哪个版本，它首先查询注册表以找出它应该加入哪个子网。有了这些信息，它还可以找出该子网中的对等点是谁。正如我们稍后将看到的，这些信息不必完全是最新的。

然后协议询问所有对等点他们最新的 CUP 是什么，最后，可以使用已接收到的所有 CUP 中最高的来确定当前在该子网中运行的互联网计算机版本。

由于 IC 是一个去中心化的系统，并且构建 CUP 是子网中多个节点的集体努力，因此不知道哪些节点参与了创建最新的 CUP。为了容忍 f 个拜占庭节点，2f+1 个节点必须签署一个 CUP 才能使其有效。

因此，如果查询 CUP 的节点少于 f+1，则不能保证其中一个节点具有最新版本的 CUP。

在最坏的情况下，节点进程的 CUP 已过时并且不会立即检测到升级。少于 2f+1 个节点支持的 CUP 总是被忽略，因为在这种情况下 CUP 的签名无法成功验证。

如前所述，子网中的节点可能运行不同的互联网计算机版本。为了避免版本之间的不兼容，使用专用于 CUP 交换的端点通过单独的通信通道从对等方获取 CUP，对等层不用于此目的。这允许交换 CUP 的逻辑保持相对简单，并使其更容易保持向后和向前兼容。

共识详情

现在我们已经了解了如何使用 CUP 来决定应该运行哪个版本的互联网计算机，让我们看看 CUP 是如何实际创建的。

有一系列从 27 到 30 的区块，以及一系列状态（在本例中为 27 和 28）。在区块 30 中，共识选择使用新的注册表版本 r，这会触发升级。共识现在知道它必须在该高度建立一个 CUP 参考新的注册表版本 r，但它目前不能这样做，因为它还没有计算高度 30 的状态。

在可以计算高度 30 处的状态之前，需要完成区块 30。为了在该区块上完成最终确定，该协议会生成没有入口消息的区块，直到有一个大于或等于 30 的区块的最终确定为止。这些区块不包含入口消息，以避免进一步改变高度 30 以上的状态。

一旦高度 >= 30 的区块被最终确定，状态 30 可以被计算并最终被证明。有了这个，系统就拥有了为那个高度建造一个 CUP 所需的所有信息。

诚实节点在升级期间保持其状态，新的 IC 版本可以选择转换该状态作为升级后的步骤，如果他们愿意，否则节点可以在升级完成后直接使用先前版本的状态。

在区块 30 的创建到执行升级之间的时间期间，用户体验受到影响。当创建高度 30 的 CUP 时，查询调用继续可用，但不能接受进一步更新的调用，因为不再允许 v1 的节点在高度 30 之后创建非空区块。

升级 CUP 签名后，子网也会在短时间内无法用于查询调用，因为需要安装升级并重新启动 VM 以应用该升级。

总体而言，子网升级期间的停机时间约为几分钟（目前约为两分钟）。

该 CUP 然后可以用作两个版本之间的切换点。

我们还需要确保来自 v1 的工件不会溢出到 v2，否则我们最终可能会得到多个相同区块高度的非空区块，这将是不正确的，并可能导致链中的分叉，我们通过用生成的协议版本号来注释每个共识工件来解决这个问题。

请注意，这里有多个相同高度的区块，因为系统需要在它想要的版本中生成更多区块才能达到最终确定。但是，v1 中的区块是空的，因此它们不会进一步修改状态。

结论

我们已经提出了互联网计算机协议升级的解决方案，它重用了互联网计算机中已经存在的机制。它允许网络快速连续推出补丁，甚至包括协议更改 —— 所有这些都可以在用户感知的停机时间很少的情况下完成。

开始在 smartcontracts.org 上构建并加入我们的开发者社区 forum.dfinity.org。

作者：Stefan Kaestle

DFINITY 高级研究员（性能）

翻译：Catherine

-    往  期  推  荐    -

下一代 AMM 成功完成由 Polychain Capital 的 Beacon Fund 领投的一轮融资

MetaSports Basketball 将 NFT 收藏变成了可玩的角色

Terabethia 跨链协议桥接互联网计算机和以太坊