比特币的下一个重大升级：OP CAT和OP CTV的综合评估

比特币的下一个重大升级？ OP_CAT 和 OP_CTV 的评估

推进比特币交易的可编程性

执行摘要

• 比特币对协议升级的保守态度使得共识变更很少见，但正如之前的 SegWit 和 Taproot 升级所展示的那样，开发者仍然愿意优化其编程语言和网络参数。

• 比特币的编程语言 Bitcoin Script，限制了交易携带全局状态和自省能力，这限制了表达性。

• OP_CAT (BIP 347) 和 OP_CTV (BIP 119) 这两个主要提案旨在通过启用交易输出的支出条件来增强比特币的交易可编程性，这可能会显着增强 Bitcoin Script 并使其更具表现力。

• OP_CAT 和 OP_CTV 最有希望的用例包括比特币 L1 和比特币 L2 之间的无需信任的桥梁、高级自托管金库解决方案以及对闪电网络的改进。

• 实施软分叉升级的治理过程涉及多个比特币利益相关者。在协议构思和技术审查的早期阶段，媒体影响者和核心开发者目前拥有最大的影响力。

• Galaxy Research 预测，比特币核心开发者将在 2025 年就添加 OP_CAT 或 OP_CTV 达成共识，但由于漫长的激活过程，实际实施可能需要 1-2 年。

介绍

对比特币协议的更改需要包括但不限于协议开发者、完整节点、最终用户和矿工在内的一系列利益相关者之间的对话和协作。就协议升级达成共识是费力且通常具有争议的。例如，2015-2017 年的“区块大小战争”将比特币社区分为两部分：一方是想要改变协议的基本属性（区块大小）的利益相关者，另一方是不想改变的利益相关者。这场持续多年的辩论导致了永久性的链分裂，并创建了一种名为 Bitcoin Cash 的替代加密货币，它是比特币的一个分叉。

鉴于在协议更改上达成共识的难度，对比特币的重大升级很少见。比特币协议开发者长期以来一直拒绝有争议的升级，并花费数年时间来实施确实得到更广泛比特币社区支持的升级。这突出了开发者致力于保持对比特币开发的保守态度，这种态度可以提高可预测性、网络忠诚度和向后兼容性。

虽然对比特币共识的改变很少见，但比特币开发者已经表现出优化比特币脚本和网络参数的意愿。来自区块大小战争的 SegWit 升级实际上增加了区块大小限制，从而允许区块中包含更多交易。SegWit 还通过改变交易数据的计量方法（从字节到虚拟字节（vbytes））来优化交易数据的格式。转向 vbytes 以及将签名数据移动到见证字段，使得一个比特币区块可以包含多达 4m 个交易数据的权重单位（约 4MB）。上一次比特币软分叉是 2021 年的 Taproot 升级，它引入了一种名为 Tapscript 的更新的脚本语言。这个新版本的 Bitcoin Script 包含新的签名方案（Schnorr 签名），该签名方案改进了密钥聚合，从而可以将多个公钥和签名合并为一个签名密钥。使用 Schnorr 签名进行密钥聚合减少了需要多个签名的交易的数据使用量，同时提高了闪电网络（比特币最大的 P2P 支付层，构建在比特币基础层之上）上交易的隐私。SegWit 和 Taproot 的这一高级概述表明，虽然比特币开发者不愿对比特币进行共识更改，但这并不意味着比特币的技术特性不会发生变化。

继 SegWit 和 Taproot 之后，比特币开发者现在正在探索改进比特币的交易可编程性，以便向交易添加额外的智能合约逻辑。比特币智能合约涉及使用支出条件，即限制和控制未花费交易输出 (UTXO) 未来支出方式的能力，其中更详细和限制性的支出约束被称为“covenants”。本报告将首先回顾 Bitcoin Script 以及它如何与比特币的 UTXO 会计模型一起运行。在回顾之后，我们将分析 2 个待处理的 opcode，OP_CTV 和 OP_CAT，以突出这些 opcode 如何潜在地改进 Bitcoin Script 以包含强大的功能，从而实现高效的交易可编程性。最后，本报告强调了交易可编程性对于桥和托管等比特币基础设施的重要性，最后展望了 OP_CAT 和 OP_CTV 的共识可能性以及将这些 opcode 实施到下一个软分叉升级中的路径。

Bitcoin Script 和 UTXO 模型

比特币使用一种本地脚本语言来构建交易，该语言被称为“Bitcoin Script”。一个脚本包含一组指令，这些指令定义了交易的接收者如何花费正在发送的比特币，这也称为“支出条件”。Bitcoin Script 由 186 个 opcode 组成，opcode 是一系列用作命令函数的脚本词。这些 opcode 用于创建关于比特币资产如何在网络上支出和转移的官方规则。例如，Pay-to-PubKey Hash 交易包括 4 个 opcode，这些 opcode 对比特币交易强制执行支出条件，其中比特币会支出到一个哈希公钥，并且只能使用与支出者关联的正确公钥和私钥来支出。

