比特币的下一个重大升级是什么？对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 年。

1、引言

比特币协议的变更需要多个利益相关方的讨论与协作，包括但不限于协议开发者、全节点、终端用户和矿工。实现协议升级的共识过程复杂且充满争议。例如，2015-2017 年的“区块大小之争” 让比特币社区分 裂，一方希望调整区块大小，另一方则反对。多年的争论最终导致了区块链的永久性分叉，并诞生了一个新的加密货币——比特币现金（bitcoin cash），它是比特币的一个分叉版本。

鉴于达成协议变更共识的难度，比特币的重大升级较为罕见。比特币协议开发者拒绝有争议的升级，并且时间实施那些得到更广泛比特币社区支持的升级需要花费数年，这已有很长的历史。这凸显了开发者对比特币开发采取保守态度的承诺，以促进可预测性、网络保真度和向后兼容性。

尽管比特币的共识变更较为罕见，但比特币开发者已表现出对比特币脚本和网络参数优化的开放态度。区块大小之争中诞生的隔离见证（segwit）升级实际上增加了区块大小限制，允许区块中包含更多交易。segwit还通过将交易数据的计量单位从字节（bytes）改为虚拟字节（vbytes），优化了交易数据的格式。这一转变，加上将签名数据移至见证字段，使得一个比特币区块可以包含多达4m权重单位的交易数据（约4mb）。比特币的最后一个软分叉是2021年的taproot升级，它引入了一种名为tapscript的更新版脚本语言。这个新版本的比特币脚本包含了新的签名方案（schnorr签名），改进了密钥聚合，将多个公钥和签名合并为一个签名密钥。schnorr签名的密钥聚合减少了需要多个签名的交易数据量，同时提高了闪电网络（比特币最大的p2p支付层，建立在比特币基础层之上）上交易的隐私性。对segwit和taproot的简要概述表明，尽管比特币开发者对比特币的共识变更持谨慎态度，但这并不意味着比特币的技术特性不会发生变化。

在segwit和taproot之后，比特币开发者现在正在探索提高比特币的交易可编程性，以在交易中添加额外的智能合约逻辑。比特币智能合约涉及支出条件的使用，即限制和控制未花费交易输出（utxo）未来如何被花费的能力，更复杂和严格的支出约束被称为“covenants”（“限制条款”或“契约”）。本文将首先回顾比特币脚本及其如何与比特币的utxo会计模型配合使用。随后，我们将分析两个待定的操作码op_ctv和op_cat，以强调这些操作码如何有可能改进比特币脚本，使其包含强大的功能，从而实现高效的交易可编程性。最后，本文强调了交易可编程性对比特币基础设施（如桥接和托管）的重要性，并展望了op_cat和op_ctv达成共识的可能性，以及将这些操作码实施到下一个软分叉升级中的路径。

2、比特币脚本与utxo模型

比特币使用一种原生脚本语言来构建交易，称为“比特币脚本”。脚本由一组指令组成，定义了交易的接收者如何花费正在发送的比特币，也称为“支出条件”。比特币脚本由186个操作码组成，这些操作码作为命令函数运行。这些操作码用于创建关于比特币资产如何在网络上花费和转移的官方规则。例如，pay-to-pubkey hash交易包含4个操作码，这些操作码对比特币交易强制执行支出条件，其中比特币被花费到一个哈希公钥，并且只能使用与花费者相关的正确公钥和私钥进行花费。

比特币脚本专为比特币的未花费交易输出（utxo模型）设计，该模型使用输入和输出。每个比特币交易至少包括1个输入和1个输出，尽管大多数简单交易至少包括1个输入和2个输出（输入端的一部分btc用于资助交易，一部分发送给接收者，剩余部分在输出端返回给花费者）。utxo是尚未花费的比特币部分，可以在未来的交易中发送。一旦utxo被用作交易的输入，它们就不再是输出。因此，当用户花费比特币时，utxo会不断被创建和销毁。以下是一个简化的utxo模型示例：

