BIP 119 以及如何变更比特币的共识规则

作者：Keags

来源：https://bitcoinmagazine.com/technical/exploring-bip119-and-changes-made-to-bitcoin

在过去几周中，有一股力量在推动以 “BIP 119” 或说 “CTV” 为名的比特币升级提议。本文想做两件事：其一，我想介绍 CTV 的重要属性；其二，我想厘清当前在比特币社区中正在发生的两场相互关联的争论。

在比特币中，我们要认真对待 “别轻信，自己验证（Don’t Trust, Verify）” 的格言。因此，我在本文中说的任何内容，都应该跟 BIP119 原文以及实现它的 Pull Request 交叉验证。

此外，虽然我在这里讲的东西自身都能站得住脚，不需要谁来颁发证书，我还是想说，至撰写本文之时，我已经开发比特币技术乃至比特币本身近 5 年了。有这个背景不代表我就绝对正确，但应该至少能说服你：这篇文章出自知情人士之手，不会浪费你的阅读时间。

免责声明：我已经公开支持在比特币主网上激活 BIP 119。所以我没法给你一个 “不偏不倚” 的观点。不过，我会尽力说明什么是事实、什么是观点。

最后，这篇文章假设读者对比特币的工作原理、比特币交易的结构以及比特币中的脚本系统有一些基本的了解。

那么，什么是 “CTV”？CTV 是 “CheckTemplateVerify” 的缩写，是一个给比特币提议的共识规则变更。这个提议本质上是给比特币的脚本系统增加一种操作，使之能阻止一笔资金被花费，除非花费该资金的交易具备特定的 “模板”。

这是比特币脚本系统前所未有的功能，因此产生了一些争议。截至本文撰写之时，你在比特币上能够设置的花费条件，要么是基于时间的（CHECKLOCKTIMEVERIFY 和 CHECKSEQUENCEVERIFY），要么是基于 “见证数据（witeness）” 的（见证数据是指你向比特币网络出示的、证明你有权花费这些币的证据）。

今天的比特币脚本中，没有操作码可以用来指定花费资金的交易必须满足的条件。这种对交易本身施加限制的设计和操作码通常被称为 “covenants（限制条款）”。还有许多正在比特币社区中讨论的提议也属于这个类别，但是，究竟什么是限制条款，为什么我们想要这个功能呢？

限制条款最重要的特性是，你可以在花费由它们约束的资金的交易的输出上施加限制。回忆一下，比特币交易带有一些输入（也就是你想花费的资金）以及一些输出（资金转移的目的地）以及见证数据（证明你可以花费这些币的证据）。

能够指定未来你想花费这些币的可能方式，让我们可以创建更加安全的冷存储解决方案。举个例子，假设你想限制从冷存储中取出资金的速度，每个月不得超过 10%。有了限制条款之后，你可以这样构造你的花费条件：在你存入资金的一个月后，要么取出 10% 到一个预先指定的热存储地址中，剩余的 90% 转移到一个新的（类似的）冷存储钱包中；要么，将所有资金转到一个新的、带有类似设置的冷存储钱包中。这样的安排的价值在于，你可以保证，即使你的资金存储方案被攻破了，在重建安全的方案之前，你最多只会有 10% 的资金损失。这种用途常常被称为 “金库（vault）”。

但这不是限制条款的唯一用途。你需要限制条款来实现许多 “携带状态” 的合约。我没有能力细数这样的应用场景，但这里有一个很长的清单，而在这个网页上也有更好的阅读材料。

回到 CTV 具体来说。CTV 是怎么工作的？CTV 取出比特币虚拟机栈顶的元素，验证当前交易的 “模板哈希值” 与这个元素值一致。这必然意味着，如果你想花费由 CTV 保护起来的资金，你必须在把资金 存入 这个 CTV 保护的地址 之前 就知道未来的花费交易的模板哈希值。

为什么是这样？因为花费交易的模板哈希值是嵌入到你锁定资金的脚本中的，而因为哈希函数是单项的，你必须提前知道这个交易：要在事后找出一个模板哈希值等于脚本中哈希值的交易，等同于破解比特币的挖矿算法。

这种设计的结果是，CTV 相比于其竞争对手会简单很多。首先，一个 CTV 合约的所有 “退出路径” 都是提前已知的。这使得 CTV 合约安全性的分析容易得多，也因此更不容易导致你的资金意外永久锁定。

在结束对 CTV 如何工作的讨论前，我们来说说 “模板哈希值” 是怎样生成的，因为它最终决定了你在生成一个 CTV 合约之前要承诺什么。模板哈希值覆盖了交易的版本、locktime（时间锁）、输入的数量、sequence number（序列号，用来执行包括交易层面的相对时间锁等功能）、输出的数量、输出的哈希值和数值。这包含了一笔交易的绝大部分，但不包括输入的 ID 和见证数据。本质上，这意味着你必须知道你想用来花费这些资金的确切交易。它使 CTV 的设计没有什么回旋的余地，不会出现那些有缺陷的设计中的 bug。这是另一个 CTV 相比其它提议，需要分析的界面更小的原因。