Bitcoin Script 专为比特币的未花费交易输出 (UTXO 模型) 而设计，该模型使用输入和输出。每个比特币交易至少包含 1 个输入和 1 个输出，尽管大多数简单交易至少包含 1 个输入和 2 个输出（其中一部分 BTC 在输入端为交易提供资金，其中 1 部分发送给接收者，剩余部分在输出端发送回给支出者）。UTXO 是尚未花费并可在未来交易中发送的比特币片段。UTXO 一旦用作交易的输入，就不再是输出。因此，当用户花费比特币时，UTXO 会不断地被创建和销毁。以下是 UTXO 模型如何工作的一个简化示例：

1. 如果 Alice 的钱包中有一个价值 1 BTC 的 UTXO，并且她向 Bob 发送 0.5 BTC，则 Alice 的输入将为 1 BTC。

2. 她的输出将为 0.49 BTC（返回给 Alice）和 0.5 BTC（发送给 Bob）。0.01 BTC 的差额表示为交易费用支付的 BTC（此交易费用会根据网络拥塞情况而有所不同）。

3. 在此交易结束时，Alice 将拥有一个新的 UTXO 集，表示她剩余的 0.49 BTC。

在步骤 1 中，Alice 正在使用她价值 1 BTC 的 UTXO 作为交易的第一个输入，从而销毁了该 UTXO。在步骤 2 中，Alice 创建了 2 个新的 UTXO，价值分别为 0.5 和 0.49 BTC，其中一个作为她的零钱返还给她，另一个支付给 Bob。在步骤 3 中，Alice 现在拥有一个新的 UTXO，价值为 0.49 BTC。应该注意的是，如果 Alice 需要向 Bob 支付 0.5 BTC，Alice 也可以在步骤 1 中使用总计为 0.5 BTC 的多个 UTXO；如果任何输入 UTXO 都未完全支付给接收者，Alice 现在可能会收到 2 个新的 UTXO 而不是 1 个。UTXO 模型是比特币网络的一个关键特性，并且在交易的处理和验证中起着至关重要的作用。

上面的 UTXO 示例完全是使用 Bitcoin Script 构建的。每个 UTXO 都包含一个锁定脚本，其中包含 UTXO 支出的条件集。当用户通过提供与相应公钥关联的正确私钥签名来证明对输入（正在支出的 UTXO）的所有权时，UTXO 的锁定脚本将被解锁。此信息被称为“scriptsig”，当输入中包含正确的 scriptsig 时，则满足支出条件，并且可以支出比特币。回到 Alice 和 Bob 的 UTXO 示例，在步骤 1 中，Alice 必须在输入中提供她的私钥签名才能支出她的 UTXO。随后，Bob 在支出他新收到的 0.5 BTC 之前，也必须提供相同的信息。

比特币的脚本语言可以包含更复杂的支出条件，例如要求多个签名或在特定区块高度解锁比特币。但是，Bitcoin Script 并非通用脚本，并且缺乏与其他编程语言（例如以太坊的本地编程语言 Solidity）相同的表达能力。因此，使用 Bitcoin Script 为桥梁和托管解决方案编程智能合约逻辑非常具有挑战性。

截至 2025 年 Bitcoin Script 的障碍

虽然 Bitcoin Script 在过去 16 年中证明了其对用户的有用性以及抵御双重支出攻击的弹性，但该脚本语言缺乏通用功能，例如表达性和存储全局状态。Bitcoin Script 不具有表达性，因为它是一种基于堆栈的编程语言，无法使用乘法和大数的算术运算。Bitcoin Script 只能对 32 位大的值执行非平凡的计算。因此，Bitcoin Script 将大于 32 位的堆栈元素彼此隔离。这种 32 位限制隔离了使用加密功能、乘法和除法的计算密集型命令，这些命令需要脚本大小大于具有当前 opcode 集的 32 位。虽然可以使用多个 opcode 模拟算术和乘法，但这需要许多堆栈元素，但不幸的是，Bitcoin Script 的堆栈大小限制为 1000 个元素。因此，在交易输出上创建超出当今已存在操作的复杂支出条件具有挑战性。

Bitcoin Script 最大的限制是该语言无法读取/写入和存储交易数据，因为它只能读取支出者给出的输入。如果没有一种编程语言能够存储全局状态，则该脚本无法独立验证应用程序或桥梁上的帐户余额。Bitcoin Script 逻辑无法访问全局状态，因为任何状态数据都必须适合单个交易。因此，几乎不可能开发通用功能或在Layer2网络和比特币的基础层之间构建无需信任的桥梁。

自 2020 年以来，一直在开展旨在解决 Bitcoin Script 局限性的举措。多年来，开发者之间似乎出现了一种共识，即唯一能使 Bitcoin Script 更具表达能力的方法是执行一个软分叉升级，该升级实施新的 opcode 以启用 covenants。虽然比特币的一个派别认为这些升级对比特币网络构成风险，但另一个派别认为比特币需要更多的可编程性功能来扩展比特币的用例。虽然在哪个 opcode 最适合比特币以提高交易可编程性方面尚未取得任何实际进展，但 covenants 的倡导者现在大多同意 OP_CTV 和 OP_CAT 是改进比特币交易可编程性的主要比特币改进提案 (BIP)。我们知道，有不止 2 个解决方案可以在比特币上实施 covenants，但是，本报告将仅涵盖 OP_CTV 和 OP_CAT，这是两个最突出的提案。

