Taproot是一个旨在提高 比特币 隐私性及灵活性的拟议协议升级,目前该方案正处于开发的后期阶段,Bitcoin Core的贡献者一致认为,Taproot升级将使得 比特币 受益,截至目前,该方案似乎也受到了更广泛的 比特币 生态的欢迎。因此,Taproot很可能会被纳入Bitcoin Core协议,而其它 比特币 提议也可能会随之推出。但仍有一个问题: 比特币 网络应该如何进行升级?Taproot是共识协议层的一个改变,这意味着 比特币 节点必须以某种方式从旧规则切换到新规则,并且要避免网络的分裂。由于各种原因,这在过去被认为是一个挑战。目前, 比特币 开发者们正在考虑改进激活协议升级的策略。
好消息是Taproot的实施会是一次软分岔。这种类的升级增加或收紧了规则,而硬分叉则是删除或放松规则。添加或收紧规则的好处是,升级节点认为有效的任何内容,在非升级节点看来也会是有效的。(如果旧节点同时接受事务类A和B,但新规则只允许事务类A,则旧节点将在实现新规则的网络上保持兼容。) 比特币 最早的软分叉是通过截止日(flag days)机制激活的。开发者(特别是中本聪)在一个新的 比特币 软件客户端的代码中嵌入了一个未来日期,指定了升级后的节点将执行新规则的时间点。矿工和用户被鼓励在此日期之前升级,以避免网络分裂。(注:在那个年代,矿工和用户经常重叠,这与今天不同)由于未升级的节点仍然与新规则兼容,因此软分叉的一个好处是,如果大部分算力强制升级,整个 比特币 网络会就其区块链版本达成共识。这也意味着,在实施新的协议规则时,不需要立即升级所有节点,从而允许用户具有一定的灵活性。自2012年左右以来,软分叉已越来越多地利用算力作为协调机制,以协调向新规则的转换。通过在区块中嵌入一些数据,矿工可以向其它矿工和网络的其余部分发出信号,告知他们已升级软件的信息,从而准备好实施新的规则。一旦有足够的算力信号支持,所有升级的节点都会被触发以执行新规则。经过几次升级,这一战略演变成BIP 9( 比特币 改进提议)。例如,BIP 9就是用来激活 比特币 上一次隔离见证(SegWit)软分叉升级的机制。矿工们有一年的时间来启动升级,要求在任何难度区间内95%的区块都包含就绪信号位。如果一年后没有发生这种情况,激活期就会过期,升级就会失败。(当然,可以简单地再试一次)然而,对于隔离见证(SegWit)来说,BIP 9的运行并不顺利。与以前的某些升级一样,有些矿工可能由于漠不关心而在一段时间内没有进行升级(通常没有太大的动力促使矿工快速升级)。但一个更大的问题是,一些矿工已开始将这一信号传递过程理解为对升级的投票,而不是发出准备就绪的信号,而是投票决定是否支持升级。更糟糕的是,一些矿工最终利用这一“投票权”阻止升级,以试图在 比特币 开发过程中获得政治影响力,或者他们可“投票”反对升级,以暗中获益。经过长时间的激烈争吵,隔离见证(SegWit)最终确实激活了,但只有在其他 比特币 客户端包含新的激活方案之后。一些用户运行的BIP 148客户端中包含的BIP 148,被编程为仅接受截止日(flag day)后支持协议升级的区块。同时,btc1客户端中包含的BIP 91,有效地将算力要求从95%降低到75%。面对潜在的网络分裂和可能的收入损失情况,一直在阻挠的矿工们让步了。但对于大多数Bitcoin Core开发者来说,BIP 9已暴露出它是一个次优的解决方案,因此,开发者们已开始考虑替代方案。
BIP 8号
BIP 8是BIP 9的早期替代方案,它是由BIP 148的作者Shainfry和Bitcoin Knots,以及Bitcoin Core贡献者Luke-jr提出的,它最初与BIP 9相似,但关键的区别在于:一年后若算力支持不足,升级并不会因此失败,它会做完全相反的事情,即在那个时间点激活软分叉。与截止日(flag day)类似,所有升级的节点将从那时起开始实施新规则。而那些仍未能升级的矿工,其挖取的区块,将冒着被升级的矿工和用户拒绝的风险。bip9背后的主要思想是,假设用户升级,矿工无法阻止软叉,因此他们无法利用这种投票权。它们可以加速激活并帮助协调协议的顺利升级,但是即使它们自己不激活升级,升级最终还是会发生的。BIP 8的**草案,包含了一些显著的变化。首先,当信号期即将到期时,BIP 8允许为节点配置两种不同的策略:如前两段所述,强制激活,或者像BIP 9一样不强制激活。此外,节点(如果这样配置的话)实际上并没有激活升级本身,而是为升级发出信号。而不表示支持升级的区块,将被拒绝。这两个变化的结合有一个有趣的特性,即如果 比特币 算力的大部分都被迫发出信号支持升级,即使没有配置为强制执行信号的BIP 8节点也将随升级一起进行。反对BIP 8及其强制信号(或自动激活)的一个论点是,它可能会有风险,尤其是在较短的时间内。如果算力占多数,且至少有部分用户不升级,则该方案会造成升级节点网络和未升级节点网络分裂。假设大多数用户支持升级,这可能最终会有利于网络的升级部分。但在此期间,未升级的用户将面临资金损失的风险,而未升级的矿工将浪费掉算力,从而有损 比特币 的安全性。**的办法是提供足够的时间进行升级。不幸的是,每个人对时间的长度看法是不同的,一些人认为强制信号可能在一年内开始,另一些人则认为需要几年时间。BIP 8存在的另一个复杂问题是,设置强制信号的默认值。如果在默认情况下关闭强制信号,用户可能会发现自己不协调,从而增加网络分裂的风险。另一方面,如果在Bitcoin Core客户端中,强制信号被选为默认设置,则历史上广泛采用的Bitcoin Core实际上就保证了升级将会发生。一些人认为,这会使Bitcoin Core开发者对 比特币 的协议规则产生太大的影响。出于这个原因,BIP 8的合著者Luke-jr倾向于通过特殊的客户端专门部署带有强制信号的BIP 8,类似于BIP 148客户端。另一些人则认为,Bitcoin Core开发者始终会根据自己的**判断发布软件,同时牢记用户需求并避免有争议的升级,设置BIP 8默认值也不例外。如果有人不同意Bitcoin Core开发人员的最终选择,他们可选择不升级到新版本,甚至分叉Bitcoin Core代码,以推出竞争版客户端。
现代软分叉激活
虽然Bitcoin Core开发者确实会考虑用户需求,并尝试避免有争议的升级,但并不是所有人都相信这是可能的。也许在这次发布之后,会出现全新的问题。或者,Bitcoin Core开发者可能遗漏了一些东西。这就是为什么Bitcoin Core贡献者Matt Corallo提出了一项被称为“现代软分叉激活”策略的原因。现代软分叉激活包括三个步骤,它基本上实现了BIP 9(或没有强制信号的BIP 8)和带有截止日激活的BIP 8的组合(尽管强制信号可能是一种选择)。作为第一步,BIP 9将允许矿工通过算力激活软分叉。如果矿工们在一年内没有激活它,第一个激活窗口就会过期。然后,作为第二步,开发者们需要一些时间来分析激活失败的原因,如果他们确实发现了问题,就重新考虑这个提议。但是,如果他们发现方案没有问题,则第三步是重新部署软分叉,这一次使用BIP8和flag day激活:矿工们有另一次机会用算力激活方案,但如果他们再次失败,软分叉将在第二个信号周期结束时激活。(Bitcoin Core贡献者AJ Towns表示,在第二个信号周期内,算力激活阈值也可能随着时间的推移逐渐降低)Corallo相信,如果提议没有错的话,这种方案将提供BIP9的好处,而不会带来负面影响。如果矿工愿意,他们可以协调一次平稳的升级,并且没有强制激活,如果激活最初失败,开发者可以花时间重新考虑提议。同时,由于没有充分的理由,矿工从阻止升级中获得的收益要少得多,因为众所周知,升级最终仍将继续进行。反对现代软叉激活的主要论点是,如果没有矿工的合作,这个过程将花费相对较长的时间,有些人认为BIP 9步骤完全是在浪费时间。Corallo最初的提议,包含1年的BIP 9信号,以及随后6个月的重新考虑期,**是在自动激活前2年的BIP 8信号期,也就是说,总共有3年半的时间。虽然这个时间表尚未确定,但将不同步骤缩短太多,会减少重新考虑或升级的时间(即会增加网络分裂的风险)。由于距离潜在的强制激活还有很长时间,一些人认为,矿工终究可以尝试获得一些政治权力,他们可以将升级推迟数年的时间。
8号院+91号院
另一个最近被提出来的建议,也许**被描述为BIP 8和现代软分叉激活的一个组合,至少在精神上是这样的。这项不具名的提议,将部署一个很长的BIP 8信号周期,可能与现代软分叉激活的三年半时间一样长,之后强制触发信号。然而,如果一年后升级还没有启动,开发者将需要一些时间重新考虑这个提议,就像他们使用现代软分叉激活一样。如果开发者发现该提案没有问题,并断定该提案只是由于矿工的漠不关心或其他无效原因而没有激活,则他们可以选择部署隔离见证(SegWit)激活期间使用的BIP 91风格的新软分叉。这将有效地降低激活的算力阈值,从而可能加快过程。另一方面,如果开发人员最终发现提案是有问题的,他们可以部署一个新的软分叉来解决问题,甚至完全撤销原来的软分叉(这里是指Taproot)。假设现代软分叉激活在强制信号发出之前有三年半的时间线,那么应该有足够的时间来处理这个问题。反对这一提议的主要论点可能是,部署软分叉(如果需要)来撤消另一次软分叉是有争议的。更具体地说,它要求矿工和用户在截止日期之前升级到新版本,否则就有分裂网络的风险。
孢子
**,Bitcoin Core贡献者Jeremy Rubin提出,他发明了一个名为概率 比特币 软分叉(或称“Sporks”)的概念,这可能比典的算力强制软分叉更具激励相容性。Rubin认为,BIP 9 的核心问题在于,矿工可以在不付出代价的情况下推迟升级,这可能会给他们带来政治权力。而在Sporks方案中,就绪信号不再是来自矿工在其挖矿的区块中包含的一点数据,而是来自区块头哈希:它们通过投入时间和资源而随机生成的工作量证明。升级后的节点会同意,有效区块头算力的一小部分(统计上每六个月左右才能找到一次)将触发升级。根据哈希的随机性,矿工将无法控制他是生成常规区块头哈希,还是升级激活区块头哈希。从统计意义上讲,他只是偶尔生成一个区块头哈希。所以,如果他投入的资源碰巧生成了一个升级激活区块头哈希,那么他有两个选择。要么将其发布到 比特币 网络,获得区块奖励,并激活软分叉。或者,在我们的示例中,由于不发布而将软分叉平均延迟了大约六个月……但这样做也意味着矿工放弃了区块奖励,也就是说,推迟升级将付出巨大的代价。目前,Sporks的主要问题,可能在于它是一个相对较新的想法,尚未有可用的代码,更不用说测试了。尽管有些人确实认为这一概念很有趣,但它并不是激活Taproot的有力竞争者。本文链接:https://www.8btc.com/article/625597
转载请注明文章出处
文章标题:比特币应该包含在主根升级中。你会选择多少种不同的方式?
文章链接:https://www.btchangqing.cn/69244.html
更新时间:2020年07月22日
本站大部分内容均收集于网络,若内容若侵犯到您的权益,请联系我们,我们将第一时间处理。