分叉与共识

共识规则决定了什么样的交易和区块是有效的,是比特币网络中的节点能互相独立工作并达成一致的基础。长期来看,为了演进比特币系统,添加新特性,修复 bug,共识规则并不总是一成不变的。但与传统的软件升级不同,比特币没有官方机构,其软件的升级,需要协调和考虑多数系统参与者的意见。

这篇文章,介绍升级共识规则的两种方式,软分叉(Soft fork)和硬分叉(Hard fork)。

兼容性

在开始之前,先介绍两个软件开发中的概念,向后兼容(Backward Compatibility)和向前兼容(Forward Compatibility)。

这里的 “前” 和 “后”,是根据英语的习惯描述的,以现在的软件为基准:

  • “后”(Backward)指的是向后退,是过去
  • “前”(Forward)指的是向前进,是未来

Office Word 2007 可以打开 Office Word 2003 创建的 doc 文档,是向后兼容。Office Word 2007 可以打开 Office Word 2010 创建的 docx 文档,是向前兼容。

一般来说,软件做到向后兼容,比做到向前兼容要容易。

软分叉

软分叉的意思是,比特币协议发生了一些变化,但旧节点却不能发现这个变化,从而继续接受新节点用新协议挖出的区块。 新版本软件产生的交易或区块,可以被旧版本软件验证通过并接受,反过来也成立。旧节点将会在他们 不能完全理解 的新区块上继续添加区块。

软分叉不是真正的分叉,如果有节点没有升级软件,软分叉后的区块链看起来就像下面的样子。

软分叉很好理解,就像你使用 Office Word 2007 和 Office Word 2010 一样。

  • 你能用 Word 2007 打开和编辑 Word 2010 创建的 docx 文档,反过来也一样
  • 但你不能在 Word 2007 中使用 Word 2010 提供的新功能,就像软分叉后,旧版本软件无法知道新的共识规则一样

还记得 CLTV 时间锁么,由 BIP-65 通过软分叉激活。

新版本软件因为知道新的共识规则,会在验证交易时验证时间锁是否已经释放,但运行旧版本软件的节点并不会这样做。

这正是软分叉被诟病的地方,软分叉 放松了验证

一家公司里有一些审计人员,还有一些交易员。交易员想开展一项当前不被公司认可的新业务,审计人员会拒绝这种新交易。有一天,某个机智的交易员想出了一个方法,“我要做一些衍生品合约交易,但会在交易记录上写成买入土地。当你们看到的时候,就在脑子中把土地替换为衍生品合约,一切照常,审计人员不会发现的”。

这里的审计人员就是 拥有算力 的全节点(运行着旧版本软件),而交易员的行为就是软分叉。

硬分叉

硬分叉会带来区块链的永久分叉。

新版本软件产生的交易或区块,旧版本软件无法识别或验证通过,就像你使用 Word 2003 无法打开 Word 2007 创建的 docx 文档一样。

对某次硬分叉升级,如果绝大多数人都同意(都会使用新版本的软件),硬分叉后的区块链形如下图。

因为不存在分歧,所以旧链不会被继续延长(没有算力支持),硬分叉后仍只有一条链。

但如果双方矛盾不可调和且都有 算力支持 ,硬分叉后便会有两条链存活下来。

  • 因为区块大小的争论无法调和,Bitcoin Cash(BCH)从 Bitcoin(BTC)的区块高度 478558 硬分叉诞生
  • 因为发展理念的不同,Bitcoin SV(BSV)从 Bitcoin Cash(BCH)的区块高度 556767 硬分叉诞生

请注意,“学习笔记” 系列文章,一般使用 bitcoin 来指代协议,使用 “比特币” 来泛指 Bitcoin(BTC)、Bitcoin Cash(BCH)和 Bitcoin SV(BSV)这些不同版本的比特币(同一协议的不同实现)

总结

软分叉和硬分叉是改变共识的两种方法 ,它们都是 “向后兼容” 的,否则新版本的软件将 “不认识” 过去的区块,无法从头验证整个区块链。

软分叉还是 “向前兼容” 的,旧版本软件会接受新版本软件产生的区块,只是不能完全 “理解” 而已,这在某种程度上放宽了共识的验证。

硬分叉不是 “向前兼容” 的, 没有分歧的硬分叉升级不会产生两条链(不会产生新的币)

一个自由的社区,会在发展过程中不可避免的产生分歧。当分歧实在无法调和时,相较于陷入无尽的争吵和诋毁,停滞不前,通过硬分叉分道扬镳(获得算力支持并存活下来)可能是更好的选择。毕竟,各自按路线图好好发展,构建完整生态赢得更多用户才是最重要的,虽然这样的硬分叉会带来社区的割裂和短暂的混乱,但这是自由的代价。