BIP 119 (OP_CTV)

比特币改进提案 119 (BIP 119)，也称为 CHECK-TEMPLATE-VERIFY (CTV)，是比特币核心开发者 Jeremy Rubin 于 2020 年 1 月创建的提案。该提案引入了一个新的 opcode，OP_CTV，该 opcode 可以在比特币交易的输出上实施通用支出条件，也称为 covenants。作为背景，“CHECK_TEMPLATE_VERIFY”中的模板部分是指编写 Bitcoin Script 时必须遵循的交易格式。CHECK-TEMPLATE-VERIFY 是一种新函数，它使交易输出的锁定脚本能够提交到锁定脚本中存储的支出条件（作为哈希），也称为 commitment 哈希。因此，只有满足 commitment 哈希中详述的条件，才能解锁交易输出。一旦在链上广播，与交易关联的 commitment 哈希是不可变的。OP_CTV 的好处是交易的发送者能够对接收者施加支出条件，这是对比特币脚本当前规则的重大更改，当前规则只能对发送者构建支出条件。

covenants 主要有两种类型。通用 covenants 可以复制并应用于多个 UTXO。在 UTXO 被支出之后，covenant 不会过期。另一方面，预先计算的 covenants 也可以复制，但只能复制有限的、预先定义的次数。预先计算的 covenant 的逻辑必须由发送者提前指定，并且与通用 covenant 的不同之处在于，支出条件不能无限期地复制。通用 covenants 也称为递归 covenants，可能会对 UTXO 的同质性构成风险，这就是 BIP 119 的倡导者通常只关注使用 OP_CTV 的用例的原因，也是 BIP 119 不允许通用 covenants 的原因。例如，启用通用 covenants 后，托管人或比特币交易所可能有能力处理带有支出条件的提款，这些支出条件将无限期地继续存在，从而永远使这些币受到政府或其他机构的审查的可能性。

使用 BIP 119 设置的 Covenants

以金库方案为例，以下是 OP_CTV 的功能如何启用 covenants：

Alice 想在 10 年后将她价值 1 BTC 的 UTXO 中的 0.8 BTC 支出给 Bob 和 Charlie（每人 0.4 BTC）。Alice 还希望她的约 ~0.2 BTC 的零钱被发送到一个新的金库，该金库将 BTC 锁定额外 10 年。

步骤 1： Alice 将她价值 1 BTC 的 UTXO 支出给 Bob 和 Charlie，并在锁定脚本中详细说明 Bob 和 Charlie 可以在 525k 个区块（大约 10 年）内支出 BTC。Alice 还包括详细说明她的约 ~0.2 BTC 的零钱输出将被发送到她拥有的金库地址的指令，该金库地址将锁定她的 UTXO 525k 个区块（大约 10 年）。

步骤 2： Bob 和 Charlie 在 525k 个区块之后支出他们各自价值 0.4 BTC 的 UTXO。Alice 设置的锁定脚本将根据当前区块高度检查 commitment 哈希，如果满足条件，则 Bob 和 Charlie 可以支出他们新的 UTXO。

在步骤 2 中，在 Bob 和 Charlie 支出他们的 UTXO 后[GP1]，Bitcoin Script 的一部分（也称为“锁定脚本”）检查支出条件的履行情况，将确保在释放 BTC 之前满足所有条件。此操作通常被称为使用正确的 scriptsig“解锁”比特币输出。如果未满足条件，则锁定脚本将不会启动 BTC 的转移。

步骤 3： 在 Charlie 和 Bob 满足锁定脚本中的 commitment 哈希后，以 Alice 的零钱 (~0.2 BTC) 返回给 Alice 的 UTXO 将用作具有指定金库 scriptpubkey 的地址的输入。金库 scriptpubkey 包括一个哈希，该哈希允许 Alice 在 525k 个区块后解锁金库，以支出她的 ~0.2 BTC 的 UTXO。使用金库方案的好处是 Alice 可以在哈希中添加安全措施，例如秘密恢复地址，以防有人窃取她的私钥并试图在 525k 个区块时间锁定之前解锁 UTXO 时，她的 UTXO 将被支出到该地址。

如果没有 covenants，在前面的示例中，Alice 将需要创建一个预先签名的交易，以强制执行对她已支出给 Bob 和 Charlie 的 BTC 的未来支出条件。预先签名的交易可以是单个或多个交易的图，这些交易已由发送者的私钥提前签名，但实际上并未广播到网络以进行确认和执行。预先签名的交易不可扩展，因为它们要求用户存储多个交易的数据，直到它们在链上执行为止。此外，预先签名的交易要求所有签名方在可以支出资金时进行交互。但是，通过 OP_CTV 使用 commitment 哈希进行 covenants 减轻了用户存储预先签名交易数据并依赖与交易关联的所有各方之间交互的需求。