*如果alice的钱包中有一个价值1 btc的utxo，并且她向bob发送了0.5 btc，alice的输入将是1 btc。*她的输出将是0.49 btc（返回给alice）和0.5 btc（发送给bob）。0.01 btc的差额代表支付给交易费用的btc（此交易费用将根据网络拥堵情况而变化）。*在此交易结束时，alice将有一个新的utxo集，代表她剩余的0.49 btc。在第1步中，alice使用她价值1 btc的utxo作为交易的第一个输入，销毁了utxo。在第2步中，alice创建了两个新的utxo，价值0.5 btc和0.49 btc，一个作为她的找零返回给她，另一个支付给bob。在第3步中，alice现在有一个新的utxo，价值0.49 btc。需要注意的是，如果alice需要支付bob 0.5 btc，alice也可以在第1步中使用多个utxo，总和为0.5 btc；如果输入utxo均没有完全之出给接收者，alice现在可能会收到2个新的utxo，而不是1个。utxo模型是比特币网络的一个关键特性，在交易处理和验证中起着至关重要的作用。

上面的utxo示例完全使用比特币脚本构建。每个utxo都包含一个锁定脚本，其中包括utxo被花费的一组条件。当用户通过提供与相应公钥关联的正确私钥签名来证明输入（被花费的utxo）的所有权时，utxo的锁定脚本将被解锁。此信息称为“脚本签名”，当输入中包含正确的脚本签名时，支出条件得到满足，比特币可以被花费。回到alice和bob的utxo示例，在第1步中，alice必须在其输入中提供她的私钥签名以花费她的utxo。随后，bob在花费他新收到的0.5 btc之前必须提供相同的信息。

比特币的脚本语言可以包含更复杂的支出条件，例如需要多个签名或在特定区块高度解锁比特币。然而，比特币脚本并非通用的，缺乏像以太坊原生编程语言solidity那样的表达能力。因此，使用比特币脚本为桥接和托管解决方案编程智能合约逻辑极具挑战性。

3、截至2025年比特币脚本面临的障碍

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

比特币脚本的最大限制是该语言无法读取/写入和存储交易数据，因为它只能读取花费者提供的输入。如果编程语言无法存储全局状态，脚本就无法独立验证应用程序或桥上的账户余额。比特币脚本逻辑无法访问全局状态，因为任何状态数据都必须适合单个交易。因此，几乎不可能开发通用功能或在l2网络和比特币基础层之间构建无信任桥接。

自2020年以来，克服比特币脚本限制的举措一直在进行中。多年来，开发者之间似乎已经达成共识，即提高比特币脚本表达性的唯一途径是执行软分叉升级，实施新的操作码以实现covenants。虽然比特币社区的一部分人认为这些升级对比特币网络构成风险，但另一部分人认为比特币需要更多的可编程性功能来扩展比特币的用例。尽管在哪个操作码最适合提高比特币交易可编程性方面尚未取得实质性进展，但covenants的倡导者现在大多同意op_ctv和op_cat是增强比特币交易可编程性的主要比特币改进提案（bips）。我们了解到，在比特币上实施covenants的解决方案不止两种，但本文仅描述op_ctv和op_cat这两个最突出的提案。

4、bip 119（op_ctv）

比特币改进提案119（bip 119），也称为check-template-verify（ctv），是由比特币核心开发者jeremy rubin于2020年1月提出的提案。该提案引入了一个新的操作码op_ctv，该操作码可以在比特币交易的输出上实施一般支出条件，即covenants。下面来做一个简单的背景介绍。“check_template_verify”中的模板部分指的是编写比特币脚本时必须遵循的交易格式。check-template-verify是一种新功能，它使交易输出的锁定脚本能够承诺存储在锁定脚本中的支出条件作为哈希，也称为承诺哈希。因此，只有在满足承诺哈希中详细说明的条件时，交易输出才能被解锁。一旦在链上广播，与交易相关的承诺哈希是不可变的。op_ctv的好处是交易发送者可以对接收者施加支出条件，这是对比特币脚本当前规则的重大改变，当前规则只能构造发送者的支出条件。

covenants契约主要有两种类型。一般契约可以复制并应用于多个utxo。covenants在utxo被花费后不会过期。另一方面，预计算契约也可以复制，但只能在有限的、预定义的次数内使用。预计算契约的逻辑必须由发送者提前指定，并且与一般契约的不同之处在于支出条件不能无限复制。一般契约，也称为递归契约，可能会对utxo的可替代性构成风险，这就是为什么bip 119的倡导者通常只关注使用预计算契约的op_ctv用例，以及为什么bip 119不支持一般契约。例如，如果启用一般契约，托管人或比特币交易所可能能够处理带有永久性支出条件的提款，这些比特币可能永远摆脱不了受到政府或其他权威机构审查的可能性。

5、使用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个区块后花费btc，也就是大约10年后。alice还包含了详细说明她的找零输出约0.2 btc将发送到她拥有的金库地址的指令，该地址将锁定她的utxo 525k个区块，即大约10年后。

