HashKey Capital研报：Covenants，比特币的可编程性

原文作者：HashKey Capital Head of Investment Research Jeffrey HU、HashKey Capital Investment Manager Harper LI

近期比特币社区里掀起来一波关于重新启用 OP_CAT 等操作码的讨论。Taproot Wizard 也通过推出 Quantum Cats 的 NFT、声称已经获得 BIP-420 的编号等，吸引了不少人的注意力。支持者宣称，启用了 OP_CAT 可以实现「限制条款」（covenants）、实现比特币的智能合约或可编程性。

如果你注意到「限制条款」这个词并稍作搜索，就会发现这是另一个很大的兔子洞。开发人员已经讨论了多年，除了 OP_CAT 之外，还有 OP_CTV、APO、OP_VAULT 等等实现限制条款的技术。

那么，究竟什么是比特币的「限制条款」？为什么能吸引到如此多的开发人员持续数年的关注和讨论？能实现比特币的哪些可编程性？背后的设计原理是什么样的？本文试做一个概览性的介绍和讨论。

什么是「限制条款」

Covenants，中文译作「限制条款」，有时也翻译为「契约」，是一种能够给未来的比特币交易设置条件的机制。

当前的比特币脚本也包含了限制的条件，例如花费的时候要输入合法的签名、送入符合的脚本等。但是只要用户能解锁，就可以将该 UTXO 花到任意他希望的地方。

而限制条款是，在此限制如何解锁的基础之上，做出更多限制，例如限制 UTXO 之后的花费，也就是实现类似「专款专用」的效果；或一笔交易中送入的其他输入条件等。

更为严谨地说，目前的比特币脚本也具备一定的限制条款，例如基于操作码的时间锁，就是通过内省交易的 nLock 或者 nSequence 字段来实现交易花费前的时间限制，但也基本仅限于时间方面的限制。

那么，开发和研究人员为什么要设计这些限制检查？因为限制条款不只是为了限制而限制，更是设置了交易执行的规则。这样，用户只能按照预先设定的规则来执行交易，从而完成预定的业务流程。

所以比较反直觉的是，这可以解锁更多应用场景。

应用场景

确保 Staking 的惩罚

限制条款的一个最直观的例子是 Babylon 在 Bitcoin staking 流程中的 slash 交易。

Babylon 的 Bitcoin staking 过程是用户将自己的 BTC 资产在主链上发送到一个特殊的脚本中，花费条件包括两种：

Happy ending：经过一定的时间后，用户用自己的签名即可解锁，即完成 unstake 的过程

Bad ending：如果用户在某个被 Babylon 租借安全性的 PoS 链上有双签等作恶行为，那么通过 EOTS（extractable one-time signatures，一次性可提取签名），可以解锁出这部分资产，并由网络中的执行角色将一部分资产强制发送到燃烧地址（slash）

来源：Bitcoin Staking: Unlocking 21 M Bitcoins to Secure the Proof-of-Stake Economy

注意这里的「强制发送」，这意味着即便是可以解锁这笔 UTXO，但该资产不能任意地发送到其他任何地方，只能燃烧掉。这样才能保证作恶的用户无法抢先用自己已知的签名把资产转回给自己，以逃脱惩罚。

这个功能如果在 OP_CTV 等限制条款实现后，可以在 staking 脚本的「bad ending」分支中增加 OP_CTV 等 opcode 以实现限制。

而在 OP_CTV 启用前，Babylon 就需要通过变通的方法，由用户 + 委员会共同执行的方式来模拟实现限制条款强制执行的效果。

拥堵控制

一般而言，拥堵是指当比特币网络上手续费率很高，交易池中积攒了比较多的交易等待打包，所以如果用户想要快速确认交易，就需要提高手续费。

而此时如果一个用户必须发送多笔交易给多个收款方，就不得不提高手续费，承担比较高的成本。同时也相应的会进一步推高整个网络的手续费率。

如果有了限制条款，一个解决方法是发送方，可以先承诺到一笔批量发送的交易上。这个承诺可以让所有的接收方相信，最终的交易都会进行，可以等到手续费率低的时候再发送具体的交易即可。

如下图所示，当对区块空间的需求很高时，进行交易变得非常昂贵。通过使用 OP_CHECKTEMPLATEVERIFY，大批量支付处理商可以将其所有付款聚合到单个 O（1） 事务中以进行确认。然后，一段时间后，当对区块空间的需求减少时，付款可以从该 UTXO 中扩展出来。

来源：https://utxos.org/uses/scaling/