软分叉的困难情况：如何激活下一个比特币更新

就比特币网络的技术发展而言，6月发布的比特币核心0.20.0已成为一年中的主要事件之一。 开发人员的活动并不止于此-新的更新正在进行中，旨在增加第一个加密货币的可伸缩性，安全性和隐私性。 1月，隔离见证（SegWit）协议的创建者之一Peter Welle将Schnorr / Taproot软叉（BIP-340，BIP-341和BIP-342）正式定为改进比特币的正式提案。 激活Taproot需要达成共识协议更改。 这意味着网络节点（节点）需要以某种方式从旧规则切换到新规则，而不会导致网络被分成多个链，每个链将根据不同的规则工作。 过去，由于各种原因，此过程已引起问题。 ForkLog在《比特币杂志》上翻译了Aaron van Wyrdum的文章，他在其中确切解释了开发人员如何实施必要的更改以及他们拥有哪些替代解决方案。 *与删除或削弱规则的硬叉不同，软叉添加或完善规则。 执行软分叉时，未更新的节点也会将更新的节点认为有效的所有内容都视为有效。 例如，如果未更新的节点接受类型A和B的事务，而新规则仅允许事务A，则更新的节点将与其余节点保持兼容。 在比特币的早期，计划在特定的日子（卖旗日）进行软分叉。 开发人员，特别是中本聪，在新客户端版本的代码中指出了更新的节点开始应用新规则的时间。 建议矿工和用户（当时通常是同一个人）升级到该日期，以避免网络分裂。 由于未更新的节点仍然符合新规则，因此，软分叉的优势在于，如果很大一部分哈希率触发了更新，则网络共识会选择正确版本的区块链。 因此，节点无需在更改后的规则生效后立即进行更新。 用户可以放心，尽管他们将来需要升级，以避免拒绝拒绝违反新规则的交易或区块。 自2012年左右以来，软叉逐渐开始使用哈希率作为向新规则过渡的协调机制。 通过向区块添加特定数据，矿工可以发出信号，表示他们已更新软件并准备应用新规则。 所需的哈希率级别发出升级信号后，所有更新的节点都将开始应用新规则。 BIP-9中描述了此策略，该策略用于激活SegWit。 给矿工一年的过渡时间：在重新计算复杂性的任何时期，要求95％的区块包含一点，以表示他们已准备好进行升级。 如果一年后仍未发生，则激活期将到期。 但是，激活BIP-9并非易事。 像以前的某些升级一样，一些矿工并不着急，因为他们没有足够的动力来做到这一点。 另一个问题是，一些矿工开始将这一过程视为一种投票，他们会（或不会）发出支持信号，而不是表示准备就绪。 更糟糕的是，一些人选择使用这种“投票”来试图获得对比特币开发过程的政治影响力并加以利用。 在持续了很长时间的戏剧性事件之后，SegWit仍处于激活状态，但这仅在新的激活方案启用了替代比特币客户端之后才发生。 网络的一部分使用了BIP-148客户端，并且其中包含的同名产品被编程为仅接受那些表示支持协议更新的模块。 同时，btc1客户端中包含的BIP-91将哈希率要求从95％降低到75％。 结果，大多数比特币核心开发人员认为BIP-9不是最佳解决方案，并开始寻找替代方案。 BIP-8 BIP-9的第一个替代方案是BIP-8，它是由BIP-148的作者Shaolinfry和比特币核心开发人员Luke Dash Jr提出的。 它与BIP-9的区别在于，相反，由于哈希率支持不足，一年后就不会取消更新，相反的是，软叉在某一天被强制激活。 此刻所有更新的节点开始应用新规则，使用旧版本的软件上的矿工可能会开始挖掘将被拒绝的块。 BIP-8的主要思想是矿工不能阻止软叉（当然要由用户支持），因此不能利用这种影响来发挥自己的优势。 矿工可以加快激活速度并帮助协调协议更新，但是即使他们自己不激活它也最终会发生。 BIP-8的最新版本之一允许在信令周期即将结束时针对两种不同场景配置节点：强制激活和非强制激活。 而且，不是激活更新本身，而是迫使节点发信号通知它们已准备好进行更新。 结果，拒绝了不表示支持的块，但是，这仍然可以保证激活已更新节点的升级。 这两个更改的组合会产生非常有趣的结果：如果大多数哈希率信号支持升级，则即使未配置BIP-8节点进行更改，也会对其进行更新。 反对BIP-8及其强制信令或自动更新的论点是，这种方法可能存在风险，尤其是在较短的时间范围内。 如果大多数哈希率和至少一些用户不更新，则此方案可以将网络划分为更新的节点和未更新的节点。 使用未更新软件的用户还有可能会损失资金，而矿工会损害网络安全，这会浪费计算能力。 现代软叉激活比特币核心贡献者Matt Corallo提出了现代软叉激活的概念。 它由结合BIP-9和BIP-8的三个阶段组成。 在第一阶段，BIP-9允许矿工使用哈希率激活软叉。 如果他们没有在指定的时间范围内这样做，则第一个激活窗口将过期。 之后，开发人员将需要一些时间来分析激活失败的原因并重新考虑该提案。 如果找不到修改更新的原因，则会根据BIP-8（工作日）的规则重新发出软叉。 因此，矿工有第二次机会支持更新，但是在指定时间段之后，节点将自动切换到更改后的规则。 据Corallo称，这样的计划将使矿工出于政治原因而没有理由阻止更新，因为他们知道反正会发生。 现代软叉激活的主要反对意见是，如果不与矿工合作，该过程将花费很长时间。 最初，Corallo建议为BIP-9留出一年的时间，为拒绝原因分析留出六个月的时间，为BIP-8留出两年的时间。 因此，可能需要三年半的时间才能接受更新。 如此长的激活期会带来风险：矿工仍然可以玩政治游戏，延迟激活，而减少时间则会带来网络分裂的危险。 BIP-8 + BIP-91最近，开发人员聊天一直在讨论一个尚未命名的建议，可以将其视为BIP-8和Coral的现代软叉激活的结合。 例如，如果一年后未激活更新，它将提供长时间的BIP-8信令和提案修订。 如果开发人员未在提案本身中发现问题（例如，由于矿工的被动而未进行激活），则他们可以根据BIP-91方案选择部署新的软叉，该方案用于激活SegWit。 这将减少对哈希率支持的要求，从而加快流程。 另一方面，如果在提案本身中发现问题，则开发人员可以部署新的软叉以解决该问题或完全取消原始提案。 反对该建议的主要论点是，建议不要部署软叉，该软叉在必要时可以取消另一个软叉。 矿工和用户将需要安装新软件，然后才能强制启动更新，否则网络可能会再次分裂。 Sporks比特币核心开发人员Jeremy Rubin提出了比特币的概率软叉（Sporks）的概念，以提供比传统哈希率软叉更多的激励措施。 鲁宾认为，BIP-9的问题在于，矿工可以延迟更新而不会给自己造成任何损失，拒绝表示准备就绪。 在Sporks中，不再从矿工包含在已开采区块中的数据中获取就绪信号。 它是从区块头的哈希中提取的-矿工在花费时间和资源后随机生成的工作证明。 想法是，更新的节点同意升级将激活有效块头哈希的特定子集。 由于哈希值的随机性，矿工无法控制他生成的哈希值-定期更新或激活更新。 如果一个矿工生成一个哈希来激活更新，他将有两个选择：将其广播到比特币网络，赚取区块奖励并激活软分叉，或拒绝广播哈希，激活软叉子并进行分块奖励。 因此，激活更新的延迟会花费矿工金钱。 Sporks的概念是一个相对较新的概念，到目前为止尚未进行研究。 一些开发人员发现它很有趣，但目前不太可能将其视为激活Taproot的竞争者。 最近已经开始积极讨论的另一个想法涉及以相对较长的信号周期（例如两年）完成BIP-8的初始部署，而无需强制激活。 就像过去一样，这将使矿工能够激活软叉。 如果一段时间（例如六个月）后软叉未激活，并且没有令人信服的延迟原因，则可以在新客户端中释放具有强制激活功能的BIP-8。 该方案假定大多数矿工在此之前或期间通过强制激活来激活软叉，并且所有具有BIP-8（具有或不具有强制激活）的节点都将支持该软叉。 ForkLog之前曾发表过有关Aaron van Wyrdum的文章的翻译，内容涉及Taproot的工作原理，并解释了此解决方案为何会使比特币变得更强大。 在Telegram上订阅ForkLog新闻：ForkLog Feed-整个新闻Feed，ForkLog-最重要的新闻和民意调查。

—-

原文链接：https://forklog.com/neprostoj-kejs-softforka-kak-budet-aktivirovano-sleduyushhee-obnovlenie-bitkoina/

原文作者：Andrew Asmakov

编译者/作者：wanbizu AI

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。