步骤2：bob和charlie在525k个区块后花费他们各自价值0.4 btc的utxo。alice设置的锁定脚本将根据当前区块高度检查承诺哈希，如果满足条件，bob和charlie可以花费他们的新utxo。

在步骤2中，bob和charlie花费他们的utxo后，比特币脚本的一部分，也称为“锁定脚本”，将检查支出条件的履行情况，确保在释放btc之前满足所有条件。此操作通常称为使用正确的脚本签名“解锁”比特币输出。如果条件未满足，锁定脚本将不会启动btc的转移。

步骤3：在charlie和bob满足锁定脚本中的承诺哈希后，返回给alice作为找零的utxo（约0.2 btc）被用作具有指定金库脚本公钥的地址的输入。金库脚本公钥包括一个哈希，允许alice在525k个区块后解锁金库以花费她价值约0.2 btc的utxo。使用金库方案的好处是，alice可以在哈希中添加详细的安全措施，例如秘密恢复地址，以防有人窃取她的私钥并尝试在525k个区块时间锁之前解锁utxo。

如果没有covenants，在前面的示例中，alice需要创建一个预签名交易，以对她花费给bob和charlie的btc强制执行未来的支出条件。预签名交易可以是单个或多个交易，由发送者的私钥提前签名，但实际上并未广播到网络进行确认和执行。预签名交易不可扩展，因为它们要求用户存储多个交易的数据，直到它们在链上执行。此外，预签名交易要求在资金可以花费时所有签名方之间的互动性。然而，通过op_ctv使用承诺哈希实现covenants，减轻了用户存储预签名交易数据并依赖与交易相关的所有方之间的互动性的需求。

广义上讲，此功能可用于创建一系列复杂、高度安全和弹性的托管和安全设计，有助于改进自托管或托管设置，创建创新的新法定人数（quorum）或业务账户设置，或创建更自主的执行方案，具有更高的透明度和可靠性。

6、bip 347（op_cat）

bip 347是另一个比特币改进提案，由ethan heilman和armin sabouri于2023年10月编写，该提案也可以在比特币交易的输出上实现预计算的支出条件。该提案建议将op_cat操作码添加到比特币的脚本语言中，该功能允许比特币开发者在堆栈中将两个数据点“连接”在一起，并将这些值放在堆栈的顶部。我们来看简单的背景介绍。“连接”（concatenating）是将两个或多个代码字符串组合成一个更大的字节或数据字符串的过程。比特币脚本是一种基于堆栈的编程语言，按顺序计算每个代码字符串。对于由5行代码组成的堆栈，比特币脚本将首先计算第1行，最后计算第5行。不幸的是，比特币的脚本语言不包含允许开发者在整个堆栈中合并多个代码字符串的操作码。目前，比特币脚本缺乏算术和乘法 功能，抑制了压缩比特币脚本的能力，这限制了大型脚本（大于32位）和小型脚本（小于32位）在单个堆栈中的交互。如果没有通过“连接”压缩脚本并允许大型脚本与小型脚本通信的能力，交易输出上的复杂支出条件是不可行的。

至关重要的是，堆栈顶部的比特币脚本的连接元素可以模拟算术和乘法 功能，从而实现复杂脚本，而无需编写更容易出错的长数据密集型脚本。此外，op_cat的连接功能允许开发者使用merkle树和tapscript中的其他哈希数据结构生成支出条件，tapscript是用于启用新交易类型的原生脚本语言，作为2021年11月激活的taproot升级的一部分。

值得注意的是，中本聪禁用了op_cat以及其他使比特币脚本能够在脚本内直接执行复杂数学操作的操作码。中本聪本人删除了op_cat，因为该操作码在当时比特币脚本限制为2000字节时，结合op_dup可以构建数据密集型脚本。这种规模的脚本可能会增加比特币节点的计算资源负担并使其过载。然而，taproot升级在2021年引入了taproot脚本的大小限制（520字节），因此op_cat不再为节点操作者引入过多的计算开销。

7、使用bip 347（op_cat）部署covenants

2021年的taproot升级将schnorr签名引入比特币脚本语言。schnorr签名支持公钥和私钥聚合，使得多方可以通过单一签名共同签署一笔交易。将schnorr签名中包含的验证操作码与op_cat结合，可以创建一种非递归契约，生成交易哈希。通过op_cat，用户可以约束交易的某些部分，例如发送地址或发送金额，作为解锁脚本的要求，交易哈希则作为解锁的关键。

