详解Covenants：如何实现比特币的可编程性？
文章转载来源：HashKeyCapital
作者：HashKeyCapitalHeadofInvestmentResearchJeffreyHU、HashKeyCapitalInvestmentManagerHarperLI
近期比特币社区里掀起来一波关于重新启用OP_CAT等操作码的讨论。TaprootWizard也通过推出QuantumCats的NFT、声称已经获得BIP-420的编号等，吸引了不少人的注意力。支持者宣称，启用了OP_CAT可以实现‘限制条款’（covenants）、实现比特币的智能合约或可编程性。
如果你注意到‘限制条款’这个词并稍作搜索，就会发现这是另一个很大的兔子洞。开发人员已经讨论了多年，除了OP_CAT之外，还有OP_CTV、APO、OP_VAULT等等实现限制条款的技术。
那么，究竟什么是比特币的‘限制条款’？为什么能吸引到如此多的开发人员持续数年的关注和讨论？能实现比特币的哪些可编程性？背后的设计原理是什么样的？本文试做一个概览性的介绍和讨论。
什么是‘限制条款’
Covenants，中文译作‘限制条款’，有时也翻译为‘契约’，是一种能够给未来的比特币交易设置条件的机制。
当前的比特币脚本也包含了限制的条件，例如花费的时候要输入合法的签名、送入符合的脚本等。但是只要用户能解锁，就可以将该UTXO花到任意他希望的地方。
而限制条款是，在此限制如何解锁的基础之上，做出更多限制，例如限制UTXO之后的花费，也就是实现类似‘专款专用’的效果；或一笔交易中送入的其他输入条件等。
更为严谨地说，目前的比特币脚本也具备一定的限制条款，例如基于操作码的时间锁，就是通过内省交易的nLock或者nSequence字段来实现交易花费前的时间限制，但也基本仅限于时间方面的限制。
那么，开发和研究人员为什么要设计这些限制检查？因为限制条款不只是为了限制而限制，更是设置了交易执行的规则。这样，用户只能按照预先设定的规则来执行交易，从而完成预定的业务流程。
所以比较反直觉的是，这可以解锁更多应用场景。
应用场景
确保Staking的惩罚
限制条款的一个最直观的例子是Babylon在Bitcoinstaking流程中的slash交易。
Badending：如果用户在某个被Babylon租借安全性的PoS链上有双签等作恶行为，那么通过EOTS（extractableone-timesignatures，一次性可提取签名），可以解锁出这部分资产，并由网络中的执行角色将一部分资产强制发送到燃烧地址（slash）
来源：BitcoinStaking：Unlocking21MBitcoinstoSecuretheProof-of-StakeEconomy
注意这里的‘强制发送’，这意味着即便是可以解锁这笔UTXO，但该资产不能任意地发送到其他任何地方，只能燃烧掉。这样才能保证作恶的用户无法抢先用自己已知的签名把资产转回给自己，以逃脱惩罚。
这个功能如果在OP_CTV等限制条款实现后，可以在staking脚本的‘badending’分支中增加OP_CTV等opcode以实现限制。
而在OP_CTV启用前，Babylon就需要通过变通的方法，由用户+委员会共同执行的方式来模拟实现限制条款强制执行的效果。
拥堵控制
一般而言，拥堵是指当比特币网络上手续费率很高，交易池中积攒了比较多的交易等待打包，所以如果用户想要快速确认交易，就需要提高手续费。
而此时如果一个用户必须发送多笔交易给多个收款方，就不得不提高手续费，承担比较高的成本。同时也相应的会进一步推高整个网络的手续费率。
如果有了限制条款，一个解决方法是发送方，可以先承诺到一笔批量发送的交易上。这个承诺可以让所有的接收方相信，最终的交易都会进行，可以等到手续费率低的时候再发送具体的交易即可。
如下图所示，当对区块空间的需求很高时，进行交易变得非常昂贵。通过使用OP_CHECKTEMPLATEVERIFY，大批量支付处理商可以将其所有付款聚合到单个O（1）事务中以进行确认。然后，一段时间后，当对区块空间的需求减少时，付款可以从该UTXO中扩展出来。
这个场景是OP_CTV这个限制条款提出的比较典型的一个应用案例。还有更多的应用案例可从https：//utxos.org/uses/找到，除了上述拥堵控制，该网页列举了SoftForkBets、Decentralizedoptions、Drivechains、BatchChannels、NonInteractiveChannels、TrustlessCoordination-FreeMiningPools、Vaults、SaferHashedTimeLockedContracts（HTLCS）Limits等。
保管库
保管库（vault）是比特币应用中一类比较广泛讨论的应用场景，特别是在限制条款领域内。因为日常操作不可避免的要在资金保管与资金使用需求之间进行平衡，所以人们希望能有一类保管金库的应用：可以保证资金安全，甚至即使账户被黑（泄露了私钥），也能限制资金的使用。
基于实现限制条款的技术，保管库类的应用可以比较容易的构建出来。
以OP_VAULT的设计方案为例：在花费保管库中的资金时，需要先发送一笔交易上链。这笔交易表明了希望花费保管库的意图，即‘trigger’，并在其中设置了条件：
需要注意的是，在没有限制条款的情况下，也可以构建出来一个保管库应用，一个可行的办法是用私钥来准备好以后花费的签名，然后销毁掉这个私钥。但限制仍然比较多，例如需要确保这个私钥已经销毁掉（类似于零知识证明中的trustedsetup过程）、金额和手续费提前确定（因为要预签名）因而缺乏灵活性等。
更健壮和灵活的状态通道
一般可以认为，包括闪电网络在内的状态通道拥有和主链近乎等同的安全性（在保证节点可观察最新状态、能够正常发布最新状态上链的情况下）。然而在有了限制条款之后，一些新的状态通道的设计想法可以在闪电网络的之上更加健壮或灵活。这其中比较知名的包括Eltoo、Ark等。
Eltoo（也称为LN-Symmetry）就是其中一个比较典型的例子。这个技术方案取‘L2’的谐音，为闪电网络提出了一种执行层，允许任何后来的通道状态取代之前的状态，而不需要惩罚机制，因此也可以同时避免类似闪电网络节点那种必须保存多个之前状态以防止对手作恶。为了实现上述效果，Eltoo提出了SIGHASH_NOINPUT的签名方式，即APO（BIP-118）。
而Ark旨在降低闪电网络的入站流动性和通道管理等难度。它是一种joinpool形式的协议，多个用户都可以在一定时间内接受一个服务提供商作为交易对手，在链外进行虚拟UTXO（vUTXO）的交易，但在链上共享一个UTXO从而降低成本。和保管库类似，Ark也可以在当前的比特币网络上实现；但引入了限制条款之后，Ark可以基于交易模板降低所需要的交互量，实现更去信任化的单边退出。
限制条款技术概览
从上述应用可以看到，限制条款更像一个效果而非某种技术，因此有许多种实现的技术方式。如果进行分类，可以包括：
而其中，递归是指：有一些限制条款的实现，也可以通过限制下一笔输出来限制再下一笔的输出，可以实现添加的限制可以超越一笔交易，达到更高的交易深度。
一些主流的限制条款设计包括：
*递归：如果结合OP_CAT
限制条款的设计
从前面的介绍可以看出来，目前的比特币脚本主要限制了解锁的条件，没有限制该UTXO如何进一步被花费。要实现限制条款，我们就要反过来思考：为什么目前的比特币脚本无法实现限制条款？
原因主要在于目前的比特币脚本无法读取交易自身的内容，即交易的‘内省’（introspection）。
如果我们可以实现交易的内省——检查交易的任何内容（包括输出），那么就可以实现限制条款了。
因此限制条款的设计思路也主要围绕在如何实现内省上。
基于操作码vs基于签名
最简单粗暴的想法是，增加一个或多个操作码（即一个操作码+多种参数，或多个不同功能的操作码），直接读取交易的内容。这个也就是基于操作码的思路。
而另外一种思路是，可以不在脚本中直接读取和检查交易自身的内容，而是可以利用交易内容的哈希——如果已经对这个哈希进行了签名，那么只要在脚本里改造例如OP_CHECKSIG等来实现对这个签名的检查，就可以间接的实现交易内省及限制条款了。这个思路就是基于签名的设计方式。主要包括APO及OP_CSFS等。
APO
SIGHASH_ANYPREVOUT（APO）是提议中的一种比特币签名方式。签名的最简单的方式是对交易的输入输出都承诺，但比特币还有更为灵活的方式，即SIGHASH，选择性地对一笔交易中的输入或输出进行承诺。
如上图所示，除了适用到全部数据的ALL之外，NONE的签名方式是只适用到所有输入，而不用于输出；SINGLE是在此基础上，只对适用到相同输入序号的输出。另外，SIGHASH还可以组合，叠加了ANYONECANPAY修饰符后，只适用于一笔输入。
而APO的SIGHASH则是只对输出签名，而不对输入部分签名。这也就意味着，用APO方式签名之后的交易，可以在之后附加到任何一个满足条件的UTXO上。
这种灵活性是APO实现限制条款的理论基础：
值得注意的是，因为这个公钥没有对应的私钥，所以可以确保这些资产只能通过预先创建的交易来花费。那么，我们就可以在预先创建的这些交易中规定资产的去向，从而实现限制条款。
我们可以进一步通过对比以太坊的智能合约来理解：通过智能合约我们可以实现的也是只有通过一定的条件，才能从合约地址中取款，而非靠一个EOA签名就任意花费。从这一点来讲，比特币通过签名机制的改进就可以实现这种效果。
但上述过程中的问题在于计算时存在循环依赖，因为需要知道输入的内容来预签并创建交易。
APO以及SIGHASH_NOINPUT实现这种签名方式的意义在于可以解决这种循环依赖问题，在计算时只需要知道（指定）交易的全部输出即可。
OP_CTV
OP_CHECKTEMPLATEVERIFY（CTV），即BIP-119，采用了改进Opcode的方式。它将commitmenthash作为参数，并要求任何执行操作码的交易都包含一组与该承诺匹配的输出。通过CTV，将允许比特币用户限制他们使用比特币的方式。
该提案最初以OP_CHECKOUTPUTSHASHVERIFY（COSHV）的名义推出，并且早期侧重于创建拥塞控制交易的能力，因此对该提案的批评也集中在该方案不够通用、过于具体地针对拥塞控制用例。
在上文提到的拥堵控制用例中，发送者Alice可以创建10个输出并对这10个输出进行哈希，并使用生成的摘要来创建一个包含COSHV的tapleaf脚本。Alice还可以使用参与者的公钥来形成Taproot内部密钥，以允许他们在不泄露Taproot脚本路径的情况下合作支出。
然后，Alice会给每个接收者一份所有10个输出的副本，以便他们每个人都验证Alice的设置交易。当他们以后想要花费这笔付款时，他们中的任何一个都可以创建一个包含承诺输出的交易。
在整个过程中，在Alice创建并发送设置交易时，Alice可以通过现有的异步通信方法（如电子邮件或云驱动器）发送这10个输出副本。这意味着，接收者不需要在线，也不需要相互交互。
来源：https：//bitcoinops.org/en/newsletters/2019/05/29/#proposed-transaction-output-commitments
和APO类似，地址也可根据支出条件来构建，可以用不同的方式来制作‘锁’，包括：增加其他的key、时间锁、可组合逻辑。
来源：https：//twitter.com/OwenKemeys/status/1741575353716326835
CTV在此基础上提出了可以检查经过hash后的花费交易是否与定义的匹配，即将交易数据作为开‘锁’的密钥。
我们可以将上面10个接收者的例子继续延伸，接收方可进一步将其地址密钥设置为已签名但未广播的tx发送给下一批接收方地址，以此类推，形成一个如下图所示的树状结构。Alice在链上只用1utxo的区块空间就可以构造一个涉及多个用户的账户余额变更。
来源：https：//twitter.com/OwenKemeys/status/1741575353716326835
而如果其中一个叶子是闪电通道、是coldstorage、是其他支付路径呢？那么这棵树将从单维多层的支出树扩展至多维多层次的支出树，能支持的场景将更为丰富和灵活。
来源：https：//twitter.com/OwenKemeys/status/1744181234417140076
CTV自提出以来，经历了2019年从COSHV更名、在2020年被分配了BIP-119，并出现用于创建支持CTV合约的编程语言Sapio，在22、23年得到了社区很多讨论、更新，以及对其激活方案的争论，目前仍是社区讨论比较多的一个软分叉升级提案之一。
OP_CAT
OP_CAT如开篇所介绍的，也是一个目前非常受关注的升级提案，实现的功能对堆栈中的两个元素进行拼接（concatenante）。虽然看上去很简单，但OP_CAT可以很灵活的在脚本中实现很多功能。
最直接的例子就是对于merkle树相关的操作。Merkle树可以理解为两个元素先拼接，再进行hash。目前比特币脚本里有OP_SHA256等hash的操作码，所以如果能用OP_CAT实现对两个元素拼接，就可以在脚本中实现merkle树的验证功能，也就在一定程度上具备了轻客户端验证的能力。
另外的实现基础还包括对于Schnorr签名的增强：可以对脚本的花费签名条件设置为用户的公钥和公开nonce的拼接；之后如果签名者如果想要另签一个交易将这笔资金花费到其他地方，就不得不使用同样的nonce而导致私钥泄露。也就是通过OP_CAT实现了对nonce的承诺，进而确保已签名交易的有效性。
OP_CAT的其他的应用场景还包括：Bistream、树形签名、抗量子的Lamport签名、保管库等等。
OP_CAT本身并不是一个新的功能，它曾在比特币最早期版本中存在过，不过由于可能导致被攻击所利用而在2010年开始被禁用。例如，重复使用OP_DUP和OP_CAT就可以很容易的让全节点在处理此类脚本时堆栈爆炸，参考这个demo。
但现在重新启用OP_CAT不会发生前面提到的堆栈爆炸问题么？因为当前的OP_CAT提案只涉及到在tapscript中启用，而tapscript限定了每个堆栈元素不超过520字节，所以不会产生以前的堆栈爆炸问题。还有一些开发者认为中本聪直接禁用OP_CAT可能过于严苛。但由于OP_CAT的灵活性，可能确实一些会导致漏洞的应用场景在当前无法穷尽。
所以综合了应用场景和潜在风险等，OP_CAT最近受到很多关注，也有过PRreview，是当前最热门的升级提议之一。
结语
‘自律带来自由’，从上面的介绍可以看到，限制条款可以直接在比特币脚本中实现对交易进一步花费的限定，从而实现类似智能合约效果的交易规则。相比于BitVM等链外方式，这种编程方式可以更为原生的在比特币上验证，同时也可以改进主链上的应用（拥堵控制）、链外应用（状态通道）以及其他的新的应用方向（staking惩罚等）。
限制条款的实现技术如果能再结合一些底层的升级，会进一步释放可编程性的潜力。例如，最近在review中的64位运算符的提案，就可以进一步与提议的OP_TLUV或其他的限制条款结合，可以基于交易输出的聪的数量来进行编程。
但限制条款也可能会导致一些计划外的滥用或漏洞，因此社区对此也比较谨慎。另外，限制条款的升级也需要涉及到共识规则的软分叉升级。鉴于taproot升级时的情形，限制条款相关的升级可能也需要假以时日来完成。
感谢阿剑、Fisher、Ben对本文的审阅和建议！