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日
本站大部分内容均收集于网络，若内容若侵犯到您的权益，请联系我们，我们将第一时间处理。