从广义上讲，此功能可用于创建一系列复杂、高度安全且有弹性的托管和安全设计，从而有助于改进自托管或托管设置，创建创新的新仲裁或业务帐户设置，或创建具有更高透明度和可靠性的更自主的执行方案。

BIP 347 (OP_CAT)

BIP 347 是 Ethan Heilman 和 Armin Sabouri 于 2023 年 10 月编写的另一项比特币改进提案，该提案也可以在比特币交易的输出上启用预先计算的支出条件。该提案建议将 OP_CAT opcode 添加到比特币的脚本语言中，该函数允许比特币开发者将两个数据点连接在一起并堆叠中，并将这些值放置在堆叠的顶部。作为背景，连接是将两个或多个代码字符串组合成一个更大的字节或数据字符串的过程。Bitcoin Script 是一种基于堆叠的编程语言，按顺序计算每个代码字符串。对于由 5 行代码组成的堆叠，Bitcoin Script 将首先计算第 1 行，最后计算第 5 行。不幸的是，比特币的脚本语言不包含允许开发者合并整个堆叠中多个代码字符串的 opcode。目前，Bitcoin Script 缺乏算术和乘法能力，这会抑制压缩 Bitcoin Script 的能力，从而限制了大型脚本（大于 32 位）和小型脚本（小于 32 位）在单个堆叠中的交互。如果没有通过连接压缩脚本并允许大型脚本与小型脚本通信的能力，则交易输出上的复杂支出条件是不可行的。

至关重要的是，Bitcoin Script 在堆叠顶部的连接元素可以模拟算术和乘法功能，从而实现复杂的脚本，而无需编写容易出现错误的冗长数据密集型脚本。此外，OP_CAT 的连接功能允许开发者在使用 Tapscript（一种用于启用新交易类型的本地脚本语言，作为 2021 年 11 月激活的 Taproot 升级的一部分）的 Merkle 树和其他哈希数据结构生成支出条件。

值得注意的是，Satoshi Nakamoto 禁用了 OP_CAT 以及其他使 Bitcoin Script 能够直接在脚本中执行复杂数学运算的 opcode。Satoshi 自己删除了 OP_CAT，因为在当时比特币的脚本限制为 2000 字节时，该 opcode 启用了数据密集型脚本的构建，并添加了 OP_DUP。如此大的脚本大小可能会给比特币节点的计算资源带来负担并使它们过载。但是，Taproot 升级在 2021 年引入了 Taproot 脚本的大小限制（520 字节），因此 OP_CAT 不再会给节点运营商带来过多的计算开销。

使用 BIP 347 (OP_CAT) 的 Covenants

2021 年的 Taproot 升级在比特币的脚本语言中实施了 Schnorr 签名。Schnorr 签名支持公钥和私钥聚合，因此多个参与者可以使用单个签名集体签名交易。将 Schnorr 签名中包含的验证 opcode 与 OP_CAT 结合使用可以创建一个非递归的 covenant，该 covenant 产生一个交易哈希。使用 OP_CAT，用户可以将交易的某些部分（例如发送地址或正在发送的值）约束为解锁脚本的要求，并将交易哈希用作解锁它的密钥。

以金库方案为例，以下是 OP_CAT 的功能如何在高级别启用 covenants。本报告不涉及此示例的高度技术方面。

Alice 想要创建一个在 100 个区块后解锁她的 UTXO 的金库：

步骤 1： Alice 将她的 UTXO 支出到一个金库地址，其中包含金库解锁脚本的支出条件详细信息，包括区块高度添加到见证字段中。

步骤 2： 在 Alice 的交易期间，OP_CAT 连接见证字段中的金库解锁指令，并将它们哈希两次以获得 sighash/txhash。

步骤 3： 在 100 个区块确认后，Alice 启动花费她的金库比特币的过程，方法是广播一笔金库 UTXO 的消费交易。为了验证 Alice 是否满足了所有支出条件，她的钱包在后端执行 CheckSig opcode。此操作执行两个关键验证：它验证初始设置交易（步骤 1）中的交易哈希，并将其与当前的消费交易（步骤 3）进行比较。CheckSig 函数重建设置交易的组成部分，并验证当前交易的公钥签名，以确保满足所有金库消费条件。

步骤 4： 在 Alice 交易的公钥通过 CheckSig（它重建存储在见证字段中的消费条件）验证后，Alice 可以自由地花费她的 UXTO。

上面的示例演示了 OP_CAT 本身无法在交易上实施消费条件，而是 OP_CAT 加上 Bitcoin Script 中的其他 opcode 可以简化脚本编写，从而启用 covenants。OP_CAT 的唯一功能是连接堆叠顶部的 2 个元素。

