详解限制条款:实现比特币的可编程性

近期比特币社区掀起了一波关于重新启用 OP_CAT 等操作码的讨论。Taproot Wizard 通过推出 Quantum Cats NFT 和声称获得 BIP-420 编号等方式,吸引了不少人的注意力。支持者宣称,启用 OP_CAT 可以实现"限制条款",从而实现比特币的智能合约或可编程性。

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

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

什么是"限制条款"

限制条款(Covenants)是一种能够给未来的比特币交易设置条件的机制。

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

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

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

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

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

应用场景

确保 Staking 的惩罚

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

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

• 正常情况:经过一定的时间后,用户用自己的签名即可解锁,即完成 unstake 的过程
• 异常情况:如果用户在某个被 Babylon 租借安全性的 PoS 链上有双签等作恶行为,那么通过 EOTS(extractable one-time signatures,一次性可提取签名),可以解锁出这部分资产,并由网络中的执行角色将一部分资产强制发送到燃烧地址(slash)

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

这个功能如果在 OP_CTV 等限制条款实现后,可以在 staking 脚本的"异常情况"分支中增加 OP_CTV 等 opcode 以实现限制。

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

拥堵控制

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

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

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

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

这个场景是 OP_CTV 这个限制条款提出的比较典型的一个应用案例。

保管库

保管库(vault)是比特币应用中一类比较广泛讨论的应用场景,特别是在限制条款领域内。因为日常操作不可避免的要在资金保管与资金使用需求之间进行平衡,所以人们希望能有一类保管金库的应用:可以保证资金安全,甚至即使账户被黑(泄露了私钥),也能限制资金的使用。

基于实现限制条款的技术,保管库类的应用可以比较容易的构建出来。

以 OP_VAULT 的设计方案为例:在花费保管库中的资金时,需要先发送一笔交易上链。这笔交易表明了希望花费保管库的意图,即"trigger",并在其中设置了条件:

• 如果一切正常,那么第二笔交易是最终取款的交易。等待 N 个区块后,可以将资金进一步花费到任意地方
• 如果发现是这笔交易被窃取的(或者是被"扳手攻击"时候胁迫的),在 N 个区块的取款交易发送前,可以立即发送到另一个安全地址(用户更安全的保管)

需要注意的是,在没有限制条款的情况下,也可以构建出来一个保管库应用,一个可行的办法是用私钥来准备好以后花费的签名,然后销毁掉这个私钥。但限制仍然比较多,例如需要确保这个私钥已经销毁掉(类似于零知识证明中的 trusted setup 过程)、金额和手续费提前确定(因为要预签名)因而缺乏灵活性等。

更健壮和灵活的状态通道

一般可以认为,包括闪电网络在内的状态通道拥有和主链近乎等同的安全性(在保证节点可观察最新状态、能够正常发布最新状态上链的情况下)。然而在有了限制条款之后,一些新的状态通道的设计想法可以在闪电网络的之上更加健壮或灵活。这其中比较知名的包括 Eltoo、 Ark 等。

Eltoo (也称为 LN-Symmetry)就是其中一个比较典型的例子。这个技术方案取"L2"的谐音,为闪电网络提出了一种执行层,允许任何后来的通道状态取代之前的状态,而不需要惩罚机制,因此也可以同时避免类似闪电网络节点那种必须保存多个之前状态以防止对手作恶。为了实现上述效果, Eltoo 提出了 SIGHASH_NOINPUT 的签名方式,即 APO(BIP-118)。

而 Ark 旨在降低闪电网络的入站流动性和通道管理等难度。它是一种 joinpool 形式的协议,多个用户都可以在一定时间内接受一个服务提供商作为交易对手,在链外进行虚拟 UTXO(vUTXO)的交易,但在链上共享一个 UTXO 从而降低成本。和保管库类似,Ark 也可以在当前的比特币网络上实现;但引入了限制条款之后,Ark 可以基于交易模板降低所需要的交互量,实现更去信任化的单边退出。

限制条款技术概览

从上述应用可以看到,限制条款更像一个效果而非某种技术,因此有许多种实现的技术方式。如果进行分类,可以包括:

• 类型:通用型、专用型
• 实现方式:基于 Opcode、基于签名
• 递归:递归、非递归

而其中,递归是指:有一些限制条款的实现,也可以通过限制下一笔输出来限制再下一笔的输出,可以实现添加的限制可以超越一笔交易,达到更高的交易深度。

一些主流的限制条款设计包括:

• OP_CTV:通用型,基于 Opcode,非递归
• OP_VAULT:专用型,基于 Opcode,非递归
• APO:通用型,基于签名,非递归
• OP_CAT:通用型,基于 Opcode,递归*
• OP_CSFS:通用型,基于签名,递归

*如果结合 OP_CAT

限制条款的设计

从前面的介绍可以看出来,目前的比特币脚本主要限制了解锁的条件,没有限制该 UTXO 如何进一步被花费。要实现限制条款,我们就要反过来思考:为什么目前的比特币脚本无法实现限制条款?

原因主要在于目前的比特币脚本无法读取交易自身的内容,即交易的"内省"(introspection)。

如果我们可以实现交易的内省——检查交易的任何内容(包括输出),那么就可以实现限制条款了。

因此限制条款的设计思路也主要围绕在如何实现内省上。

基于操作码 vs 基于签名

最简单粗暴的想法是,增加一个或多个操作码(即一个操作码 + 多种参数,或多个不同功能的操作码),直接读取交易的内容。这个也就是基于操作码的思路。

而另外一种思路是,可以不在脚本中直接读取和检查交易自身的内容,而是可以利用交易内容的哈希——如果已经对这个哈希进行了签名,那么只要在脚本里改造例如 OP_CHECKSIG 等来实现对这个签名的检查,就可以间接的实现交易内省及限制条款了。这个思路就是基于签名的设计方式。主要包括 APO 及 OP_CSFS 等。

APO

SIGHASH_ANYPREVOUT(APO)是提议中的一种比特币签名方式。签名的最简单的方式是对交易的输入输出都承诺,但比特币还有更为灵活的方式,即 SIGHASH,选择性地对一笔交易中的输入或输出进行承诺。

而 APO 的 SIGHASH 则是只对输出签名,而不对输入部分签名。这也就意味着,用 APO 方式签名之后的交易,可以在