那么，技术社区当前对这个主题的意见如何呢？某些限制条款机制是有用的，这似乎取得了广泛的共识。但分歧依然存在：（尤其是）CTV 是我们下一步最好的选择吗？其它提案能否提供更好的取舍？

许多人支持多研究一下其他为比特币添加限制条款的方案。这在原则上是没问题的。问题是，我第一次知道 CTV 是在 Bitcoin2019 大会上，这都快三年了。所以，虽然它对许多人来说还是个新想法，还是有一些人已经参与这个讨论经年之久，并且在持之以恒地分辨下一步应该怎么做。不过，对比特币人来说，保持对共识变更提议的怀疑主义精神是很重要的。这就是比特币的强大之处。

如果你已经读到这里了，但依然不觉得 CTV 有何吸引力的话，那也没什么。比特币的任何操作码都是你自愿选择使用的。有一个 multisig（多签名）操作码并不代表你就一定要使用它，CTV 也一样。CTV 也不会改变你现有的币的花费方式。即使 CTV 激活，你也要主动将币转移到一个 CTV 地址中，这样才会影响你的币在比特币网络中转移的能力。

我经常讲，这种类型的变更是 “非侵入式的”，因为只有你自己想要时，它们才会影响到你。进一步来说，我认为，适应这样的变化的意愿也是很重要的，即使你自己并不想使用它们：也许在未来某一天，你也会需要一种非侵入式变更，所以你可以建设一种合作的文化，帮助更多人得到他们想要的变更。如果一种变更会伤害你，或者会改变比特币的一些（对你来说）重要的属性，你应该毫不犹豫地反对，但并非所有变更都有这样的风险，在我看来，CTV 就没有这两个问题。

那么，为什么还会有争议呢？在本文剩下的篇幅里，我想转移一下话题，谈谈共识规则变更的激活程序。这才是争议的核心所在。争议的第一部分产生于一个事实：许多人认为，想在这个夏天就激活 CTV 有点操之过急了。如果你才刚刚了解到 CTV，你可能也会这样想。但就像我前面说到的，对一些人来说，CTV 是一个已经筹备了接近 3 年的提议的。这是根本的矛盾。

在比特币中，你如果不真的尝试一下，就几乎不可能知道一个提议到底有多少支持。每个人对社会共识的观点，都是被自己在网络中的关系加过滤镜的。每个人对社会共识的观点都是独一无二的，也是有意义的，但最终来说是不完备的。有一些研究指出了如何提高我们对民意的整体理解，但比特币的独特之处，也让解决办法很难让所有人都觉得公平。此外，我们去年才刚刚激活一个共识变更。哪怕 Taproot 激活几个月了，也还是有许多人根本不知道它有什么功能，更不用说它是怎么工作的了。

尽管似乎缺乏对 Taproot 的教育，似乎也没有人对它的激活感到不安。我猜测这是因为技术社区几乎普遍认为 Taproot 是一个好主意，而且共识和激活代码都在一个 Bitcoin Core 更新中正式发布了（我相信这使得人们更倾向于接受它）。

这跟我接下来要讲到的情形大相径庭。但细说现状之前，我想再说说 Taproot 的情形：即使 Taproot 的激活得到了压倒性的支持，激活的 方法 也是（依然是）众口难调。

这也揭示了 CTV 争论的一些方面。也就是说，实际上有两场争论。第一个争论的主题是：“我们真的想要 CTV 吗？” 第二个争论的主题是：“假设我们想要 CTV，合理的激活方式是什么样的？” CTV 提议的作者 Jeremy Rubin 在自己的博客中写了一篇文章解释自己将采取的步骤以及背后的理由，包括要放出一个比特币客户端，基于 Bitcoin Core，包含最早会在 2022 年激活 CTV 的代码。

虽然负责激活的代码是直接从 Taproot 的相关代码中取出来的，一个重要的区别是，CTV 尚未被合并到 Bitcoin Core 中，激活它的代码也没有。这些机会因为一些争议，已经被放弃了，因为这些争议显著表明现在没有共识。在我看来，整个推动激活、收集反馈、再次尝试的流程，正是共识建立的过程。不管怎么说，如果没有人声援 Taproot，它就不可能在比特币网络上激活。

那么，目前我们面临什么情形呢？当前推动 CTV 激活的尝试已经终止，转而希望在公开的讨论中建立共识。CTV 的优缺点将在接下来的几个月中得到讨论。与此同时，也有许多关于未来的软分叉应该如何激活的讨论，我们希望比特币既能保持合理的升级能力，又不让整个流程被那些希望篡改比特币特性的人劫持。

（完）