首页 > 比特币 > 正文
随着最新的共识协议变化 Taproot 接近激活,比特币开发人员正在询问网络应该如何升级。

随着最新的共识协议变化 Taproot 接近激活,比特币开发人员正在询问网络应该如何升级。

Taproot是一项拟议的协议升级,旨在提高比特币的隐私和灵活性,目前正处于开发后期。比特币核心贡献者同意升级将使比特币受益,到目前为止,它似乎也受到更广泛的比特币生态系统的欢迎。因此,Taproot 很可能会进入比特币核心版本,其他比特币实现可能会随之而来。

比特币下一步走势

但仍有一个问题:比特币网络本身应该如何升级?Taproot 是一种共识协议更改,这意味着比特币节点必须以某种方式从旧规则切换到新规则,而不会将网络分成执行不同规则的派系。由于各种原因,这在过去有时被证明是一个挑战。

现在正在考虑激活协议升级的改进策略。

以前的软分叉和 BIP 9

好消息是 Taproot 将是一个软分叉。这种类型的升级增加或收紧了规则——而不是删除或放松规则的硬分叉。添加或收紧规则的好处是升级节点认为有效的任何内容,未升级节点也认为有效。(如果旧节点接受交易类型 A 和 B,但新规则只允许交易类型 A,则旧节点将在执行新规则的网络上保持兼容。)

比特币最早的软分叉是通过标志日激活的。开发人员(特别是中本聪)在新的比特币软件客户端版本的代码中嵌入了未来日期,指定升级节点将执行新规则的时间点。鼓励矿工和用户在该日期之前升级以避免网络分裂。(顺便说一句,在那些日子里,矿工和用户比今天更经常是同一个人。)

由于未升级的节点仍然与新规则兼容,软分叉的一个方便的好处是,如果大多数哈希算力强制升级,整个比特币网络就其区块链版本达成共识。这也意味着在执行新协议规则时,不再需要立即升级所有节点,从而为用户提供了一定的灵活性。(尽管鼓励用户升级;他们最终是通过拒绝交易和破坏新规则来执行新规则的人。)

自 2012 年左右以来,软分叉越来越多地利用哈希算力作为协调机制来协调向新规则的转换。通过在他们的区块中嵌入一些数据,矿工可以向其他矿工和网络的其余部分发出信号,表明他们升级了他们的软件,从而准备好执行新规则。一旦有足够的算力信号支持,所有升级的节点都会被触发以执行新规则。

经过几次升级,这种策略演变成比特币改进提案 9(BIP 9)。例如,BIP 9 是用于激活比特币最后一次软分叉升级的机制,即隔离见证(SegWit)。矿工有一年的时间来激活升级,要求任何难度区间内 95% 的区块都包含一个准备就绪信号位。如果一年后没有发生这种情况,激活期就会到期,升级就会失败。(然后当然可以简单地再试一次。)

然而,对于 SegWit,BIP 9 并没有顺利进行。与之前的一些升级一样,由于冷漠,一些矿工可能有一段时间没有开始升级:通常没有很大的动力让矿工快速升级。但更大的问题是,一些矿工已经开始将信号传递过程理解为对升级的一种投票,在这种情况下,他们会(或不会)表示支持升级,而不是发出准备就绪的信号。更糟糕的是,一些矿工最终使用这个“投票”来阻止升级,以试图获得对比特币开发过程的政治影响力,和/或他们“投票”反对升级,以便秘密地从比特币的怪癖中受益升级将修复的协议。

经过长时间的激烈戏剧,隔离见证最终确实激活了,但只有在替代比特币客户端包含新的激活方案之后。BIP 148 包含在由一些用户运行的 BIP 148 客户端中,被编程为仅接受块信令支持从标志日开始的协议升级。同时,包含在 btc1 客户端中并由矿工在 BIP 148 标志日之前运行的 BIP 91 有效地将哈希功率要求从 95% 降低到 75%。面对潜在的分裂网络和可能的收入损失,阻碍矿工承认。但是对于大多数比特币核心开发人员来说,BIP 9 已经表明自己是一个次优的解决方案,他们开始考虑替代方案。

BIP 8