以金库方案为例，以下是op_cat功能如何实现covenants的总体概述。本示例的技术细节超出了本文范围。

alice希望创建一个在100个区块后解锁其utxo的金库：

*步骤1：alice将其utxo花费到一个金库地址，并在见证字段中包含金库解锁脚本的支出条件细节，包括区块高度。

*步骤2：在alice的交易过程中，op_cat将见证字段中的金库解锁指令连接起来，并对它们进行两次哈希运算以获取sighash/txhash。

*步骤3：在100个区块确认后，alice通过广播金库utxo的支出交易来启动花费其金库比特币的过程。为了验证alice是否满足所有支出条件，她的钱包在后台执行checksig操作码。此操作执行两个关键验证：验证初始设置交易（步骤1）中的交易哈希，并将其与当前支出交易（步骤3）进行比较。checksig函数重建设置交易的组件，并验证当前交易的公钥签名，以确保所有金库支出条件均已满足。

*步骤4：在alice交易的公钥通过checksig验证后（checksig重建了存储在见证字段中的支出条件），alice可以自由花费她的utxo。

上述示例展示了op_cat本身无法在交易上实施支出条件，而是op_cat与比特币脚本中的其他操作码结合可以简化脚本编写，从而实现covenants。op_cat的唯一功能是将堆栈顶部的两个元素连接起来。

尽管op_cat可以与checksig一起用于创建covenants，但仅添加op_cat并不会为比特币脚本带来类似solidity的功能。这一限制同样适用于仅添加op_ctv。即使使用op_cat，比特币交易也只能进行最小程度的内省（introspection），这意味着交易无法完全访问先前交易的元素或状态。因此，op_cat只能支持taproot交易输出的细粒度covenants。op_cat无法修复taproot输出的叶子节点或验证使用的内部密钥。taproot叶子节点是提交到taproot输出的单个支出条件或脚本。可以将它们视为花费比特币的不同“路径”或方式——每个叶子节点代表一种可能的花费方式。比特币taproot交易中的内部密钥是用于最有效支出路径的主要公钥。当使用内部密钥花费utxo时，你只需在链上提供签名，无需揭示任何脚本或merkle路径。

需要注意的是，这些限制可以通过其他操作码提案（如op_tweak_verify和op_internalkey）解决。总体而言，op_cat可以被视为生成交易输出上复杂支出条件的主要构建块，然而，包括checksig在内的其他构建块对于推进比特币交易可编程性的发展至关重要。

8、covenants可带给比特币的关键特性

（1）无信任桥接与单边退出

starkware（以太坊上starknet zk-rollup的创建者）发布了一份报告，强调了op_cat如何支持创建stark验证器和merkle验证器，以实现无信任的比特币桥接。无信任桥接通过递归契约系统构建，该系统通过记录在merkle树中的交易链来维护桥接状态。该机制的核心是存储在不可花费的op_return输出中的桥接持久状态，其中包含代表账户余额的merkle树的根哈希。op_cat covenant要求每笔新的存款或取款交易都包含反映当前桥接状态的有效状态转换。用户通过专门的存款和取款covenants与桥接交互，这些covenants使用merkle树将多笔交易聚合为批次以进行高效验证。然后，该merkle树的根合并到主桥接契约中，该契约验证并处理每笔存款或取款。在取款期间，契约通过确保取款地址与叶子交易中第一个输入的地址匹配来验证所有权。该设计利用merkle证明在比特币脚本中进行高效的状态更新，创建了一个无信任系统，其中桥接的状态和规则完全通过由op_cat创建的链上契约逻辑强制执行，而不需要第三方信任。至关重要的是，对于验证端系统状态转换的无信任比特币桥接，比特币脚本需要验证证明。op_cat通过将哈希数据连接在一起，在比特币脚本中构建stark验证器的能力，使得utxo锁定脚本能够验证端系统状态转换的zk-proof（零知识证明）。

taproot wizard团队创新了一种新的无信任桥接框架，将op_cat与bitvm结合。bitvm通过允许在比特币上分割和执行任意计算，实现了图灵完备的表达能力。bitvm将利用比特币脚本的任意计算的运行时分割到比特币上的多个交易中。如果没有covenants，锁定比特币的bitvm桥接需要预签名交易来设置桥接。op_cat从先前交易中携带数据的能力使得bitvm桥接能够在没有预签名交易的情况下锁定和解锁比特币。op_cat可以通过一种称为“cat on the stack”的技巧从先前交易中携带数据。该技巧涉及在堆栈上连接哈希数据以构建merkle树根，op_cat可以验证该根。因此，catvm桥接确保来自先前交易、存款和取款的特定交易数据必须包含在下一笔交易中，以保证在成功取款后merkle根被延续。cat on the stack技巧还确保在一个用户取款后，剩余的桥接比特币可以由任何符合条件的用户取款。

