作者:BitMEX Research

来源:https://blog.bitmex.com/bitcoins-consensus-forks/

摘要:在本文中,我们列出了比特币共识规则的 19 次更改(或者应该叫 18 次,因为有一次意外地 “失败了”),我们相信它们代表了比特币历史上的几乎所有重大事件。至少有三次事件导致了可辨识的链分裂,分别在 2010 年、2013 年和 2015 年发生,分别持续了 51 个、24 个和 6 个区块。

img

- 图片来源:gryb25 -

术语

术语 定义
链分裂(chainsplit) 区块链的分裂,产生两条相互独立但拥有共同祖先的链。原因可能是硬分叉,也可能是软分叉,甚至可以是非分叉的其它原因。
硬分叉 放松关于区块有效性的共识规则,使得一些原本被认为是无效的区块在新规则下会被认为是有效的。
现有的节点必须升级才能跟随硬分叉后的链。
软分叉 收紧关于区块有效性的共识规则,使得一些原本被认为有效的区块在新规则下会被认为是无效的。
现有的节点不是必须升级,不升级也能跟随软分叉后的链。

注意:这些术语被认为始创于 2012 年 4 月,并在 BIP99BIP123 中得到正式表述。

比特币共识分叉列表

2010 年 7 月 28 日(禁用 OP_RETURN)

激活区块号:无 1

BIP 号或软件版本号0.3.5

内容:禁用 OP_RETURN,修复一个致命的 bug,该 bug 可以让任何人花费任何比特币。

类型:软分叉

结果:未有证据表明该次升级期间出现了问题。

2010 年 7 月 31 日(加入 OP_NOP)

激活区块号:无 1

BIP 号或软件版本号0.3.6

内容

  1. 禁用 OP_VER 和 OP_VERIF 3
  2. 加入 OP_NOP 功能。

类型:第一项为软分叉;第二项为硬分叉。

结果:一些用户在升级期间遇到了问题,并且无法升级的用户被建议强制关闭节点 2

2010 年 8 月 1 日(隔离脚本签名和脚本公钥的求值)

激活区块号:无 1

BIP 号或软件版本号0.3.7

内容让脚本签名和脚本公钥分别求值。修复了一个致命的 bug,该 bug 可以让任何人花费任何比特币。

类型:硬分叉

结果:没有证据证明在此期间出现了问题。

2010 年 8 月 15 日(修复数值溢出漏洞;禁用 OP_CAT)

激活区块号:74,638

BIP 号或软件版本号0.3.10

内容

  1. 在 1845 亿比特币被花费的事故出现后,修复输出的数值溢出漏洞。作为该交易的输入的 0.5 BTC 至今没有再被花费过
  2. 禁用 OP_CAT,从而移除了一个 DoS 攻击界面,同时还禁用了 14 种其它功能

类型:都是软分叉

结果:发生了一次链分裂。大概在这次事故的 5 个小时后,修复措施作为 0.3.10 版放出。人们普遍认为,在 “好的链” 重新变成最长链之前,“坏的链” 一共挖出了 51 个区块

2010 年 9 月 7 日(不正确地实现签名操作数量限制)

激活区块号:无 1

BIP 号或软件版本号0.3.12

内容:以不正确的方式加入了 20000 个签名的操作数量限制。

类型:软分叉

结果:没有证据表明在此期间出现了问题。

2010 年 9 月 12 日(加入区块大小限制)

激活区块号:79,400

BIP 号或软件版本号:无

内容:加入了 1MB 的区块体积限制。加入 MAX_BLOCK_SIZE = 1000000 代码的提交在 2010 年 7 月 15 日发生,该版本在 2010 年 7 月 19 日以 0.3.1 rc1 的版本号发布。这段新代码从 2010 年 9 月 7 日开始强制执行 1MB 的区块大小限制规则,并在区块高度 79400 处激活。在 2010 年 9 月 20 日,中本聪移除了这种激活逻辑,但保留了 1MB 的大小限制。

类型:软分叉

结果:没有证据表明在此期间出现了问题。

2012 年 3 月 15 日(不允许交易使用相同的 TXID)

激活区块号:171,193

BIP 号或软件版本号BIP30

内容:不允许交易使用完全相同的 TXID,除非旧的那一笔已经被完全花费掉。在 2012 年 9 月,这个规则施加到所有区块上,只有 91842 和 91800 两个区块是特例(它们是违反了这条规则的历史区块)。

类型:软分叉

结果:这是一次信号日(flag-day)软分叉。没有证据表明在此期间出现了问题。

2012 年 4 月 1 日(P2SH)

激活区块号:173,805

BIP 号或软件版本号BIP16

内容:支付到脚本哈希值(Pay-to-script hash,P2SH)允许交易被发送给一条脚本哈希值(以数字 3 开头的地址),而不仅仅是一个公钥的哈希值(以数字 1 开头的地址)。

类型:软分叉

