（OP_VAULT 和预签名式的保管库流程对比，来源：BIP-345）
更健壮和灵活的状态通道
一般可以认为，包括闪电网络在内的状态通道拥有和主链近乎等同的安全性（在保证节点可观察最新状态、能够正常发布最新状态上链的情况下）。然而在有了限制条款之后，一些新的状态通道的设计想法可以在闪电网络的之上更加健壮或灵活。这其中比较知名的包括 Eltoo、 Ark 等。
Eltoo （也称为 LN-Symmetry）就是其中一个比较典型的例子。这个技术方案取「L2」的谐音，为闪电网络提出了一种执行层，允许任何后来的通道状态取代之前的状态，而不需要惩罚机制，因此也可以同时避免类似闪电网络节点那种必须保存多个之前状态以防止对手作恶。为了实现上述效果， Eltoo 提出了 SIGHASH_NOINPUT 的签名方式，即 APO（BIP-118）。
而 Ark 旨在降低闪电网络的入站流动性和通道管理等难度。它是一种 joinpool 形式的协议，多个用户都可以在一定时间内接受一个服务提供商作为交易对手，在链外进行虚拟 UTXO（vUTXO）的交易，但在链上共享一个 UTXO从而降低成本。和保管库类似，Ark 也可以在当前的比特币网络上实现；但引入了限制条款之后，Ark 可以基于交易模板降低所需要的交互量，实现更去信任化的单边退出。
Covenants技术概览
从上述应用可以看到，Covenants限制条款更像一个效果而非某种技术，因此有许多种实现的技术方式。如果进行分类，可以包括：
类型：通用型、专用型
实现方式：基于 Opcode、基于签名
递归：递归、非递归
而其中，递归是指：有一些限制条款的实现，也可以通过限制下一笔输出来限制再下一笔的输出，可以实现添加的限制可以超越一笔交易，达到更高的交易深度。
一些主流的限制条款设计包括：
Covenants限制条款的设计
从前面的介绍可以看出来，目前的比特币脚本主要限制了解锁的条件，没有限制该 UTXO 如何进一步被花费。要实现限制条款，我们就要反过来思考：为什么目前的比特币脚本无法实现Covenants限制条款？
原因主要在于目前的比特币脚本无法读取交易自身的内容，即交易的「内省」（introspection）。
如果我们可以实现交易的内省——检查交易的任何内容（包括输出），那么就可以实现限制条款了。
因此限制条款的设计思路也主要围绕在如何实现内省上。
基于操作码 vs 基于签名
最简单粗暴的想法是，增加一个或多个操作码（即一个操作码+多种参数，或多个不同功能的操作码），直接读取交易的内容。这个也就是基于操作码的思路。
而另外一种思路是，可以不在脚本中直接读取和检查交易自身的内容，而是可以利用交易内容的哈希——如果已经对这个哈希进行了签名，那么只要在脚本里改造例如 OP_CHECKSIG 等来实现对这个签名的检查，就可以间接的实现交易内省及限制条款了。这个思路就是基于签名的设计方式。主要包括 APO 及 OP_CSFS 等。
APO
SIGHASH_ANYPREVOUT（APO）是提议中的一种比特币签名方式。签名的最简单的方式是对交易的输入输出都承诺，但比特币还有更为灵活的方式，即 SIGHASH，选择性地对一笔交易中的输入或输出进行承诺。
目前 SIGHASH 及其组合对交易输入输出的签名范围（来源《Mastering Bitcoin, 2nd》
如上图所示，除了适用到全部数据的 ALL 之外，NONE 的签名方式是只适用到所有输入，而不用于输出；SINGLE 是在此基础上，只对适用到相同输入序号的输出。另外，SIGHASH 还可以组合，叠加了 ANYONECANPAY 修饰符后，只适用于一笔输入。
而 APO 的 SIGHASH 则是只对输出签名，而不对输入部分签名。这也就意味着，用 APO 方式签名之后的交易，可以在之后附加到任何一个满足条件的 UTXO 上。
这种灵活性是 APO 实现限制条款的理论基础：
可以预先创建一笔或多笔交易
通过这些交易的信息构建出一个只能求出一个签名的公钥
这样任何发送到该公钥地址上的资产都只能通过预先创建的交易来花费
值得注意的是，因为这个公钥没有对应的私钥，所以可以确保这些资产只能通过预先创建的交易来花费。那么，我们就可以在预先创建的这些交易中规定资产的去向，从而实现限制条款。
我们可以进一步通过对比以太坊的智能合约来理解：通过智能合约我们可以实现的也是只有通过一定的条件，才能从合约地址中取款，而非靠一个 EOA 签名就任意花费。从这一点来讲，比特币通过签名机制的改进就可以实现这种效果。
但上述过程中的问题在于计算时存在循环依赖，因为需要知道输入的内容来预签并创建交易。
APO 以及 SIGHASH_NOINPUT 实现这种签名方式的意义在于可以解决这种循环依赖问题，在计算时只需要知道（指定）交易的全部输出即可。
OP_CTV
OP_CHECKTEMPLATEVERIFY （CTV） ，即 BIP-119 ，采用了改进Opcode 的方式。它将 commitment hash 作为参数，并要求任何执行操作码的交易都包含一组与该承诺匹配的输出。通过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 在链上只用1 utxo 的区块空间就可以构造一个涉及多个用户的账户余额变更。
来源：https://twitter.com/OwenKemeys/status/1741575353716326835
而如果其中一个叶子是闪电通道、是cold storage、是其他支付路径呢？那么这棵树将从单维多层的支出树扩展至多维多层次的支出树，能支持的场景将更为丰富和灵活。
来源：https://twitter.com/OwenKemeys/status/1741575353716326835
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 最近受到很多关注，也有过 PR review，是当前最热门的升级提议之一。
结语
「自律带来自由」，从上面的介绍可以看到，限制条款可以直接在比特币脚本中实现对交易进一步花费的限定，从而实现类似智能合约效果的交易规则。相比于 BitVM 等链外方式，这种编程方式可以更为原生的在比特币上验证，同时也可以改进主链上的应用（拥堵控制）、链外应用（状态通道）以及其他的新的应用方向（staking 惩罚等）。
限制条款的实现技术如果能再结合一些底层的升级，会进一步释放可编程性的潜力。例如，最近在 review 中的 64 位运算符的提案，就可以进一步与提议的 OP_TLUV 或其他的限制条款结合，可以基于交易输出的聪的数量来进行编程。
但限制条款也可能会导致一些计划外的滥用或漏洞，因此社区对此也比较谨慎。另外，限制条款的升级也需要涉及到共识规则的软分叉升级。鉴于 taproot 升级时的情形，限制条款相关的升级可能也需要假以时日来完成。
特别鸣谢：感谢阿剑、Fisher、Ben 对本文的审阅和建议！
原文链接：https://medium.com/hashkey-capital-insights/covenants-programmability-of-bitcoin-0e646510b197
APP 