（2）高级金库托管

比特币金库是一种新的托管解决方案，包含诸如恢复路径等安全功能，允许用户在私钥泄露的情况下将其比特币提取到一个秘密地址。bip 345，正式名称为op_vault，是一项待定的比特币改进提案，利用op_ctv来增强比特币托管的安全参数。需要注意的是，op_cat也可以用于创建比特币金库的支出条件，而无需预签名交易。比特币核心开发者james o’beirne于2023年1月提出了op_vault，以缩小op_ctv的用例范围。op_vault依赖op_ctv为金库比特币创建支出条件，而无需存款人预先签署多笔交易。covenants允许金库具有时间延迟，当任何人在原始时间锁之前尝试花费金库比特币时，时间延迟将被触发，通常这是试图窃取资金的攻击者。

（3）non-equivocation合约

non-equivocation合约于2015年被引入比特币网络，是比特币交易输出，如果签名者双花，则会泄露签名密钥。在实践中，用户锁定原生比特币，作为可罚没的保证金。该保证金允许用户在基础层上执行0确认交易，这些交易稍后在区块中被挖出。0确认交易是由比特币共识规则验证和保护的即时比特币交易。如果0确认交易的发送者在交易被挖出之前花费了输入，则对手方可以从泄露的签名密钥中罚没其比特币保证金。

（4）闪电网络的改进

op_cat可以启用通道工厂（channel factories），允许用户在不首先在比特币基础层上广播通道开放交易的情况下打开闪电通道。例如，如果alice希望创建2个闪电通道（一个与bob，另一个与charlie），alice将广播与bob和charlie的通道开放交易（2笔交易）。通道开放交易要求双方将比特币存入2/2的多重签名地址。通过通道工厂，bob和charlie可以在不广播新的通道开放交易的情况下彼此打开单独的通道。因此，原始通道开放交易中的所有参与者可以彼此创建独立的通道。

op_ctv可以创建共享utxo，其中一个utxo代表多个用户。使用ctv的共享utxo可以使多个用户通过一笔链上交易打开多个闪电通道。通常，每个闪电通道需要一笔链上交易。因此，如果许多用户打开闪电通道，这可能会使内存池充满待处理的交易并增加交易费用。虽然目前这不是问题，但通道开放需要扩展以支持闪电网络吸引数百万活跃用户。

9、op_cat和op_ctv相关风险

所有比特币软分叉都包含技术风险，例如新操作码的错误或未预见的用例。尽管前者很少见，但后者在铭文（inscriptions）的创建中暴露出来。铭文涉及在交易的见证字段中输入任意数据，这已被用于在比特币上创建新代币和nft集合。segwit和taproot升级共同使用户能够将图像和文本数据作为字符串数据输入到见证字段中。虽然数字艺术和可替代代币的创建并不是激活segwit或taproot的重点，但多年后，聪明的开发者发现了如何将这些升级用于其他目的。galaxy research在我们的ordinals报告中强调了这一观点，并指出通过segwit和taproot意外创建的铭文可能对未来比特币升级产生负面影响，因为社区对这些新用例的惊讶可能会使其更加犹豫是否支持新的软分叉。

尽管对比特币升级能力的看跌情绪存在，但op_cat和op_ctv已经过大量测试和研究。对covenants的最初批评是，政府可能会强制应用程序强制执行仅允许一组批准地址花费比特币的支出条件。这一批评是无效的，因为支出条件的条件由拥有资金的用户决定。用户可以创建限制未来支出到特定地址的交易，但这些限制不能由第三方外部强制执行，并且在锁定资金被花费后不能永久延续。因此，政府无法强制执行自托管金库应用程序或bridge如何花费资金。尽管托管人和比特币交易所仍然可以限制用户如何花费资金，但他们无法在没有执行一般契约能力的情况下为取款资金添加永久支出条件，而op_ctv不允许一般契约。

总体而言，op_cat和op_ctv是简单的操作码，每个操作码都能很好地执行一项功能。op_cat将堆栈顶部的两个元素连接起来，而op_ctv可以在锁定脚本中对支出条件进行哈希。这些操作码的一些用例（如无信任桥接的开发）仍需要进一步研究和实战测试，因为桥接极易受到bug和黑客攻击的影响。