结果:在 2012 年 2 月 1 日的前一周,达到 55% 的激活门槛。矿工的升级速度不够快,所以激活时间点被推迟到 3 月 15 日。使用 0.6.0 rc1 版本而没有升级(因此不适用推迟)的用户,更早地激活了软分叉,并被卡在了区块高度 170060 处,因为根据他们的节点,这个区块中包含了一笔无效交易。在激活之后,因为仍有 45% 的矿工在生产无效的区块,问题持续了几个月。

2013 年 3 月 24 日(要求 coinbase 交易包含区块高度)

激活区块号:227,835

BIP 号或软件版本号BIP34

内容:要求 coinbase 交易包含区块高度。

类型:软分叉

结果:达到 95% 的激活门槛。成功启动。

2013 年 3 月 11 日(Bitcoin Core 数据库切换,意料之外的硬分叉)

激活区块号:225,430

BIP 号或软件版本号0.8.0

内容:这是一次意料之外的硬分叉,由 Bitcoin Core 的数据库技术从 Berkeley DB 切换成 LevelDB 导致;切换意外地移除了一个未知的 10000-BDB 数据库锁限制。这导致了 2013 年 3 月 11 日的硬分叉,虽然导致错误的软件是在 2013 年 2 月 20 日(20 天以前)发布的了。这次变更因为比特币社区和矿工切换会 0.7.2 规则而回滚。

类型:共识规则没有发生改变

结果:发生了一次至少持续 24 个区块的链分裂,使用 0.8.0 的链最多领先 13 个区块。还发生了一次成功的重复花费

2013 年 3 月 18 日(输入数量的区块级限制)

激活区块号:无 1

BIP 号或软件版本号0.8.1

内容:这是一次临时的软分叉,引入了一条新规则:一个区块内通过交易输入引用的 TXID 数量不能超过 4500 个。这条规则比起 10000-DBD 锁限制更为严格。这个规则在 2013 年 5 月 15 日通过信号日硬分叉废止

类型:软分叉

结果:没有证据表明在此期间出现了问题。

2013 年 5 月 15 日或 8 月 16 日(废止输入数量的区块级限制)

激活区块号:252,451 或更早

BIP 号或软件版本号BIP50

内容:在 2013 年 8 月,一个生产出来的区块可能违反了最初的 10000-BDB 锁限制规则;该规则在 2013 年 5 月 15 日放宽了。

类型:硬分叉

结果:没有证据表明在此期间出现了问题。

2015 年 7 月 4 日(更严格的 DER 形式签名)

激活区块号:363,731

BIP 号或软件版本号BIP66

内容:严格使用 DER 形式的签名,意味着比特币不再依赖于 OpenSSL 的签名解析。

类型:软分叉

结果:在一个为期 1000 个区块的周期内获得 95% 的同意。发生了一次链分裂,留下了 6 个区块,因为一些矿工发信号表示支持 BIP66,但没有升级,同时又是 SPY 挖矿的。最终软分叉的链领先了。

2015 年 12 月 14 日(CLTV 脚本级绝对时间锁)

激活区块号:388,380

BIP 号或软件版本号BIP65

内容:Check Lock Time Verity(OP_CLTV)在未来某个时间点以前可以一直锁定。这是比特币的第一个新功能。

类型:软分叉

结果:达到 95% 的激活阈值,成功激活。

2016 年 7 月 4 日(相对时间锁)

激活区块号:419,328

BIP 号或软件版本号BIP68BIP112BIP113

内容

  • 交易级相对事件锁,允许交易的输出在交易得到确认后的一段时间内禁止花费。
  • CheckSequenceVerify,脚本级相对时间锁。
  • 中值时间(Median time-past)消除了矿工使用未来的时间戳来获得更多交易手续费的激励。

类型:软分叉

结果:使用 95% 的版本位(versionbits)信号机制,成功激活。

2017 年 7 月 23 日(加速隔离见证激活表态)

激活区块号:477,800

BIP 号或软件版本号BIP91

内容:这个临时的软分叉强制要求对 SegWit 表示支持。

类型:软分叉

结果:在一个为期 336 个区块的周期里,这个软分叉以 80% 的挖矿阈值成功激活,虽然只有少数用户强制执行 BIP91 规则,因此它被废止了。因此,在此期间,发生链分裂的风险增加了。

2017 年 8 月 1 日(加速隔离见证激活表态)

激活区块号:478,479

BIP 号或软件版本号BIP148

内容:这个临时的软分叉强制要求在 2017 年 8 月 1 日后的两周内对 SegWit 升级表示支持。

类型:软分叉

结果:信号日软分叉似乎成功了,没有出现问题,虽然只有少数用户执行 BIP148 规则,因此它被废止。在此期间,链分裂的风险增加了。

2017 年 8 月 24 日(SegWit 升级)

激活区块号:481,824

BIP 号或软件版本号BIP141BIP143BIP147

内容:隔离见证(SegWit)升级。

类型:软分叉