BIP 8是 BIP 9 的早期替代方案,由 BIP 148 作者 Shaolinfry 和 Bitcoin Knots 以及比特币核心贡献者 Luke-jr 提出。它最初类似于 BIP 9,但有一个关键区别:它不会在一年的哈希算力支持不足后升级失败,而是会做完全相反的事情并在那个时间点激活软分叉。与国旗日类似,所有升级的节点将从那时起开始执行新规则。仍然没有升级的矿工将冒着挖掘升级矿工和用户会拒绝的区块的风险。 

BIP 8 背后的主要思想是——当然假设用户升级——矿工不能阻止软分叉,因此不能利用这种杠杆来谋取利益。他们可以加快激活速度并帮助协调协议的顺利升级,但即使他们自己不激活升级,最终也会发生。

BIP 8 的最新草案包括一些显着的变化。首先,BIP 8 允许在信令周期即将到期时为节点配置两种不同的策略:强制激活,如前两段所述,或不强制激活,如 BIP 9。此外,不是激活升级本身,节点(如果这样配置)实际上强制执行升级信号。然后拒绝不支持升级的块,因此仍然保证升级,至少对于升级的节点。这两个变化的组合具有一个有趣的特性,即如果所有比特币哈希算力中的大部分被迫表示支持升级,即使未配置为强制执行信号的 BIP 8 节点也将伴随升级。

反对 BIP 8 及其强制信号(或自动激活)的一个论点是它可能存在风险,尤其是在较短的时间内。如果算力占多数且至少有一些用户不升级,则该方案可能会在升级节点和未升级节点之间拆分网络。假设大多数用户支持升级,这可能最终有利于网络的升级部分。但在此期间,未升级的用户可能会损失资金,而未升级的矿工则会浪费算力,从而损害比特币的安全性。

这种风险可能最好通过提供足够的升级时间来应对。不幸的是,并不是每个人都同意多少时间是足够的。有些人认为强制信号可以在一年内开始,其他人认为应该需要几年时间。

BIP 8 的另一个复杂之处是设置强制信令的默认值。如果默认关闭强制信令,用户可能会发现自己不协调,增加了网络分裂的风险。另一方面,如果在比特币核心版本中选择强制信号作为默认值,那么比特币核心在历史上的广泛采用实际上保证了升级将会发生。一些人认为这会给比特币核心开发人员带来对比特币协议规则的太大影响。BIP 8 的合著者 Luke-jr 更喜欢 BIP 8 只通过特殊客户端部署,类似于 BIP 148 客户端。

其他人认为,Bitcoin Core 开发人员总是根据他们的最佳判断发布软件,同时牢记用户需求并避免有争议的升级;设置 BIP 8 默认值应该也不例外。如果有人不同意比特币核心开发人员所做的选择,他们可以简单地选择不升级到新版本,甚至分叉比特币核心代码以完全启动竞争客户端。

现代软分叉激活

虽然比特币核心开发人员确实寻求考虑用户需求并尽量避免有争议的升级,但并非所有人都相信这总是完全可能的。也许只有在新版本中部署软件时才会对提议的升级感到担忧。也许在此版本之后会出现全新的问题。或者也许比特币核心开发人员只是错过了一些东西。

这就是比特币核心贡献者 Matt Corallo 提出一项名为“现代软分叉激活”的策略的原因之一。现代软分叉激活由三个步骤组成,共同实现了 BIP 9(或:没有强制信号的 BIP 8)和带有标志日激活的 BIP 8(尽管强制信号也可以是一个选项)的组合。 

作为第一步,BIP 9 将允许矿工通过算力激活软分叉。如果矿工在(比如)一年内没有激活它,第一个激活窗口就会到期。然后,作为第二步,开发人员花一些时间分析激活失败的原因,如果他们确实发现了问题,则重新考虑该提案。如果他们发现提案没有问题,那么第三步是重新部署软分叉,这次使用 BIP 8 和标志日激活:矿工有另一个机会用算力激活提案,但如果他们再次失败,当第二个信令周期结束时,软分叉激活。(比特币核心贡献者 AJ Towns建议,在第二个信号周期内,哈希功率激活阈值也可以随着时间的推移逐渐降低。)

通过明确承诺重新部署 BIP 8,如果证明该提案没有任何问题,Corallo 认为该策略将提供 BIP 9 的好处而没有不利之处。代码在第一个信号周期内放出来供大家考虑,如果矿工愿意,他们可以协调平滑升级,并且没有强制激活,如果激活最初失败,开发人员可以花时间重新考虑提案。与此同时,矿工从无缘无故阻止升级中获得的收益要少得多,因为每个人都知道它最终会激活。

