Covenants：比特币的可编程性
比特币的“Covenants”是一种为未来比特币交易设置条件的机制。本文概述了限制条款的基本概念、应用场景及技术实现方法，并讨论了其背后的设计原则。文章介绍了如OP_CAT、OP_CTV和APO等技术提案，以及它们如何增强比特币的可编程性和智能合约功能。同时，本文还涉及限制条款在比特币网络中的应用，如拥堵控制、金库（vaults）、状态通道等，并讨论了实现限制条款的设计理念及潜在的社区争议。
由 Jeffrey Hu 和 Harper Li 联合撰写
最近在比特币社区中，有关重新启用如OP_CAT等操作码的讨论引起了热议，Taproot Wizard通过推出Quantum Cats的NFT并声称获得了BIP-420的分配而备受关注。支持者们声称，启用OP_CAT将实现“Covenants”，从而为比特币带来智能合约或可编程性。
如果你注意到“Covenants”这个词，并稍加搜索，你会发现这是另一个大的研究领域。多年来，开发者们一直在讨论实现Covenants的技术，如OP_CTV、APO、OP_VAULT等，除了OP_CAT之外。
更确切地说，当前的比特币脚本也有一些类型的Covenants，例如基于操作码的时间锁定，通过检查交易的nLock或nSequence字段来限制交易在一定时间内不能被花费，但这些仍然仅限于时间限制。
那么，到底什么是比特币的“Covenants”？为什么它多年来吸引了这么多开发者的关注和讨论？比特币的可编程性可以实现到什么程度？它背后的设计原则是什么？本文试图提供一个概述和讨论。
什么是“Covenants”？
Covenants是一种可以为未来比特币交易设置条件的机制。事实上，目前的比特币脚本中已经包含了约束条件，例如必须输入合法签名、在花费时提交合规的脚本。只要用户能解锁，就可以将UTXO（未花费的交易输出）用于任何用途。
而Covenants是在这种解锁限制的基础上，增加更多的限制，例如在花费之后限制UTXO的使用，这类似于资金划拨或其他交易输入条件的效果。
那么，为什么开发者和研究人员要设计这些限制检查呢？因为Covenants不仅仅是限制，而是为了设定交易执行的规则。通过这种方式，用户只能按照预设规则执行交易，从而完成预期的业务流程。
相对直观的是，这带来了更多的应用场景。
应用场景
确保质押惩罚
Covenants的一个最直观的例子是Babylon在比特币质押过程中的削减交易。
Babylon的比特币质押过程涉及用户将其BTC发送到主链上的一个特殊脚本，具有两个支出条件：
- Happy ending：在一定时间后，用户可以通过自己的签名解锁，这意味着质押过程完成。
- Bad ending：如果用户在PoS链上进行双重花费攻击，用户可以通过EOTS（可提取一次性签名）解锁资产，并由网络中的执行者将部分资产强制发送到销毁地址（削减）。
来源：《比特币质押：解锁2100万比特币以保障权益证明经济》
注意“强制”一词，这意味着即使UTXO可以解锁，资产也不能被发送到其他地方，只能被销毁。这确保了恶意用户不能通过自己的已知签名将资产转回自己。
这种特性在实现如OP_CTV（CheckTemplateVerify）等Covenants后，可以通过在质押脚本的“坏结局”中添加操作码来实现。在OP_CTV启用之前，Babylon需要通过用户和委员会的合作来模拟强制执行Covenants的效果。
拥堵控制/扩展
常来说，比特币网络拥堵是指交易费用较高、交易池中积累了大量等待打包的交易，因此，如果用户希望快速确认交易，就需要提高费用。
此时，如果用户需要向多个地址发送多笔交易，他们将不得不提高费用，导致成本增加。这将进一步推高整个网络的交易费用。
如果有Covenant，则有解决方案：一个包含多个输出的单一承诺交易。这种承诺可以让所有接收方确信最终交易会发生，每个人可以等到费用降低后再发送具体交易。
如下所示，当区块空间需求高时，进行交易的成本非常高。通过使用OP_CHECKTEMPLATEVERIFY（OP_CTV），一个高流量支付处理器可以将其所有支付合并到一个O(1)交易中进行确认。然后，经过一段时间，当区块空间需求下降时，可以从该UTXO中扩展出支付。
来源： https://utxos.org/uses/scaling/
这种场景是OP_CTV限制所展示的一个典型用例。更多用例可以在UTXOs找到。除了上述提到的拥堵控制，该页面还列出了软分叉下注、去中心化期权、驱动链、批量通道、非交互式通道、无需信任的无协调挖矿池、金库（Vaults）、更安全的哈希时间锁定合约（HTLCs）限制等。
金库（Vaults）
金库是比特币应用中讨论最广泛的用例之一，尤其是在Covenants的领域。由于日常操作不可避免地需要平衡资金安全和使用的需求，人们希望有一个金库能够保障资金安全，甚至在账户被黑客攻击（例如，私钥被泄露）时限制其使用。
基于用于实现限制条款的技术，这种托管金库可以相对容易地构建。
以OP_VAULT的设计方案为例：当要花费金库中的资金时，首先需要向链上发送一笔交易。这笔交易表明花费金库的意图，即“触发器”，并在其中设置条件：
- 正常情况：如果一切顺利，那么第二笔交易最终会提取资金。在等待N个区块后，资金可以进一步花费到任何地方。
- 异常情况：如果交易被盗（或在“触发攻击”中被胁迫），在N个区块后的提取交易发送之前，资产可以立即发送到另一个安全地址（对用户更安全）。
OP_VAULT 流程，来源：BIP-345
需要注意的是，也可以在没有Covenants的情况下建立金库，一种可能的方法是使用私钥准备好用于后期花费的签名，然后销毁这个私钥。然而，这种方法仍然有更多的限制，例如需要确保私钥已经被销毁（类似于零知识证明中的可信设置过程），以及在预签名时难以灵活地确定金额和费用。
预计算金库和 OP_VAULT ，来源：BIP-345
更加稳健和灵活的状态通道
通常认为，状态通道（包括闪电网络）的安全性几乎与主链相同（确保节点能够观察到最新状态并能够正确地将最新状态发布到链上）。然而，通过Covenants，可以在闪电网络基础上设计出更加稳健或灵活的新型状态通道。其中一些较为知名的包括Eltoo和Ark。
Eltoo
Eltoo（也称为LN-Symmetry）是一个典型的例子。作为“L2”的缩写，这项技术提出了一个闪电网络的执行层，允许任何后续通道状态替换先前状态而无需惩罚机制，从而避免了闪电网络节点需要保存多个先前状态以防止对手实施恶意行为。为了实现上述效果，Eltoo提出了SIGHASH_NOINPUT签名和APO（BIP-118）。
Ark
Ark旨在减少闪电网络的入站流动性和通道管理难度。它是一种类似于joinpool的协议，其中多个用户可以在一段时间内接受一个服务提供商作为对手方，并在链下交易虚拟UTXO（vUTXO），但在链上共享一个UTXO以降低成本。类似于金库（vaults），Ark可以在当前的比特币网络上实现；然而，通过引入Covenants，Ark可以基于交易模板减少所需的交互量，实现更加无信任的单向退出。
Covenants概述
从上述应用中可以看出，Covenants更像是一种效果而非某种特定技术，因此有多种技术方式可以实现。它们可以分类为：
- 类型：通用型（generic），限制型（restrictive）
- 实现方式：基于操作码（opcode-based），基于签名（signature-based）
- 递归性：递归（recursive），非递归（non-recursive）
递归意味着：某些Covenants的实现可以通过限制当前交易的输出来限制下一笔交易的输出，这意味着交易链中的每一笔交易都受到前一笔交易的限制。
一些流行的Covenants设计包括：
Covenants的设计
从前面的介绍中可以看出，当前的比特币脚本主要限制了解锁条件，但不限制UTXO（未花费的交易输出）进一步的花费方式。为了实现Covenants，我们需要反向思考：为什么当前的比特币脚本不能实现Covenants？
主要原因是当前的比特币脚本无法读取交易本身，这意味着无法对交易进行内省。如果我们能够实现内省——检查交易中的任何内容（包括输出）——那么我们就可以实现Covenants。因此，Covenants的设计也围绕如何实现内省展开。
基于操作码 vs 基于签名
最简单和最粗暴的想法是添加一个或多个操作码（一个操作码加多个参数，或多个具有不同功能的操作码），直接读取交易的内容。这也被称为基于操作码的设计思路。
另一种思路是，不直接在脚本中读取和检查交易内容，而是使用交易内容的哈希值。这意味着如果该哈希值已经被签名，那么通过在脚本中转换类似于OP_CHECKSIG的操作码来检查这个签名，就可以间接实现交易内省和Covenants。这种思路基于签名的设计方法，主要包括APO（ANYPREVOUT）和OP_CSFS（CheckSigFromStack）。
通过这些技术，Covenants为比特币网络带来了更多的灵活性和可编程性，开辟了新的应用场景和可能性。这使得比特币不仅仅是一种简单的数字货币，还能够实现更加复杂的金融和商业应用。
APO (SIGHASH_ANYPREVOUT)
SIGHASH_ANYPREVOUT (APO) 是一种签名哈希提案。最简单的签名方式是同时提交交易的输入和输出，但比特币可以通过一种更灵活的方式选择性地提交交易的输入或输出，这被称为SIGHASH。
当前SIGHASH范围及其交易输入和输出签名组合
如上图所示，除了适用于所有数据的ALL，NONE的签名方式仅适用于所有输入而不适用于输出，而SINGLE则仅适用于具有相同输入索引号的输出。此外，SIGHASH可以与ANYONECANPAY修饰符结合，仅适用于一个输入。
APO的SIGHASH
与上述不同，APO的SIGHASH仅对输出进行签名，而不对输入签名。这意味着使用APO签名的交易可以在之后附加到任何符合条件的UTXO上。
这种灵活性是APO实现Covenants的基础：
- 可以预先创建一个或多个交易。
- 使用这些交易的信息构建一个公钥，只有通过/检查花费签名才能从中导出。
- 这样，发送到这个公钥地址的任何资产只能通过预创建的交易来花费。
值得注意的是，由于这个公钥没有对应的私钥，确保了这些资产只能通过预创建的交易来花费。然后，我们可以通过在这些预创建的交易中指定资产的去向来实现Covenant。
这种机制可以与以太坊的智能合约进行比较：我们可以通过智能合约实现只有在满足某些条件时才能从合约地址中提取资金，而不是通过EOA（外部拥有账户）签名任意花费。从这个角度来看，比特币可以通过改进签名机制实现这一效果。
OP_CTV
OP_CHECKTEMPLATEVERIFY (CTV)，也称为BIP-119，是一种对操作码的改进。它以承诺哈希（commitment hash）作为参数，要求任何执行该操作码的交易都包含一组与该承诺匹配的输出。通过CTV，比特币用户可以限制他们使用比特币的方式。
最初以OP_CHECKOUTPUTSHASHVERIFY（COSHV）的形式引入，早期主要关注于创建拥堵控制交易的能力，该提案的批评点也集中在其不够通用，过于具体针对拥堵控制用例。
在上述拥堵控制用例中，发送方Alice可以创建10个输出，并将这10个输出的哈希值作为结果摘要，使用该摘要创建包含COSHV的tapleaf脚本。Alice还可以使用参与者的公钥形成一个Taproot内部密钥，使他们能够在不暴露Taproot脚本路径的情况下合作花费资金。
然后，Alice将所有10个输出的副本分发给每个接收方，以便他们可以验证Alice的设置交易。当他们稍后想要花费支付时，任何人都可以创建一个包含承诺输出的交易。
在整个过程中，Alice可以通过现有的异步通信方式（如电子邮件或云盘）发送这10个输出的副本。这意味着接收者无需在线或彼此互动。
来源： https://bitcoinops.org/en/newsletters/2019/05/29/#propose-transaction-output-commitments
类似于APO，可以基于花费条件构建地址，并以不同方式“锁定”它们，包括额外的密钥、相对或固定的时间锁定及其他逻辑来组合它们。
来源： https://twitter.com/OwenKemeys/status/1741575353716326835
基于此，CTV提出检查花费交易的哈希是否与定义的匹配，这意味着交易数据用作解锁“锁”的钥匙。
我们可以拓展上述10个接收者的例子，其中一个接收者可以进一步将其地址密钥设置为一个已签名但未广播的交易，发送给下一批接收者，如此形成一个如图所示的树结构。Alice可以使用一个UTXO的区块空间构建涉及多个用户的账户余额变化。
来源： https://twitter.com/OwenKemeys/status/1741575353716326835
如果其中一片叶子是闪电通道、冷藏库或其他支付路径怎么办？那么树会从单维多层支付树扩展到多维多层支付树，可以支持的场景会更丰富、更灵活。
来源： https://twitter.com/OwenKemeys/status/1744181234417140076
如果其中一个叶节点是闪电通道、冷存储或其他支付路径呢？那么，这棵树将从单维多层支付树扩展为多维多层支付树，支持的场景将更加丰富和灵活。
自提议以来，CTV经历了从2019年的COSHV改名为2020年的BIP-119的过程，并且出现了用于创建支持CTV合约的编程语言Sapio。在2022年和2023年期间，社区对其激活选项进行了大量讨论、更新和辩论，CTV仍然是社区中讨论最多的软分叉升级提案之一。
OP_CAT
OP_CAT，如在开头段落中所述，是一个当前备受关注的升级提案，旨在实现将堆栈中的两个元素或两个数据集连接在一起的功能。尽管看起来简单，但OP_CAT非常灵活，可以在脚本中以多种方式实现。
Merkle树操作：最直接的示例是Merkle树的操作，可以解释为将两个元素连接在一起并进行哈希运算。目前，比特币脚本中有OP_SHA256和其他哈希操作码，因此如果可以使用OP_CAT连接两个元素，就可以在脚本中实现Merkle树验证功能，从而在一定程度上提供轻客户端验证的能力。
Schnorr签名增强：另一种实现基础是Schnorr签名的增强：可以将脚本的花费签名条件设置为用户公钥和公共随机数（nonce）的连接；然后如果签名者想签署另一笔交易以花费其他地方的资金，他或她必须使用相同的随机数，这可能会泄露私钥。也就是说，OP_CAT实现了对随机数的承诺，从而确保签署交易的有效性。
OP_CAT的其他应用包括：
Bistream
树签名
抗量子攻击的Lamport签名
金库（vaults）等
OP_CAT本身并不是新特性，它在比特币的最早版本中就存在，但由于其可能被攻击者利用，在2010年被禁用。例如，重复使用OP_DUP和OP_CAT可能会导致完整节点在处理此类脚本时堆栈爆炸，如在此演示中所见。
那么，重新启用OP_CAT后上述堆栈爆炸问题是否会再次出现呢？当前的OP_CAT提案仅涉及在tapscript中启用它，每个堆栈元素的大小限制为520字节，因此不会导致先前的堆栈爆炸问题。还有一些开发者认为中本聪可能对禁用OP_CAT过于严苛。然而，由于OP_CAT的灵活性，确实可能存在一些可能导致漏洞的应用场景。
由于OP_CAT的应用场景和潜在风险相结合，最近它受到了很多关注，并且已经进行了PR（拉取请求）审核，目前是最热门的升级提案之一。
灵活性：OP_CAT为比特币脚本提供了更大的灵活性，使其能够处理更复杂的数据结构和操作。
应用广泛：OP_CAT可用于多种应用场景，从Merkle树验证到增强Schnorr签名，再到抗量子攻击的签名方案。
安全性改进：通过限制每个堆栈元素的大小，可以避免过去堆栈爆炸的问题。
通过重新启用OP_CAT，比特币网络可以实现更高的可编程性和灵活性，为开发者提供更多的工具和可能性。
结论
“自我约束带来自由”，正如以上介绍所示，Covenants可以直接在比特币脚本中实现，从而限定交易的进一步花费，进而实现类似智能合约的交易规则。这种编程方法可以比像BitVM这样的链下方法更本地化地在比特币上验证，并且能够改进主链上的应用（如拥堵控制）、链下应用（如状态通道）以及其他新的应用方向（如质押削减等）。
如果将Covenants的实现技术与其他升级结合起来，可能会进一步释放可编程性的潜力。例如，最近的64位算术提案可以进一步结合提议的OP_TLUV或其他基于交易输出的聪数量编程的Covenants。
然而，Covenants也可能导致意想不到的滥用或漏洞，因此社区对此也持谨慎态度。此外，Covenants的升级需要涉及共识规则的软分叉升级。鉴于taproot升级的情况，预计与Covenants相关的升级也需要时间来完成。
特别感谢
感谢Ajian、Fisher和Ben的审阅和建议！
参考
- https://utxos.org/
- https://bitcoincovenants.com/
- 与covenants相关的资源集合： https://gist.github.com/RobinLinus/c96fb7c81430ec6dc92f048687bd3068
- https://anyprevout.xyz/
- BIP 345：OP_VAULT提案： https://www.btcstudy.org/2023/04/13/bitcoin-improvement-proposals-345-op-vault-commit-0b0674c546/
- https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf
- https://maltemoeser.de/paper/covenants.pdf
- https://bitcoinops.org/en/topics/op_cat/
- OP_CAT： https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN-2024-0001.md
- CAT 和 Schnorr 技巧： https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
此材料仅供一般信息之用，不构成任何形式的投资建议、招揽或要约，也不应被解释为任何形式的投资建议或招揽，HashKey Capital对使用或依赖任何此类信息不承担任何责任。
关注HashKey Capital的最新动态
推特 - https://twitter.com/HashKey_Capital
领英 — https://www.linkedin.com/company/hashkeycapital/
声明：
1.本文转载自[medium]，版权归原作者所有[Jeffrey Hu和 Harper Li]，如对转载有异议，请联系Gate Learn团队，团队将尽快按照相关流程处理。
2、免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3.文章的其他语言版本由Gate Learn团队翻译，文中未提及Gate.io，翻译的文章不得转载、转发或抄袭。
相关文章
BTC Staking赛道Map梳理
Covenants：比特币的可编程性
比特币的“Covenants”是一种为未来比特币交易设置条件的机制。本文概述了限制条款的基本概念、应用场景及技术实现方法，并讨论了其背后的设计原则。文章介绍了如OP_CAT、OP_CTV和APO等技术提案，以及它们如何增强比特币的可编程性和智能合约功能。同时，本文还涉及限制条款在比特币网络中的应用，如拥堵控制、金库（vaults）、状态通道等，并讨论了实现限制条款的设计理念及潜在的社区争议。
由 Jeffrey Hu 和 Harper Li 联合撰写
最近在比特币社区中，有关重新启用如OP_CAT等操作码的讨论引起了热议，Taproot Wizard通过推出Quantum Cats的NFT并声称获得了BIP-420的分配而备受关注。支持者们声称，启用OP_CAT将实现“Covenants”，从而为比特币带来智能合约或可编程性。
如果你注意到“Covenants”这个词，并稍加搜索，你会发现这是另一个大的研究领域。多年来，开发者们一直在讨论实现Covenants的技术，如OP_CTV、APO、OP_VAULT等，除了OP_CAT之外。
更确切地说，当前的比特币脚本也有一些类型的Covenants，例如基于操作码的时间锁定，通过检查交易的nLock或nSequence字段来限制交易在一定时间内不能被花费，但这些仍然仅限于时间限制。
那么，到底什么是比特币的“Covenants”？为什么它多年来吸引了这么多开发者的关注和讨论？比特币的可编程性可以实现到什么程度？它背后的设计原则是什么？本文试图提供一个概述和讨论。
什么是“Covenants”？
Covenants是一种可以为未来比特币交易设置条件的机制。事实上，目前的比特币脚本中已经包含了约束条件，例如必须输入合法签名、在花费时提交合规的脚本。只要用户能解锁，就可以将UTXO（未花费的交易输出）用于任何用途。
而Covenants是在这种解锁限制的基础上，增加更多的限制，例如在花费之后限制UTXO的使用，这类似于资金划拨或其他交易输入条件的效果。
那么，为什么开发者和研究人员要设计这些限制检查呢？因为Covenants不仅仅是限制，而是为了设定交易执行的规则。通过这种方式，用户只能按照预设规则执行交易，从而完成预期的业务流程。
相对直观的是，这带来了更多的应用场景。
应用场景
确保质押惩罚
Covenants的一个最直观的例子是Babylon在比特币质押过程中的削减交易。
Babylon的比特币质押过程涉及用户将其BTC发送到主链上的一个特殊脚本，具有两个支出条件：
- Happy ending：在一定时间后，用户可以通过自己的签名解锁，这意味着质押过程完成。
- Bad ending：如果用户在PoS链上进行双重花费攻击，用户可以通过EOTS（可提取一次性签名）解锁资产，并由网络中的执行者将部分资产强制发送到销毁地址（削减）。
来源：《比特币质押：解锁2100万比特币以保障权益证明经济》
注意“强制”一词，这意味着即使UTXO可以解锁，资产也不能被发送到其他地方，只能被销毁。这确保了恶意用户不能通过自己的已知签名将资产转回自己。
这种特性在实现如OP_CTV（CheckTemplateVerify）等Covenants后，可以通过在质押脚本的“坏结局”中添加操作码来实现。在OP_CTV启用之前，Babylon需要通过用户和委员会的合作来模拟强制执行Covenants的效果。
拥堵控制/扩展
常来说，比特币网络拥堵是指交易费用较高、交易池中积累了大量等待打包的交易，因此，如果用户希望快速确认交易，就需要提高费用。
此时，如果用户需要向多个地址发送多笔交易，他们将不得不提高费用，导致成本增加。这将进一步推高整个网络的交易费用。
如果有Covenant，则有解决方案：一个包含多个输出的单一承诺交易。这种承诺可以让所有接收方确信最终交易会发生，每个人可以等到费用降低后再发送具体交易。
如下所示，当区块空间需求高时，进行交易的成本非常高。通过使用OP_CHECKTEMPLATEVERIFY（OP_CTV），一个高流量支付处理器可以将其所有支付合并到一个O(1)交易中进行确认。然后，经过一段时间，当区块空间需求下降时，可以从该UTXO中扩展出支付。
来源： https://utxos.org/uses/scaling/
这种场景是OP_CTV限制所展示的一个典型用例。更多用例可以在UTXOs找到。除了上述提到的拥堵控制，该页面还列出了软分叉下注、去中心化期权、驱动链、批量通道、非交互式通道、无需信任的无协调挖矿池、金库（Vaults）、更安全的哈希时间锁定合约（HTLCs）限制等。
金库（Vaults）
金库是比特币应用中讨论最广泛的用例之一，尤其是在Covenants的领域。由于日常操作不可避免地需要平衡资金安全和使用的需求，人们希望有一个金库能够保障资金安全，甚至在账户被黑客攻击（例如，私钥被泄露）时限制其使用。
基于用于实现限制条款的技术，这种托管金库可以相对容易地构建。
以OP_VAULT的设计方案为例：当要花费金库中的资金时，首先需要向链上发送一笔交易。这笔交易表明花费金库的意图，即“触发器”，并在其中设置条件：
- 正常情况：如果一切顺利，那么第二笔交易最终会提取资金。在等待N个区块后，资金可以进一步花费到任何地方。
- 异常情况：如果交易被盗（或在“触发攻击”中被胁迫），在N个区块后的提取交易发送之前，资产可以立即发送到另一个安全地址（对用户更安全）。
OP_VAULT 流程，来源：BIP-345
需要注意的是，也可以在没有Covenants的情况下建立金库，一种可能的方法是使用私钥准备好用于后期花费的签名，然后销毁这个私钥。然而，这种方法仍然有更多的限制，例如需要确保私钥已经被销毁（类似于零知识证明中的可信设置过程），以及在预签名时难以灵活地确定金额和费用。
预计算金库和 OP_VAULT ，来源：BIP-345
更加稳健和灵活的状态通道
通常认为，状态通道（包括闪电网络）的安全性几乎与主链相同（确保节点能够观察到最新状态并能够正确地将最新状态发布到链上）。然而，通过Covenants，可以在闪电网络基础上设计出更加稳健或灵活的新型状态通道。其中一些较为知名的包括Eltoo和Ark。
Eltoo
Eltoo（也称为LN-Symmetry）是一个典型的例子。作为“L2”的缩写，这项技术提出了一个闪电网络的执行层，允许任何后续通道状态替换先前状态而无需惩罚机制，从而避免了闪电网络节点需要保存多个先前状态以防止对手实施恶意行为。为了实现上述效果，Eltoo提出了SIGHASH_NOINPUT签名和APO（BIP-118）。
Ark
Ark旨在减少闪电网络的入站流动性和通道管理难度。它是一种类似于joinpool的协议，其中多个用户可以在一段时间内接受一个服务提供商作为对手方，并在链下交易虚拟UTXO（vUTXO），但在链上共享一个UTXO以降低成本。类似于金库（vaults），Ark可以在当前的比特币网络上实现；然而，通过引入Covenants，Ark可以基于交易模板减少所需的交互量，实现更加无信任的单向退出。
Covenants概述
从上述应用中可以看出，Covenants更像是一种效果而非某种特定技术，因此有多种技术方式可以实现。它们可以分类为：
- 类型：通用型（generic），限制型（restrictive）
- 实现方式：基于操作码（opcode-based），基于签名（signature-based）
- 递归性：递归（recursive），非递归（non-recursive）
递归意味着：某些Covenants的实现可以通过限制当前交易的输出来限制下一笔交易的输出，这意味着交易链中的每一笔交易都受到前一笔交易的限制。
一些流行的Covenants设计包括：
Covenants的设计
从前面的介绍中可以看出，当前的比特币脚本主要限制了解锁条件，但不限制UTXO（未花费的交易输出）进一步的花费方式。为了实现Covenants，我们需要反向思考：为什么当前的比特币脚本不能实现Covenants？
主要原因是当前的比特币脚本无法读取交易本身，这意味着无法对交易进行内省。如果我们能够实现内省——检查交易中的任何内容（包括输出）——那么我们就可以实现Covenants。因此，Covenants的设计也围绕如何实现内省展开。
基于操作码 vs 基于签名
最简单和最粗暴的想法是添加一个或多个操作码（一个操作码加多个参数，或多个具有不同功能的操作码），直接读取交易的内容。这也被称为基于操作码的设计思路。
另一种思路是，不直接在脚本中读取和检查交易内容，而是使用交易内容的哈希值。这意味着如果该哈希值已经被签名，那么通过在脚本中转换类似于OP_CHECKSIG的操作码来检查这个签名，就可以间接实现交易内省和Covenants。这种思路基于签名的设计方法，主要包括APO（ANYPREVOUT）和OP_CSFS（CheckSigFromStack）。
通过这些技术，Covenants为比特币网络带来了更多的灵活性和可编程性，开辟了新的应用场景和可能性。这使得比特币不仅仅是一种简单的数字货币，还能够实现更加复杂的金融和商业应用。
APO (SIGHASH_ANYPREVOUT)
SIGHASH_ANYPREVOUT (APO) 是一种签名哈希提案。最简单的签名方式是同时提交交易的输入和输出，但比特币可以通过一种更灵活的方式选择性地提交交易的输入或输出，这被称为SIGHASH。
当前SIGHASH范围及其交易输入和输出签名组合
如上图所示，除了适用于所有数据的ALL，NONE的签名方式仅适用于所有输入而不适用于输出，而SINGLE则仅适用于具有相同输入索引号的输出。此外，SIGHASH可以与ANYONECANPAY修饰符结合，仅适用于一个输入。
APO的SIGHASH
与上述不同，APO的SIGHASH仅对输出进行签名，而不对输入签名。这意味着使用APO签名的交易可以在之后附加到任何符合条件的UTXO上。
这种灵活性是APO实现Covenants的基础：
- 可以预先创建一个或多个交易。
- 使用这些交易的信息构建一个公钥，只有通过/检查花费签名才能从中导出。
- 这样，发送到这个公钥地址的任何资产只能通过预创建的交易来花费。
值得注意的是，由于这个公钥没有对应的私钥，确保了这些资产只能通过预创建的交易来花费。然后，我们可以通过在这些预创建的交易中指定资产的去向来实现Covenant。
这种机制可以与以太坊的智能合约进行比较：我们可以通过智能合约实现只有在满足某些条件时才能从合约地址中提取资金，而不是通过EOA（外部拥有账户）签名任意花费。从这个角度来看，比特币可以通过改进签名机制实现这一效果。
OP_CTV
OP_CHECKTEMPLATEVERIFY (CTV)，也称为BIP-119，是一种对操作码的改进。它以承诺哈希（commitment hash）作为参数，要求任何执行该操作码的交易都包含一组与该承诺匹配的输出。通过CTV，比特币用户可以限制他们使用比特币的方式。
最初以OP_CHECKOUTPUTSHASHVERIFY（COSHV）的形式引入，早期主要关注于创建拥堵控制交易的能力，该提案的批评点也集中在其不够通用，过于具体针对拥堵控制用例。
在上述拥堵控制用例中，发送方Alice可以创建10个输出，并将这10个输出的哈希值作为结果摘要，使用该摘要创建包含COSHV的tapleaf脚本。Alice还可以使用参与者的公钥形成一个Taproot内部密钥，使他们能够在不暴露Taproot脚本路径的情况下合作花费资金。
然后，Alice将所有10个输出的副本分发给每个接收方，以便他们可以验证Alice的设置交易。当他们稍后想要花费支付时，任何人都可以创建一个包含承诺输出的交易。
在整个过程中，Alice可以通过现有的异步通信方式（如电子邮件或云盘）发送这10个输出的副本。这意味着接收者无需在线或彼此互动。
来源： https://bitcoinops.org/en/newsletters/2019/05/29/#propose-transaction-output-commitments
类似于APO，可以基于花费条件构建地址，并以不同方式“锁定”它们，包括额外的密钥、相对或固定的时间锁定及其他逻辑来组合它们。
来源： https://twitter.com/OwenKemeys/status/1741575353716326835
基于此，CTV提出检查花费交易的哈希是否与定义的匹配，这意味着交易数据用作解锁“锁”的钥匙。
我们可以拓展上述10个接收者的例子，其中一个接收者可以进一步将其地址密钥设置为一个已签名但未广播的交易，发送给下一批接收者，如此形成一个如图所示的树结构。Alice可以使用一个UTXO的区块空间构建涉及多个用户的账户余额变化。
来源： https://twitter.com/OwenKemeys/status/1741575353716326835
如果其中一片叶子是闪电通道、冷藏库或其他支付路径怎么办？那么树会从单维多层支付树扩展到多维多层支付树，可以支持的场景会更丰富、更灵活。
来源： https://twitter.com/OwenKemeys/status/1744181234417140076
如果其中一个叶节点是闪电通道、冷存储或其他支付路径呢？那么，这棵树将从单维多层支付树扩展为多维多层支付树，支持的场景将更加丰富和灵活。
自提议以来，CTV经历了从2019年的COSHV改名为2020年的BIP-119的过程，并且出现了用于创建支持CTV合约的编程语言Sapio。在2022年和2023年期间，社区对其激活选项进行了大量讨论、更新和辩论，CTV仍然是社区中讨论最多的软分叉升级提案之一。
OP_CAT
OP_CAT，如在开头段落中所述，是一个当前备受关注的升级提案，旨在实现将堆栈中的两个元素或两个数据集连接在一起的功能。尽管看起来简单，但OP_CAT非常灵活，可以在脚本中以多种方式实现。
Merkle树操作：最直接的示例是Merkle树的操作，可以解释为将两个元素连接在一起并进行哈希运算。目前，比特币脚本中有OP_SHA256和其他哈希操作码，因此如果可以使用OP_CAT连接两个元素，就可以在脚本中实现Merkle树验证功能，从而在一定程度上提供轻客户端验证的能力。
Schnorr签名增强：另一种实现基础是Schnorr签名的增强：可以将脚本的花费签名条件设置为用户公钥和公共随机数（nonce）的连接；然后如果签名者想签署另一笔交易以花费其他地方的资金，他或她必须使用相同的随机数，这可能会泄露私钥。也就是说，OP_CAT实现了对随机数的承诺，从而确保签署交易的有效性。
OP_CAT的其他应用包括：
Bistream
树签名
抗量子攻击的Lamport签名
金库（vaults）等
OP_CAT本身并不是新特性，它在比特币的最早版本中就存在，但由于其可能被攻击者利用，在2010年被禁用。例如，重复使用OP_DUP和OP_CAT可能会导致完整节点在处理此类脚本时堆栈爆炸，如在此演示中所见。
那么，重新启用OP_CAT后上述堆栈爆炸问题是否会再次出现呢？当前的OP_CAT提案仅涉及在tapscript中启用它，每个堆栈元素的大小限制为520字节，因此不会导致先前的堆栈爆炸问题。还有一些开发者认为中本聪可能对禁用OP_CAT过于严苛。然而，由于OP_CAT的灵活性，确实可能存在一些可能导致漏洞的应用场景。
由于OP_CAT的应用场景和潜在风险相结合，最近它受到了很多关注，并且已经进行了PR（拉取请求）审核，目前是最热门的升级提案之一。
灵活性：OP_CAT为比特币脚本提供了更大的灵活性，使其能够处理更复杂的数据结构和操作。
应用广泛：OP_CAT可用于多种应用场景，从Merkle树验证到增强Schnorr签名，再到抗量子攻击的签名方案。
安全性改进：通过限制每个堆栈元素的大小，可以避免过去堆栈爆炸的问题。
通过重新启用OP_CAT，比特币网络可以实现更高的可编程性和灵活性，为开发者提供更多的工具和可能性。
结论
“自我约束带来自由”，正如以上介绍所示，Covenants可以直接在比特币脚本中实现，从而限定交易的进一步花费，进而实现类似智能合约的交易规则。这种编程方法可以比像BitVM这样的链下方法更本地化地在比特币上验证，并且能够改进主链上的应用（如拥堵控制）、链下应用（如状态通道）以及其他新的应用方向（如质押削减等）。
如果将Covenants的实现技术与其他升级结合起来，可能会进一步释放可编程性的潜力。例如，最近的64位算术提案可以进一步结合提议的OP_TLUV或其他基于交易输出的聪数量编程的Covenants。
然而，Covenants也可能导致意想不到的滥用或漏洞，因此社区对此也持谨慎态度。此外，Covenants的升级需要涉及共识规则的软分叉升级。鉴于taproot升级的情况，预计与Covenants相关的升级也需要时间来完成。
特别感谢
感谢Ajian、Fisher和Ben的审阅和建议！
参考
- https://utxos.org/
- https://bitcoincovenants.com/
- 与covenants相关的资源集合： https://gist.github.com/RobinLinus/c96fb7c81430ec6dc92f048687bd3068
- https://anyprevout.xyz/
- BIP 345：OP_VAULT提案： https://www.btcstudy.org/2023/04/13/bitcoin-improvement-proposals-345-op-vault-commit-0b0674c546/
- https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf
- https://maltemoeser.de/paper/covenants.pdf
- https://bitcoinops.org/en/topics/op_cat/
- OP_CAT： https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN-2024-0001.md
- CAT 和 Schnorr 技巧： https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
此材料仅供一般信息之用，不构成任何形式的投资建议、招揽或要约，也不应被解释为任何形式的投资建议或招揽，HashKey Capital对使用或依赖任何此类信息不承担任何责任。
关注HashKey Capital的最新动态
推特 - https://twitter.com/HashKey_Capital
领英 — https://www.linkedin.com/company/hashkeycapital/
声明：
1.本文转载自[medium]，版权归原作者所有[Jeffrey Hu和 Harper Li]，如对转载有异议，请联系Gate Learn团队，团队将尽快按照相关流程处理。
2、免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3.文章的其他语言版本由Gate Learn团队翻译，文中未提及Gate.io，翻译的文章不得转载、转发或抄袭。
相关文章
BTC Staking赛道Map梳理