蓑衣网区块链软分叉是怎么样实现的
软分叉是指旧节点不会察觉到代码的变化，会继续接受或验证新节点生成的块。具体来说，具有软分叉和硬分叉的新节点可以接受旧节点生成的数据或代码，就像Windows 10也兼容Windows XP应用程序一样。在此基础上，软分叉还可以实现“前向兼容”，使旧节点也可以接受新节点生成的块，从而避免区块链分裂的情况。接下来，我们将介绍软叉是如何实现的。
共识规则和软分叉
共识规则决定每笔交易或每块的有效性。比特币网络上的每个用户和矿工都遵守同一套共识规则，这意味着他们都愿意接受和同意一个账本。
当大多数用户和/或矿工决定采用更严格的共识规则时，可能会发生软分叉，这使得一些先前有效的事务/块变得无效，而不是相反。如果大多数人执行新规则，任何其他非法分歧(统计上)都不会赶上工作量证明中新的和更严格的共识分歧。少数遵循老规矩的人，总会遵循更长更严的分叉，让网络上的所有人最终接受并认同一个账本。
策略规则和共识规则
虽然共识规则是确定事务有效性的唯一标准，但是通信节点或挖掘节点可能更喜欢某个事务。比如：
作为一种垃圾邮件控制机制，成本非常低或者“微产出”(低产值)的交易都会被拒绝。
一些矿商拒绝包括“连锁赌场”交易，这被认为是垃圾邮件。
交易的未知版本被拒绝(目前只有版本1和2是“已知的”)。
非常规脚本(即不是P2PKH、P2SH、v0 segwit或某些其他情况)和未知NOPx代码(目前只知道OP_NOP2和OP_NOP3)的交易将被拒绝。
替代费(Replace-by-fee)和子代付(child-pay-for-parent)也属于政策规定，因为它们决定了矿工更倾向于哪些交易。
根据定义，政策规则必须至少与共识规则一样严格。显然，矿商不希望将无效交易包含在一个区块中(这会导致采矿奖励的损失)，或者将其分散(会被同行拒绝)。
虽然政策条款可能比共识条款更严格，但应该注意的是，政策条款并不决定交易的有效性。一旦事务被包括在有效块中，即使它违反了一些策略规则，所有网络节点都将接受并确认它。
还应注意的是，政策规则是区域性的，而共识规则是普遍性的。这意味着不同的网络节点可能具有不同的策略规则。只要运行相同的共识规则，他们仍然会一致同意区块链账本。
违反政策规则的交易有时被称为“非标准交易”，我们需要将其与“无效交易”区分开来。
策略规则和软分叉
理想情况下，在激活软分叉之前，所有矿工都应该升级到新的、更严格的规则版本。从经济利益上来说，他们有很强的动机去这么做，因为开采一个无效区块(就新规则而言)会导致巨大的财务成本。但在比特币这样的去中心化系统中，矿工的行为无法得到保证。
虽然理论上矿商应该关注所有规则变更的提议，并及时采取行动，但是一旦矿商挖掘无效区块，就会导致市场的扰乱和普通用户的经济损失。因此，任何精心规划的软分叉都应该考虑到这一点，并将风险降至最低。
诀窍在于，软分叉的内容应限制在现有的、广泛采用的政策规定所涵盖的范围内。有政策但不知道新共识规则的矿商，会自动拒绝这些交易，所以永远不会把这些交易纳入新的交易规则。这在比特币历史上的一些案例中有详细解释。
案例分析描述BIP65:检查锁时间验证OP_NOP1到OP_NOP10在比特币脚本语言中无意义。尽管它们被计为一个操作(脚本中限制为201个操作)，但实际上它们在事务验证中被忽略。但是从0.10版本开始，比特币核心中加入了一个策略规则，默认拒绝OP_NOPx。BIP65是比特币核心0.12中引入的软分叉，它将OP_NOP2重新定义为OP_CHECKLOCKTIMEVERIFY( OP_CLTV)。OP_CLTV检查顶层堆栈值是否大于事务的nLockTime字段(以及其他条件)。如果任何条件匹配，交易将被视为无效。否则，OP_CLTV将像OP_NOP2一样被忽略。
？新的共识规则，新节点将在软分叉被激活后实施该规则。甚至在激活之前，原始的OP_NOP2策略规则已经被OP_CLTV规则所取代。(这没问题，因为OP_CLTV规则比原来的OP_NOP2共识规则更严格)？旧的挖掘节点不执行nLockTime检查。但是，只要运行0.10或更高版本，默认的OP_NOP2策略规则将阻止它们包含任何带有OP_CLTV的事务，无论该事务是有效还是无效。因此，对于新的OP_CLTV共识规则，0.10或以上的旧挖掘节点不会主动产生无效块。BIP68:使用序列号的相对锁定时间nSequence是比特币交易中的一个字段，基本不用。BIP68的概念是利用nSequence字段实现相对锁定时间，这是支付通道、闪电网络等高级交易非常重要的组成部分。但是从第一版比特币开始，nSequence字段就被忽略了，矿工对任何有nSequence值的交易都采取接受的态度。没有关于nSequence值的策略规则，所以不可能简单的完成OP_CLTV这样的安全软分叉。
诀窍是使用事务版本字段(n version)。从版本0.7开始，非版本1的事务将被策略规则拒绝。为了充分利用这一点，BIP68要求只有当事务版本为2或更高(准确地说是低于0)时，才强制执行nSequence的新规则。因此，旧的挖掘节点不会产生任何违反BIP68的块，因为默认情况下它们不会包含任何非版本1的事务。攻击者不能通过简单地改变事务版本来“关闭”BIP68，因为版本是通过签名认证的。这也是交易版本与共识规则相关联的唯一示例。BIP141: segwit (SegWit)是一种通过重新定义特定脚本模式来修复事务规模的软分叉。BIP141的模式是以单个OP_x(x=0到16)开始的输出脚本(或P2SH redeemscript 蓑衣网小编2022 ),后面是2到40字节之间的规范数据推送。然而，这不是最初的提议。在第一稿中，见证模式是2到41字节之间的单次推送。
该政策从v0.6版开始实施，用于拒绝非常规脚本(即非P2PKH、P2SH和其他几种类型)的交易。在这方面，证人计划的第一个模式草案确实不规范。？问题是用P2SH编程的见证程序。在v0.10之前，策略规则还会拒绝任何非常规的P2SH脚本。这个规则在v0.10中被大大放宽，原来的见证程序设计没有被覆盖。？当时也考虑了几个备选方案：？新的事务版本(如BIP68)不起作用。 如果新的共识规则是“只在nVersion大于2时执行segwit规则”，攻击者可以通过改变nVersion窃取segwit输出中存储的所有加密货币(因为nVersion只通过segwit签名认证，但nVersion小于2时不检查)。 OP_NOPx可用于标识见证程序。但是这样会让所有的见证都多一个字节，占用有限的OP_NOPx空间。？最终版本使用BIP62的所谓“干净堆栈”策略规则。虽然现在已经撤销了BIP62，但是它的规则仍然作为一个策略来实现。“清除堆栈”要求脚本评估必须以唯一的堆栈项目结束。然而，最终的见证程序设计留下了两个堆栈。这基本上没问题，但是违反了“干净堆栈”策略。？失败案例：BIP16和支付脚本hash
(P2SH)BIP16率先计划实现比特币软分叉。当55%的哈希功率表示就绪时(当前使用率约为80%至95%)，它被激活。在引入P2SH之前，没有检查支出产出形式的政策。所以相当一部分矿工在软叉激活几个月后一直在产生无效块，偶尔会产生长区块链。案例：莱特币的隔离证人。比特币隔离见证实现后不久，Litecoin就开始整合segwit的代码。然而，尽管segwit是在比特币核心0.13.1中发布的，但当时Litecoin的最新版本是0.10.4，不包含“干净堆栈”规则。Litecoin的开蓑衣网小编2022发者试图通过在segwit中增加一个额外的共识规则来解决这个问题，要求block版本必须至少是0x20000000，希望强制矿工升级。事实证明，所有的矿工都是在激活前升级的(最后一个大型矿工是在激活前几个小时升级的)，没有分叉是因为上一个版本没有CLEANSTACK。
？如果大矿池不在最后一刻升级，额外的块版本规则只能提供很少的保护。这将在下一篇文章中进一步讨论。政策保护不是万能的此时读者可能会发现，上述政策保护措施只会阻止未评级矿工在软叉激活后主动产生第一个无效块。但是，如果创建了这个无效块，那么没有升级的矿工就会接受它。同时，如果有更多的工作证明支持，这个区块链会越来越长。因此，这只是减少而不是完全消除软分叉激活中意外的区块链分叉的一种方式。如果大量的矿工通过不同的完整节点运行不同的策略规则，那么这个策略保护也是有问题的。文章来自BitMEX (www.bitmex.com)[x]