反对现代软分叉激活的主要论点是,如果没有矿工合作,这个过程会花费相对较长的时间,有些人认为 BIP 9 步骤完全是在浪费时间。Corallo 最初的提议包括一年的 BIP 9 信令,然后是六个月的重新考虑,最后是在自动激活之前两年的 BIP 8 信令:总共三年半。虽然这个时间表当然还不是一成不变的,但将不同的步骤缩短太多会减少重新考虑和/或升级的时间(增加网络分裂的风险)。

由于潜在的强制激活需要很长时间,一些人还认为,矿工毕竟可以尝试获得一些政治影响力:他们可以将升级推迟数年。

BIP 8 + BIP 91

另一个最近通过比特币技术渠道传播的建议可能最好被描述为 BIP 8 和现代软分叉激活之间的合并,至少在精神上是这样。未命名的提案将部署很长的 BIP 8 信号周期,可能与现代软分叉激活的三年半一样长,之后强制信号触发。但是,如果(比如说)一年后升级仍未激活,开发人员将需要一些时间来重新考虑该提案,就像使用现代软分叉激活一样。

如果开发人员发现该提案没有问题,而是得出结论认为它只是由于矿工冷漠或其他无效原因而没有激活,他们可以选择部署一个新的软分叉,其风格类似于 BIP 91,在 SegWit 期间使用激活。这将有效地降低激活的哈希功率阈值,可能会加快进程。

另一方面,如果开发人员最终发现提案存在问题,他们可以部署一个新的软分叉来解决问题,甚至完全撤消原始软分叉(在这种情况下,Taproot)。假设现代软分叉激活的三年半时间到强制信号,应该有足够的时间来处理这个问题。

反对这个提议的主要论点可能是,如果需要的话,部署一个软分叉来撤销另一个软分叉并不是很优雅。更具体地说,它要求矿工和用户在截止日期之前升级到新版本,否则可能会导致网络分裂。

斯波克斯

最后,作为一个离群点的想法,比特币核心贡献者 Jeremy Rubin 建议,他发明的一个称为概率比特币软分叉或“ Sporks ”的概念可能比典型的哈希算力强制软分叉更具激励兼容性。

鲁宾认为,BIP 9 问题的核心是矿工可以免费延迟升级。简单地拒绝表示准备好升级是免费的,但它可能会为他们提供政治影响力。

有了 Sporks,就绪信号不再来自矿工在他们挖掘的区块中包含的一些数据,而是来自区块头哈希:他们通过投入时间和资源随机生成的工作证明。升级后的节点会同意一小部分有效的区块头哈希——统计上只能每六个月左右发现一次——将触发升级。

根据散列的随机性,矿工不会控制他是生成常规块头散列还是升级激活块头散列;从统计上看,他只是偶尔生产出后者之一。因此,如果他投入的资源碰巧生成了激活升级的区块头哈希,他将有两种选择。要么,将其发布到比特币网络,获得区块奖励,并激活软分叉。或者,不发布,在我们的示例中平均将软分叉延迟大约六个月……但这样做也会放弃块奖励。延迟升级将付出巨大的代价。

目前 Sporks 的主要问题可能是它是一个相对较新的想法,尚未开发 - 更不用说在野外进行测试了。虽然有些人确实认为这个概念很有趣,但它目前还不是 Taproot 激活的最有可能的竞争者。

更新

另一个想法(主要是)自本文撰写以来一直受到关注,首先部署具有相对较长信令周期(例如,两年)的 BIP 8,在此信令周期结束时配置为没有强制信令。这使得矿工可以相对正常地激活软分叉,就像他们过去多次做过的那样。但是,如果一段时间(例如六个月)后软分叉没有被激活,并且延迟似乎没有充分的理由,则可以发布一个新客户端,其中 BIP 8 配置为在现有信令周期结束或更早。假设大多数矿工在此强制信令期间之前或期间激活软分叉,两组 BIP 8 节点(有和没有强制信令配置)都会在激活时强制执行软分叉。

猜你喜欢
发表评论

电子邮件地址不会被公开。 必填项已用*标注

评论信息