更新研究概览

在更新机制研究中,我们设法提出了一个更新系统,它能够进行不影响生产环境的,几乎无缝的软件更新,并为权益所有人提供投票选择硬分叉(向后不兼容的协议更新)的选项,无需引入任何非协议级别的工具。

我们建议使用权益来对软硬分叉进行投票。

更新系统模型

对于 CSL,我们决定在协议层本身增加对协议更新的支持。它给区块链处理带来了一些开销,但有几个重要的好处:

  1. 对于每个实现该协议的用户,其最新版本的区块链是已知的。
  2. 没有中央实体负责维护或分发更新,任何此类更新都是在大多数权益的默认或明确同意下提出的,然后以分布式的方式分发。
  3. 我们不依赖客户及时更新 PC 上的软件;这是自动完成的,更新通过区块链直接发布。
  4. 如果在某些版本的 CSL 协议或某些特定实现中检查到任何安全漏洞,将会有一种机制来快速分发更新(仍然在大多数权益的同意下)

应用程序更新:签署和宣布

这里,我们考虑如何安全地更新应用。协议更新是本文档相关部分涵盖的一个独立问题。

要进行更新,首先需要批准其提案。至少有一个协议达成,更新提案才能通过。

  1. 明确通过:它拥有权益的大部分肯定投票(即严格大于 50%)。
  2. 隐式通过:权益的肯定投票大于否定投票,并且至少在 U 个 slot 的区块链中。

这个方法似乎自然地适用于 CSL 模型,就像 PoS 加密货币一样。每个权益相关者都负责按照他们股权的相对比例维护系统,区块链则通过权益所有人之间的共识来维持。

软件更新也是这个维护过程的一部分,所以权益相关者应该考虑这个可信更新。

隐式通过

权益所有人负责系统更新的事实并不会限制我们每个更新都需要大部分股权签名的系统。我们可以介绍一个隐式通过的概念。

更新必须至少有在区块链发布的权益签名的最小限度(configuration.yaml 中的 updateProposalThd)。权益所有人签署更新是不够的,他们应该赞成或反对。

接入第三方客户

IOHK 将维护一个唯一的官方客户端。但社区维护的第三方客户端也有生存空间。人们需要从权益所有人收集足够多签名来发布他们的系统更新,当然也有可能不是一个『更新』,而是一个从头开始的不同的客户端,或者是官方客户端的一个分支。只要这个更新有足够多的权益所有人的签名,网络就认为它是可信的,可以通过与官方客户端相同的机制进行更新。

应用更新:分发和应用

IOHK 维护的一系列 HTTP 的镜像足够作为开始。

在这个过程中,我们计划维护一个基于 Bittorrent 的,或类似 Bittorrent 的解决方案来分发更新。总的来说,基于法律上的考虑,P2P 分发更新是一个至关重要的业务需求。这决定我们将使用哪种类似于 Bittorrent 的解决方案。

此外,有趣的是,更新本身并不需要安全且可信的通道来分发,因为它已经预先知道了一些已知的可信密钥(或一组密钥)。

应用更新通过 bsdiff 准备,可以直接或通过安装程序更新。我们正在考虑将来转移到 courgette

协议更新

首先,我们需要区分软硬协议更新。

软分叉会修改区块链共识规则,以便新版本仍然与旧版本客户端兼容,硬分叉则不会与旧版本保持向前兼容。

BIP-99 提供了很好的标准来区分这两种分叉。

  • 一个软分叉引入新的规则,对区块进行限制。这样一来,之前无效的仍然无效,而之前有效的一些区块也会变成无效。
  • 硬分叉是一个让之前无效区块变成有效的分叉。

软分叉具有向后兼容等部署优势,不需要大家的共识,因为大多数用户可以添加新的规则。相比之下,硬分叉需要所有用户升级。

理论上,硬分叉可能会导致网络分裂为两个部分的情况,每部分都维护一个单独的链:一个来自采用最新系统更新的节点,另一个则来自拒绝这样做的节点。这意味着第一部分的一些区块被另一部分认为是无效的,反之亦然。

我们将协议版本定义为一个元组 (Maj, Min, Alt)

  • 主版本号(2字节):很少修改,改变不是向后兼容的,会产生一个硬分叉。
  • 次版本号(2字节):每个更新需要调整的整数
    • 更新应该是向后兼容的,因为新版本生成的区块应该被旧版本以某种方式接受。
    • 一个特定的区块可能包含未知类型的地址。对于这种情况,应该找到一个简洁的解决方法,以免影响系统的稳定性和正确性。
  • 替代版本(1字节):管理多个同时存在的协议更新版本。

协议版本将在应用程序更新中公布,稍后将放入到由更新的软件创建的每个区块中。

主版本号的改变会在将来触发硬分叉的问题。

次版本的版本更新通知网络后续应用程序更新修改了软分叉的协议。

替代版本是新功能的标志。它允许独立开发人员向协议引入多个更改。例如,如果一个供应商决定经由软分叉引入特性 X,另一个引入特性 Y(经过软分叉),他们的软件将以版本 a.b.X 和版本 a.b.Y 生成区块,其可以在区块链上共存,但是,最终只有一个会被采纳。