结果:以 95% 的版本位信号激活。

从今年到 2262 年

激活区块号: 1,3440,000

BIP 号或软件版本号BIP42

内容:修复 2100 万 BTC 供给量限制的 bug。软件在 2014 年 4 月升级以修复这个漏洞,但新的规则不会在 23 世纪以前适用。

类型:软分叉

结果:这个软分叉尚未被应用。

注释

  1. 除了 1MB 区块大小限制的软分叉以外,在 2012 年 BIP16 软分叉以前,软分叉激活是没有方法可言的,所以如果分叉平滑地发生,没有出现链分裂的话,共识分叉并不必然有准确的区块高度和日期。
  2. “如果你不立即升级到 0.3.6,最好关掉你的比特币节点,升级之后再开启。”—— Satoshi Nakamoto
  3. 在移除 OP_VER 以前,每一次软件升级都可以被认为是一种非确定式的硬分叉,而这些升级到没有记录在这个列表中。如果硬分叉的定义要包含这些升级,那会有点迂腐。
  4. 上表没有连贯一直的定义,因为,比如说,根据具体的情形选取分叉发生时间的定义,会更有用。
  5. 有些人提到,对 P2P 协议的改变也可以被认为是硬分叉,因为这让旧软件变得不可用(它们将不再能连接到网络)。但是,严格来说,这种变更没有放松关于区块有效性的定义,所以你可以通过建立一个过渡版本的软件作为中继,从而同步旧版本的软件。所以这类变更都从这个列表中排除了。
  6. 一些人认为 BIP90 是一次硬分叉,但因为它只放松了过去发生的软分叉相关的规则,所以它没有常规的硬分叉所具有的许多特性和风险。因为相同的逻辑,区块检查点方案也可以被认为是软分叉。
  7. 2010 年 7 月,链选择规则被替换成选择累积工作量最多的链,而不是最长的链。技术上来说,这不是对区块有效性规则的变更;但是,这一变更跟共识规则变更一样具有某些风险。

2013 年那场意外算是一次硬分叉吗?

从我们的角度来看,公平地说,2013 年 3 月 11 日的链分叉之后,对 BDB 锁限制的提高是一次硬分叉。相关的规则是 10000-BDB 的锁限制,在分叉后被放松了。这个规则是在 2013 年 3 月 15 日在软件的 0.8.1 上放松的,并在 2013 年 3 月 18 日发布。超出这个限制的区块最终在 2013 年 8 月 16 日产生,所以你可以将硬分叉的日期定为 2013 年 5 月 15 日,或者 2013 年 8 月 16 日。

一些人会认为,因为许多原因,这次变更不算硬分叉,包括:这条规则是 “准-非确定性的”,或者说,你可以手动改变 BDB 的配置。实际上,因为这个锁限制的非确定性特性,理论上来说你可以建立一个本地系统,使得旧有的 BDB 锁限制永远无法被突破。因此,你可以断言比特币 “从来没发生过硬分叉”,但你的硬分叉定义将要求硬分叉是确定性的,或者必须直接跟比特币的数据(比如交易和区块头)相关。

在讨论这次意外时,比特币开发者 Gregory Maxwell

这有点复杂,实际机上,你可以使用一个 BIP-50 以前的节点完整地同步区块链,几个月前我刚刚用 0.3.24 版本这么干过。它只是不能可靠地处理涉及大区块的链重组,除非你也改变 BDB 配置。所以,它到底是不是一次硬分叉,当然是可以争辩的,因为它是准非确定性的。在此之前,同样有其它的 bug 修复会导致更旧的版本被卡住、停止同步区块链 …… 所以我认为,从一个非常强的定义 —— 硬分叉将导致新链违反被以前的版本强制执行的规则 —— 来看,我们没有硬分叉过。

2015 年的链分裂事故

在上面的共识规则变更列表中,有三次时间导致了可辨识的链分裂。最近的一次发生在 2015 年 7 月 4 日,在 BIP66 软分叉升级期间。

在 BIP66 激活之后,立即出现了长达 6 个区块的孤链,因为一个矿工创建了一个无效区块,但其他一些矿池不认为这是个无效区块,因为他们根本不验证新区块。

所以实情是,一些矿工表示支持 BIP66 软分叉,但没有升级自己的节点来验证;你可以认为一些矿工是在 “做样子”。要是矿工们一直都验证区块,他们会发现这个区块是无效的,然后拒绝掉。相反,一些矿工直接在无效区块上继续挖矿,所以发生了链分裂。

下图展示了这个长达 6 个区块的链分裂。

img

- 来源:Blockchain.info;http://archive.is/WqGRp 和 http://archive.is/LHlF7 -

注意:在本文出版之后,Bitcoin Wiki 发布了另一份共识版本的清单。

免责声明

虽然本文引用了许多来源,但我们并不保证准确定。我们可能犯了错误,或偶然漏过了一些共识规则变更。欢迎更正。

(完)