尽管 OP_CAT 可以用于使用 CheckSig 创建 covenants，但仅添加 OP_CAT 并不会将类似 Solidity 的功能带到 Bitcoin Script。仅添加 OP_CTV 也存在此限制。即使使用 OP_CAT，比特币交易也只能执行最小的自省，这意味着交易无法完全访问先前交易中的元素或状态。因此，OP_CAT 只能支持 Taproot 交易输出的细粒度 covenants。OP_CAT 无法修复 Taproot 输出的叶子或验证使用的内部密钥。Taproot 叶子是承诺到 Taproot 输出的各个支付条件或脚本。将它们视为花费比特币的不同“路径”或方式 - 每个叶子代表一种可能的花费资金的方式。比特币 Taproot 交易中的内部密钥是用于最有效消费路径的主要公钥。当使用内部密钥消费 UTXO 时，你只需要在链上提供一个签名，无需显示任何脚本或 Merkle 路径。

应该注意的是，这些限制可以通过其他 opcode 提案来解决，例如 OP_TWEAK_VERIFY 和 OP_INTERNALKEY。总的来说，OP_CAT 可以被视为生成交易输出上复杂支付条件的主要构建块，但是，包括 CheckSig 在内的其他构建块对于推进比特币交易可编程性的发展至关重要。

Covenants 可以为比特币带来的主要功能

具有单方面退出的无需信任的桥梁

Starkware 是以太坊上 Starknet zk-rollup 的创建者，他们发布了一份报告，该报告强调了 OP_CAT 如何能够创建 STARK 验证器和 Merkle 验证器，以支持无需信任的比特币桥梁。无需信任的桥梁是通过递归 covenant 系统构建的，该系统通过记录在 Merkle 树中的一系列交易来维护桥梁状态。此机制的核心是将桥梁的持久状态存储在无法消费的 OP_RETURN 输出中，其中包含 Merkle 树的根哈希，该 Merkle 树表示帐户余额。OP_CAT covenant 要求每个新的存款或提款交易都包含反映当前桥梁状态的有效状态转换。用户通过专用的存款和提款 covenant 与桥梁交互，这些 covenant 使用 Merkle 树将多个交易聚合到批次中，以实现高效验证。然后，此 Merkle 树的根被合并到主桥梁 covenant 中，该 covenant 验证和处理每个存款或提款。在提款期间，covenant 通过确保提款地址与叶子交易中第一个输入的地址匹配来验证所有权。此设计利用 Merkle 证明在 Bitcoin Script 中实现高效的状态更新，从而创建一个无需信任的系统，其中桥梁的状态和规则完全通过使用 OP_CAT 创建的链上 covenant 逻辑来强制执行，而无需第三方信任。至关重要的是，对于无需信任的比特币桥梁来验证侧系统的状态转换，Bitcoin Script 需要验证证明。OP_CAT 通过将哈希数据连接在一起在 Bitcoin Script 中构建 STARK 验证器的能力使 UTXO 锁定脚本能够验证侧系统的状态转换的 zk 证明。

Taproot Wizard 团队革新了一个新的无需信任的桥梁框架，该框架将 OP_CAT 与 BitVM 结合在一起。作为背景，BitVM 允许通过将任意计算拆分并在比特币上执行来获得图灵完备的表达能力。BitVM 将利用 Bitcoin Script 的任意计算的运行时拆分到比特币上的多个交易中。如果没有 covenants，锁定比特币的 BitVM 桥梁将需要预先签名的交易来设置桥梁。OP_CAT 从先前交易中携带数据的能力使 BitVM 桥梁能够锁定和解锁比特币，而无需预先签名的交易。OP_CAT 可以通过一种称为“堆叠上的 CAT”的技巧从先前交易中携带数据。此技巧涉及连接堆叠上的哈希数据以构建 Merkle 树根，OP_CAT 可以验证该 Merkle 树根。因此，CatVM 桥梁确保先前交易、存款和提款中的特定交易数据必须包含在下一个交易中，以保证在成功提款后 Merkle 根被结转。堆叠技巧上的 CAT 还确保在一个用户提取资金后，桥梁中锁定的剩余比特币可以被任何符合条件的用户提取。

高级金库存管

比特币金库是一种新的托管解决方案，其中包括安全功能（例如恢复路径），使用户可以在私钥泄露的情况下将比特币提取到秘密地址。正式名称为 OP_VAULT 的BIP 345 是一个正在申请的比特币改进提案，它利用 OP_CTV 来增强比特币托管的安全参数。应该注意的是，OP_CAT 也可以用于为比特币金库创建消费条件，而无需预先签署交易。比特币核心开发者 James O’Beirne 在 2023 年 1 月提出了 OP_VAULT，以缩小 OP_CTV 的使用范围。OP_VAULT 依赖于 OP_CTV 来创建金库比特币的消费条件，而无需存款人预先签署多个交易。Covenants 允许金库具有时间延迟，当任何人试图在原始时间锁之前花费金库比特币时，都会触发该时间延迟，通常这是攻击者试图窃取资金。

非含糊合同