基于UTXO高度的激活 - 创世纪第3部分的路线图

2019年7月26日

解开是一件非常棘手的事情。有很多东西在十年之内就被搞砸了,而且有些东西被破坏得太厉害了,以至于它们根本就不能干净利落。比特币SV团队进行了大量的研究,广泛研究现有和原始代码,这是一个非常陡峭的学习曲线。但我们对我们现在需要实施的路线图充满信心。但是有一些务实的警告。

我举个例子。算术运算代码。原始BitCoin使用了一个允许任意大小数字的数字实现。也就是说,它不像许多系统那样限制在32位或64位数。也可以使用256位(和更大)数字,它们对加密函数非常有用。在比特币历史的早期,这个被改变并限制在32位数字以及引入可怕的CScriptnum类。删除直接在脚本中进行加密数学处理的能力(没有巨大的开销)对比特币来说是一个巨大的损失,这是我们明年2月将要解决的问题。但问题是如何?

许多问题的解决方案

我们的下一个路线图文章将描述OP_RETURN即将发生的变化,因为这是我们希望比特币生态系统尽可能提前了解的变化。这个变化的机制就是这篇文章的内容,我们分别解释它的原因是因为它是一个我们将在很多方面重用的概念。我本来可以将它合并到下一篇文章中,但它会一次又一次地出现,所以值得给它自己的帖子......

比特币的黄金法则

以向后兼容的方式转换算术系统是一件非常棘手的事情。我们可以建立测试,直到我们脸色发青,但我们如何确定我们已经涵盖了每一个边缘案例?是否可以确保所有情况都可以向后兼容?我们不知道。但我们当然关心,因为我们在比特币(GOLDEN规则)中生活和呼吸的规则之一,永远不会让可花费的比特币变得无法承受。决不。甚至不是偶然的。

谢谢P2SH

如果你看一下比特币的历史,这个问题可能没有我们想象的那么大。比特币历史上实际使用算术操作码的交易少于100个 - 我们可以看到。所以,我们不能只是编写测试来确保所有这些都是可花费的吗?可能(虽然不是在所有情况下)但更大的问题是支付脚本哈希交易。P2SH具有一个有趣的特性,即输出脚本的内容在区块链中不会显示,直到花费它为止。这与原始设计形成鲜明对比,原始设计中锁定脚本必须在创建时在区块链中公开发布。这导致在尊重'永远不会使可比的比特币不可靠'原则方面存在一些困难。因为我们不能假设P2SH脚本中有什么。我们必须假设它们中的一些包含算术操作码,因此确保我们需要为每个可能的使用和边缘情况编写测试以确保向后兼容性。许多边缘情况不会存在,实际上可能是最多的。但是我们无法知道哪个,所以我们别无选择,只能测试它们。

正如我之前所说,这很难,也许不可能证明这一点。

避开问题

解决这个问题的简单方法是,对于我们来说,除了算术运算代码的特定情况之外,还有许多功能对我们有用。甚至不要尝试向后兼容。我们只是接受比特币历史的一部分有一些破碎的东西。我们继续支持它,认为有一天,最终所有这些破碎的产出都将用完。也许这已经过去了几十年,但随着时间的推移,我们将能够弃用旧代码。

但是,如果我们继续支持旧规则,我们该如何解决?很简单,我们在某个时间点实施新规则。之后的一切都遵循新规则。之前的一切都遵循旧的规则。大多数比特币共识更改使用我们称之为“基于高度的激活”。也就是说,在区块链达到某个区块高度之后,新规则就会启动。但这可能会破坏遵循旧规则的旧交易。这给开发人员带来了巨大的负担,这种新变化有效地将他们锁定在一系列限制之内,这些限制看起来非常类似于比特币核心之前称之为“软分叉”的限制。软叉适用于numpties,我们不打算购买,因为当你试图取消10年的损害时,它们会受到不必要的限制。

因此,我们不是仅仅实现新规则,而是根据当前块高度,而不是在创建脚本时的块高度。更具体地说,您尝试花费的输入UTXO的块高度被挖掘成块。这是一种非常灵活的激活机制。这意味着使用算术操作码创建的所有输出将继续使用创建它们时存在的代码执行。如果它们有效,则它们始终有效,无论它们是针对哪个规则集设置的。幸运的是,生态系统中不需要进行大量的工具更改,因为很少使用算术运算代码。但这不是我们计划以这种方式激活的唯一变化。支付给脚本哈希本身将以这种方式弃用。在 2020年2月)新的将是无效的(严格来说,它们实际上将成为一个哈希难题,但这是另一个故事)。这是我们将如何使用基于UTXO高度激活的两个示例,以确保顺利且完全向后兼容的路径返回Genesis。


results matching ""

    No results matching ""