10、下一软分叉升级的covenants部署路径

确定比特币利益相关者对未来协议升级的共识是一个复杂的过程，随着提案的生命周期——也称为bip（比特币改进提案）过程——而演变。bcap关于比特币升级历史的报告详细描述了这些利益相关者的角色如下：

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

*投资者：巨鲸、microstrategy、etf提供商、galaxy

*媒体红人：coindesk、比特币杂志、x名人、播客

*矿商：bitmain、microbt、riot、marathon、大型私人矿商

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

*应用开发者：l2项目

在整个比特币改进提案（bip）的生命周期中，不同的利益相关者行使不同程度的影响力，他们的相对影响在实施软分叉的共识构建过程中发生变化。以下是各利益相关者影响力等级的详细划分，按1-10排名。截至2024年3月，op_cat和op_ctv处于协议构思阶段。在此阶段，媒体人物的影响力最大，因为他们可以左右公众意见并创造叙事。例如，taproot wizards是一支由知名比特币红人组成的团队，他们利用其庞大的社交媒体粉丝群向比特币社区宣传op_cat的好处。taproot wizards团队一直在制作关于op_cat的教育内容和研究，以推动比特币脚本需要新操作码以增强交易可编程性的叙事。因此，taproot wizards为op_cat培养了一大批支持者，他们正在推动核心开发者审查op_cat bip草案。

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

op_cat和op_ctv bip正处于媒体红人、用户和应用开发者利用其影响力说服比特币核心开发者这些共识变更将提高比特币交易可编程性的阶段。共识之旅的下一阶段将需要技术名人、应用开发者和核心开发者进行具体研究，详细说明op_cat和op_ctv的所有潜在风险。如果没有具体的研究和与核心开发者的公开对话，将不会有更广泛的核心开发者社区对op_cat和op_ctv形成集体观点。

一旦在核心开发者之间达成共识，op_cat和op_ctv将需要指定一名主要维护者，以促进将bip实施到比特币核心存储库的最后步骤。在op_cat和op_ctv的bip合并到比特币核心存储库后，必须决定激活方法。一旦选择了激活方法，信号期就开始了，矿商、投资者和经济节点的影响力最大。截至2024年3月，矿商、microstrategy等大型投资者以及coinbase等经济节点对op_cat和op_ctv还没有发表公开看法。在bip实施之前，这些利益相关者需要进一步了解op_cat和op_ctv的风险和好处。

11、bip激活方法

如果比特币核心开发者同意将op_cat或op_ctv包含到下一个软分叉升级中，社区需要就bip的激活方法达成一致。激活方法允许矿工发出他们对升级的准备信号。

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

当软分叉由用户（而非矿商）激活时，就被称为用户激活软分叉（uasf）。比特币上最著名的uasf示例几乎发生在2017年8月1日的“区块大小之争”期间，以帮助加快segwit升级的采用。在区块大小之争期间，比特币用户升级了他们的节点以支持segwit升级，并随后威胁要拒绝来自未升级节点的区块。通过这样做，鼓励未升级其比特币客户端软件的矿工采用segwit，以使其区块更广泛地传播并增加他们获得区块奖励的机会。虽然uasf在区块大小战争期间从未发生，但潜在uasf的威胁影响了矿工采用segwit。

第二种实施代码更改的方法是通过硬分叉，这是一种向后不兼容的升级，会在升级和未升级节点之间永久分 裂共识。比特币核心开发者从未实施过硬分叉，因为社区重视协议代码的固化和向后兼容性。如果少数用户执行硬分叉升级（例如更改区块大小），比特币可能会发生链分 裂。这就是比特币现金在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：比特币核心开发者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日正式在比特币上激活。

*现代软分叉激活：这是一种结合bip 9和bip 8不同属性的升级激活方法。它由bitcoin core最多产的贡献者之一matt corallo于2020年1月提出。该方法包括三个步骤。第一步是bip 9中概述的矿工激活软分叉。如果矿工未能激活升级，corallo概述的现代软分叉激活过程将默认为第二步，即开发者和更广泛的比特币社区重新考虑代码更改的六个月等待期。六个月后，如果开发者和用户希望继续升级，他们可以启动第三步，这本质上等同于将lot参数设置为true的bip 8。

以上就是比特币的下一个重大升级是什么？对op_cat和op_ctv的评估的详细内容，更多关于covenants可带给比特币的关键特性的资料请关注代码网其它相关文章！