精通比特币(89):改变共识之软分叉

并非所有共识规则的变化都会导致硬分叉。只有向前不兼容的共识规则的变化才会导致分叉。如果共识规则的改变也能够让未修改的客户端仍然按照先前的规则对待交易或者区块，那么就可以在不进行分叉的情况下实现共识修改。这就是软分叉，来区分之前的硬分叉。实际上软分叉不是分叉。软分叉是与共识规则的向前兼容并作些变化，允许未升级的客户端程序继续与新规则同时工作。

软分叉级只能用于增加共识规则约束，而不是扩展它们。为了向前兼容，根据新规则创建的交易和块也必须在旧规则下有效，但是反之亦然。新规则只能增加限制，否则，根据旧规则创建的交易和区块被拒绝时，还是会将触发硬分叉。

基于NOP操作码的重新解释，在比特币中实现了一些软分叉。 Bitcoin脚本有10个操作码保留供将来使用，NOP1到NOP10。 根据共识规则，这些操作码在脚本中的存在被解释为无效的运算符，这意味着它们没有任何效果。 在NOP操作码之后继续执行，就好像它不存在一样。因此，软叉可以修改NOP代码的语义给它新的含义。

例如，BIP-65（CHECKLOCKTIMEVERIFY）重新解释了NOP2操作码。 实施BIP-65的客户将NOP2解释为OP_CHECKLOCKTIMEVERIFY，并在其锁定脚本中包含该操作码的UTXO上，强制了绝对锁定实践的共识规则。 这种变化是一个软分叉，因为在BIP-65下有效的交易在任何没有实现（不了解）BIP-65的客户端上也是有效的。 对于旧的客户端，该脚本包含一个NOP代码，这被忽略。

NOP操作码的重新解释既是计划的，也是共识升级的明显机制。然而，最近，引入了另一种软分叉机制，其不依赖于NOP操作码，用于非常特定类型的共识改变。 Segwit是一个交易结构的体系结构变化，它将解锁脚本（见证）从交易内部移动到外部数据结构（将其隔离）。

Segwit最初被设想为硬分叉升级，因为它修改了一个基本的结构（交易）。在2015年11月，一位从事比特币核心工作的开发人员提出了一种机制，通过这种机制，可以将软件包引入segwit。用于此的机制是在segwit规则下创建的UTXO的锁定脚本的修改，使得未修改的客户端将任何解锁脚本视为可锁定脚本。

因此，可以引入segwit就是软分叉，而不需要每个节点必须从链上升级或拆分网络。有可能还有其他尚未被发现的机制，通过这种机制可以以向前兼容的方式进行升级，都作为软分叉。

基于NOP操作码的软分叉是相对无争议的。 NOP操作码被放置在比特币脚本中，明确的目标是允许无中断升级。然而，许多开发人员担心软分叉升级的其他方法会产生不可接受的折衷。对软分叉更改的常见批评包括：技术性债务由于软叉在技术上比硬叉升级更复杂，所以引入了技术性债务，这是指由于过去的设计权衡而增加代码维护的未来成本。代码复杂性又增加了错误和安全漏洞的可能性。验证放松未经修改的客户端将交易视为有效，而不评估修改的共识规则。

实际上，未经修改的客户端不会使用全面的协商一致的规则来验证，因为它们对新规则无视。这适用于基于NOP的升级，以及其他软分叉升级。

不可逆转升级因为软分叉产生额外的共识约束的交易，所以它们在实践中成为不可逆转的升级。如果软分叉升级在被激活后被回退，根据新规则创建的任何交易都可能导致旧规则下的资金损失。例如，如果根据旧规则对CLTV交易进行评估，则不存在任何时间锁定约束，并且可以花费在任何时间。因此，评论家认为，由于错误而不得不被回退的失败的软分叉几乎肯定会导致资金的流失。