非含糊合同于 2015 年推出，是指如果签名者双重花费，则会泄露签名密钥的比特币交易输出。在实践中，用户锁定原生比特币，这充当可削减的债券。此债券允许用户在基础层上执行 0 确认交易，这些交易随后在区块中挖掘。0 确认交易是指通过比特币的共识规则验证和保护的即时比特币交易。如果 0 确认交易的发送者在交易被挖掘之前花费了输入，则交易对方可以从泄露的签名密钥中削减他们的比特币债券。

闪电网络的改进

OP_CAT 可以启用通道工厂，从而允许用户打开闪电通道，而无需首先在比特币的基础层上广播通道打开交易。例如，如果 Alice 想要创建 2 个闪电通道（一个与 Bob，另一个与 Charlie），Alice 将广播一个与 Bob 和 Charlie 的通道打开交易（2 个 tx）。通道打开交易要求双方将比特币存入 2 对 2 多重签名地址。有了通道工厂，Bob 和 Charlie 就可以彼此打开一个单独的通道，而无需在比特币上广播一个新的通道打开交易。因此，原始通道打开交易中的所有参与者都可以彼此创建独立的通道。

OP_CTV 可以创建共享 UTXO，其中一个 UTXO 代表多个用户。具有 CTV 的共享 UTXO 可以使多个用户通过一个链上交易打开许多闪电通道。通常，每个闪电通道都需要一个链上交易。因此，如果许多用户打开闪电通道，这可能会导致交易池中充斥着待处理的交易并增加交易费用。虽然这现在不是问题，但通道打开需要扩展才能让闪电网络接纳数百万活跃用户。

与 OP_CAT 和 OP_CTV 相关的风险

所有比特币软分叉都包含技术风险，例如 bug 或新 opcode 的不可预见的使用案例。尽管前者很少见，但后者因铭文的创建而暴露出来。作为背景，铭文涉及在交易的见证字段中输入任意数据，该数据已用于在比特币上创建新的代币和 NFT 集合（有关铭文的更多信息，请阅读我们之前的两篇报告 报告）。SegWit 和 Taproot 升级共同使用户能够将图像和文本数据作为字符串数据输入到见证字段中。虽然创建数字艺术品和可替代代币并不是激活 SegWit 或 Taproot 的重点，但多年后精明的开发者想出了如何将这些升级用于其他原因。Galaxy Research 在我们的 Ordinals 报告中强调了这一观点，并指出通过 SegWit 和 Taproot 意外创建铭文可能对比特币未来的升级不利，因为社区对这些新用例的惊讶可能会让他们更不愿意支持新的软分叉。

尽管对比特币升级能力持悲观态度，但 OP_CAT 和 OP_CTV 已经过大量测试和研究。对 covenants 的最初批评是，政府可能会强迫应用程序强制执行支付条件，该条件仅允许一组批准的地址花费比特币。此批评无效，因为支付条件的条件由拥有资金的用户确定。用户可以创建将未来消费限制在特定地址的交易，但这些限制不能由第三方在外部强制执行，并且在锁定的资金被消费后，它们不能永久持续。因此，政府无法强制执行自托管金库应用程序或桥梁如何花费资金。虽然托管人和比特币交易所仍然可以限制用户如何花费资金，但他们无法在没有执行通用 covenants 的能力的情况下，将永久的支付条件添加到提取的资金中，而 OP_CTV 不允许这样做。

总的来说，OP_CAT 和 OP_CTV 是简单的 opcode，每个 opcode 都能很好地完成一项功能。OP_CAT 连接堆叠顶部的两个元素，OP_CTV 可以对锁定脚本中的消费条件进行哈希处理。这些 opcode 的一些用例（例如开发无需信任的桥梁）仍需要进一步研究和经过实战测试，因为桥梁可能极易受到 bug 和黑客攻击。

实施 Covenants 到下一个软分叉升级的路径

在比特币利益相关者之间确定对未来协议升级的共识是一个复杂的过程，该过程随着提案的整个生命周期而发展，也称为 BIP（比特币改进提案）过程。BCAP 关于比特币升级历史的报告详细说明了这些利益相关者的作用如下：

经济节点： 交易所、托管人、商家、支付提供商

投资者： 鲸鱼、MicroStrategy、ETF 提供商、Galaxy

媒体影响者： CoinDesk、Bitcoin Magazine、X 影响者、播客

矿工： Bitmain、MicroBT、Riot、Marathon、大型私人矿工

协议开发者： 比特币核心开发者

应用程序开发者： Layer2项目

在比特币改进提案 (BIP) 的整个生命周期中，不同的利益相关者会行使不同程度的影响力，并且他们在实施软分叉的共识建立过程中所产生的相对影响会发生变化。以下是每个利益相关者拥有的权力级别（排名 1-10）的详细可视化。截至 2024 年 3 月，OP_CAT 和 OP_CTV 仍处于协议构思阶段。在此阶段，媒体人士的影响力最大，因为他们的权力可以左右公众舆论并创建叙事。例如，Taproot Wizards 是一个由知名比特币影响者组成的团队，他们正在利用其庞大的社交媒体关注者来教育比特币社区 OP_CAT 的好处。Taproot Wizards 团队一直在制作关于 OP_CAT 的教育内容和研究，以推动比特币脚本需要新的 opcode 来增强交易可编程性的日益增长的叙事。因此，Taproot Wizards 培养了一支 OP_CAT 支持者大军，他们正在推动核心开发者审查 OP_CAT BIP 草案。