软分叉更新

在软分叉中,我们可以做什么,不可以做什么,有一条细线:

  1. 老版本的客户端应该总是能找到最近的有效区块。(这是 BIP-99 所说的『一些无效仍然无效』)
  2. 较旧版本的客户端发出的某些模块可能会被认为是无效的。

显然,强行推行规则2可能会导致网络分为两部分:一个权益所有人的股份足够大,可以更新,维护自己的链,拒绝其他链,但其他权益所有人还是能够维持链,拒绝这个权益所有人的区块(因为他没有占多数的股份,因此不能追上其他人,所以他的链更短)。一个简单的解决方案规则可能是这样的:如果最新的2016个区块有95%具有较新的区块版本,则旧版本会被拒绝。

注意:此处和之后的区块版本和协议版本具有相同的含义。

为什么我们想在某个时刻想让某个块版本无效这一点可能不是很清楚。这里关键的一点是,一个新的功能实际上是对我们之前所做的一个限制。例如,目前我们可能有基于公钥或基于脚本的普通旧提交。然后在某个时候,我们决定包含第三种地址类型(不管目的是什么)。我们使用哪种策略来验证具有未知类型地址的提交的区块?显然唯一的选择是不验证这个地址。

想象有人提出一个交易到这个地址,可能这么做是带着满足一些条件之前保障资金的意图,一旦条件满足,它们在版本1上的区块花费了其他交易,这是关键的一点。如果网络没有假定旧版本被启用了(因为我们只能在启用旧版本时开始拒绝区块),我们就不能使用限制。(TODO)

我们也不能接受所有高于目前所采用的区块的区块,因为在我们的实现中,每个区块都有一个专门用于存储辅助信息的字段。攻击者可以生成她使用了更高版本的协议,并生成一个 attributes 被无意义密钥污染的区块。如果我们接受它,它会使我们的区块链变得臃肿。

这是下面要描述的逻辑的动机。

在我们实现中,区块版本可以以下面的状态存在:

  • 已采用,确认区块版本的软分叉规则被触发了(见下文)
  • 已确认,当有包含软件的确认版本和此区块版本的更新提案时。注意,『软件的确认版本』是其他地方的技术术语。如果有多个区块版本,相应的软件被确认,但这些版本不被采用,我们称之为竞争。举例来说,有可能有版本 2.0.0, 2.0.1, 1.2.0, 1.2.1, 1.1.11.1.2,最后通过的版本是 1.1.3。在这种情况,那些竞争的版本是 2.0.0, 2.0.1, 1.2.01.2.1。旧版本 1.1.11.1.2 没有竞争,因为 1.1.3 已经被采纳。
  • 其他情况。举例来说,提出一个新的区块版本,但软件版本没有确认。这种状态没有特殊的名字。

软分叉的工作原理如下:

  • 非正式的,当一个确定比例的权益以版本 X 创建区块,区块版本变成已采用
  • 正式的,我们做以下事情。首先回顾一下,我们的系统在设计上,不允许回滚超过某个固定的全局阈值 k,这样可以为每个权益所有者确定稳定的股权。当我们处理创始块 e 时,我们从网络的一开始就计算所有 slot 的所有领导者的稳定股权。对于版本 X 的区块当前竞争的版本,我们取所有版本 X 的稳定版本,收集这些领导者的区块,统计他们的股权。如果其中一个版本大于 75%,则被采纳。如果多于一个版本大于 75%,我们采用其中一个(TODO)。

请注意,采用的区块版本在 epoch 期间(只在 epoch 之间)是不可变的,因此在一个 epoch 中的所有区块都根据相同的规则进行验证(因为规则是由采用的区块版本定义的)。但假设一个 epoch 中的所有区块都具有相同的区块版本是错误的。在采用区块版本之后,另一个区块版本可以竞争,并且一些节点可以使用这个新版本创建区块。

所以,总结一下:

  1. 一旦确认了更新,协议的版本(比如说 0.5.0)就可以使用了。
  2. 该节点的行为被更新(即可以发出,验证新版本的区块):
    1. 在软分叉解决之前(即在解析规则被出发之前),使用新版本 0.5.0 发布区块,但不包括任何新的 attributes(如果有的话)。同区块版本 0.4.0 一样验证 0.5.0
    2. 一旦软分叉解决,发布和验证每个版本为 0.5.0 的区块,包括新的 attributes
  3. 该节点的行为还没有被更新(即不能发出并使用新版本验证模块):
    1. 软分叉解决之前,发行并验证每个版本为 0.4.0 的区块。除此之外,任何包含未知 attributes 的区块都不会被接受
    2. 一旦软分叉解决,开始接收所有版本为 0.5.0 的区块,包括有未知 attributes 的区块。同时也验证 0.4.0 的版本。

硬分叉更新

硬分叉通过修改后的 PoB(proof of burn)来解决。由于尚未实现,我们从本文中省略本节,并将其作为单独的文档发布。