在协议构思阶段，比特币核心开发者的影响力排在第二位，因为 BIP 编辑负责审查待处理 BIP 的草案，但最重要的是，他们是唯一可以将 BIP 合并到 Bitcoin Core GitHub 存储库中的实体[1] [GP2]。如果没有比特币核心开发者的支持，BIP 将不可避免地被搁置，并最终被拒绝。比特币核心开发者还负责维护比特币代码库，并确保它不包含任何 bug。在比特币核心开发者之间达成共识是一个困难的过程，因为核心开发者之间的意识形态观点可能不同，并且每个核心开发者在决策过程中的影响力也因他们的贡献和背景而异。

####### 来源：https://github.com/bitcoin-cap/bcap/blob/main/README.md

OP_CAT 和 OP_CTV BIP 目前所处的阶段是媒体影响者、用户和应用程序开发者正在利用他们的影响力来说服比特币核心开发者，这些共识变更将改善比特币的交易可编程性。共识历程的下一阶段将需要来自技术影响者、应用程序开发者和核心开发者的具体研究，这些研究详细说明了 OP_CAT 和 OP_CTV 的所有潜在风险。如果没有具体的研究以及与核心开发者的公开来回对话，更广泛的核心开发者社区将不会对 OP_CAT 和 OP_CTV 形成集体观点。目前，有一个公共电子表格概述了核心开发者对 OP_CTV 和 OP_CAT 的看法。

一旦核心开发者之间达成共识，OP_CAT 和 OP_CTV 将需要被分配一个主要维护者，以促成在将 BIP 实施到 Bitcoin Core 存储库之前的最后几个步骤。在 OP_CAT 和 OP_CTV 的 BIP 合并到 Bitcoin Core 存储库中之后，必须确定一种激活方法。一旦选择了激活方法，就将开始信号期，在此期间矿工、投资者和经济节点将拥有最大的影响力。截至 2024 年 3 月，矿工、像 Microstrategy 这样的大型投资者和像 Coinbase 这样的经济节点对 OP_CAT 和 OP_CTV 没有任何公开观点。在实施 BIP 之前，需要对这些利益相关者进行有关 OP_CAT 和 OP_CTV 的风险和收益方面的进一步教育。

BIP 激活的方法

如果比特币核心开发者同意将 OP_CAT 或 OP_CTV 包含到下一个软分叉升级中，则社区需要就 BIP 的激活方法达成一致。激活方法允许矿工表示他们已准备好进行升级。

从广义上讲，有两种方法可以在比特币上执行代码更改。首先，可以通过软分叉执行代码更改。软分叉是向后兼容的升级，即使比特币节点运营商不升级其客户端软件，也可以在比特币网络上安全地运行。软分叉向后兼容的另一个好处是，任何不同意比特币核心（主要的比特币客户端）方向的人都可以选择运行旧版本的客户端软件，该软件不包括新 BIP 的激活，但仍然可以连接到规范的比特币区块链。软分叉通过创建比现有规则集更受限制的新条件来添加功能，因此适合现有规则。

当软分叉由用户而不是矿工激活时，它被称为用户激活的软分叉（UASF）。最值得注意的 UASF 示例几乎发生在 2017 年 8 月 1 日的“区块大小战争”期间，目的是帮助加快 SegWit 升级的采用。在区块大小战争期间，比特币用户升级了他们的节点以支持 SegWit 升级，随后威胁要拒绝来自未升级节点的区块。通过这样做，鼓励那些尚未升级其比特币客户端软件的矿工采用 Segwit，以使其区块得到更广泛的传播并增加获得区块奖励的机会。虽然在区块大小战争期间从未发生过 UASF，但潜在 UASF 的威胁影响了矿工采用 SegWit。 第二种实现代码变更的方法是通过硬分叉，这是一种向后不兼容的升级，它永久地分裂了升级节点和非升级节点之间的共识。由于社区对协议代码固化和向后兼容性的重视，比特币核心开发者从未实施过比特币的硬分叉。如果少数用户执行硬分叉升级，例如更改区块大小，则比特币上可能会发生链分裂。这就是 Bitcoin Cash 在 2017 年创建的方式，当时比特币社区中不同意 Segwit 升级，而是希望通过激活向后不兼容的代码变更来简单地增加区块大小的子集，从比特币协议中分叉出来。

除了硬分叉和软分叉激活之间的差异之外，在分叉发生之前，还有不同的方法来评估社区对升级的情绪。以下是比特币社区提出的一些过程类型 BIP 的概述，旨在更好地支持软分叉升级的激活：

BIP 9：BIP 9 提供了一个框架，供矿工通过修改比特币区块头中的版本位字段来表示他们对软分叉升级的支持。一旦信令周期结束，比特币社区可以评估矿工表示支持升级的百分比，并根据矿工的哈希率对投票进行加权。如果超过某个支持阈值，则升级可以继续在“flag day”上激活，这只是升级激活的指定区块高度。

BIP 8：Luke Dashjr 是一位自 2011 年以来一直在开发比特币的长期比特币核心开发者，他于 2017 年 2 月提出了 BIP 8 作为 BIP 9 的继任者。BIP 8 建议使用区块高度而不是哈希率来确定信令周期的持续时间，以批准提案。BIP 8 还引入了一个新的链上激活软分叉参数，称为“LOT”。如果参数设置为“TRUE”，则需要在最后一个周期发出信号，以确保软分叉被超时高度锁定。从这里开始，升级会在预定义的 flag day 由节点激活，而不管矿工是否发出其他信号。BIP 8 试图减少矿工对延迟社区想要的提案激活的任何干扰，并迫使矿工考虑因未从升级节点接收区块而损失收入的后果，如果升级的 LOT 参数设置为 TRUE。

Speedy Trial：Bitcoin 核心开发者 AJ Townes 和 Andrew Chow 在 2021 年 4 月推出了一个名为“Speedy Trial”的 BIP 8 版本。Speedy Trial 试图加快矿工表示准备好激活的时间表。这种方法一旦在指定期间内开采的大多数区块发出准备就绪的信号，就会激活一个提案。Speedy Trial 的功能类似于 BIP 9 激活部署，但激活窗口较短。最近，Taproot 升级通过 Speedy Trial 在比特币上激活。该试验要求在两周内开采的 90% 的区块发出准备就绪的信号，然后 Taproot 才能在网络上激活。该试验于 2021 年 6 月 12 日结束。由于达到了矿工 90% 的支持阈值，网络随后进入了五个月的等待期，以便让矿工和节点有时间升级其软件。Taproot 随后于 2021 年 11 月 15 日正式在比特币上激活。

Modern Soft Fork Activation：这是一种结合了 BIP 9 和 BIP 8 不同属性的升级激活方法。它由 Bitcoin Core 最多产的贡献者之一 Matt Corallo 于 2020 年 1 月提出。这种方法包括三个步骤。第一步是 BIP 9 中概述的矿工激活的软分叉。如果矿工未能激活升级，则 Corallo 概述的现代软分叉激活过程默认为第 2 步，这是一个为期六个月的时间，开发者和更广泛的 Bitcoin 社区重新考虑代码更改。六个月后，如果开发者和用户想要继续升级，他们可以启动第 3 步，这基本上是 BIP 8，其中 LOT 参数设置为 TRUE。

结论

尽管 OP_CAT (BIP 347) 和 OP_CTV (BIP 119) 获得了知名比特币开发者的大量支持，但这些提案在实施之前必须经过漫长的尽职调查过程。这是因为 OP_CAT 和 OP_CTV 需要更改比特币的共识层，并且对此类更改的 BIP 治理过程非常广泛。虽然 BIP 119 和 BIP 347 激活的时间表尚不清楚且仍然不可预测，但漫长的审查期可能会通过让社区有充足的时间来了解 OP_CTV 和 OP_CAT 的好处和影响来使该提案受益。此外，BIP 贡献者将有更多时间来压力测试 OP_CTV 和 OP_CAT 以及它可能对未来 Bitcoin Script 错误产生的影响。

虽然 OP_CAT 和 OP_CTV 的全部潜力仍在探索中，但它们最直接的影响在于为 Bitcoin L2 实现无需信任的桥接和高级安全比特币金库。无需信任的桥接对于 EVM 兼容的 Bitcoin L2 的重要性怎么强调都不为过，尤其是在 Bitcoin DeFi 不断发展的情况下。这些无需信任的解决方案代表了对当前替代方案（如 WBTC 和 cbBTC）的重大改进，后者依赖于受信任的中介机构并损害了区块链技术的无需许可性质。虽然自托管的比特币金库可能为托管解决方案提供最实际的价值，但无需信任的 L2 桥接的潜力可以作为增强的交易可编程性可以为比特币带来的更广泛可能性的引人注目的展示。

开发者社区在 2024 年全年推进这些提案的进展已经建立了巨大的势头，这种势头可能会延续到 2025 年。随着 Bitcoin 交易活动趋势下降，费用率达到 1 sat/VB，现在的重点是恢复 Bitcoin 上的交易活动。虽然我们的 Galaxy Research 2025 预测 报告表明 Bitcoin Core 开发者将就 OP_CAT 或 OP_CTV 达成共识，但最终的实施和激活过程可能会再延长 1-2 年。尽管有这个时间表，但最终采用这些提案将代表 Bitcoin Script 发展中的一个关键里程碑，为未来更复杂和安全的 Bitcoin 应用程序奠定基础。

• 原文链接： galaxy.com/insights/rese...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～