编译
|
GaryMa 吴说区块链
据 Blockspace 报道，比特币基层社区在开始推动比特币底层软件的变更，这是超四年以来少有的事（此前可能重大的底层变更都由核心开发者群体主导推动）。
这次正在涌现基层支持的是两个比特币改进提案（BIP），即 BIP-119（CTV） 和 BIP-348（CSFS）。这两个提案提出了新的比特币脚本编写方式，将使比特币能够实现 “契约”（Covenants）的功能。这两个提案可能会在比特币下一次软分叉中实施。
为了避免有些读者暂时无法理解比特币的 Covenants 以及这些具体的 BIP 方案的关系，这里我们理清一下：
简单来讲，Covenants 是比特币网络中的一个功能概念，而文中提及的两个 BIP 是为了实现这个功能概念的不同实现方案。
什么是比特币的 Covenants？
定义：
Covenants 是比特币协议中提议的机制，允许在交易中设置条件或限制，规定比特币如何被花费或转移。这些条件可以跨越多个交易，限制未来的支出方式，从而增强比特币的脚本功能。
作用：
·
提高比特币的智能合约能力，支持更复杂的应用（如贷款、去中心化交易所、保险库）。
·
增强安全性，防止资金被盗或误用。
·
优化网络性能，如减少交易费用或提高隐私。
这里我们大概就能清楚，Covenants 是一个概念，而本文提及的 BIP-119（CTV）和 BIP-348（CSFS），是 Covenants 这个功能概念的具体实现。
当前状态：
比特币主网当前并未正式集成任何 Covenants 相关功能，尽管相关讨论和提案（如 BIP-119）已推进多年。
BIP 119：OP_CHECKTEMPLATEVERIFY (CTV)
一个提议的比特币操作码，允许交易输出指定一个“模板”（Template），要求后续花费交易的输出必须匹配该模板。
由前比特币核心贡献者 Jeremy Rubin 提出，已经存在了超过五年。它通过限制资金只能按预定义方式花费，实现了“状态携带”的功能。
应用场景包括：
·
创建批量支付（Batch Payments），减少交易费用。 构建去中心化交易所（DEX）或贷款协议。
·
实现 Vaults（保险库），保护资金免受盗窃。
·
CTV 是 Covenants 的一种轻量级实现，专注于输出格式限制，而不涉及复杂逻辑。
BIP 348：OP_CHECKSIGFROMSTACK (CSFS)
一个提议的比特币操作码，允许验证一个签名是否对任意消息（Message）有效，而不仅仅是当前交易的哈希。它从数据栈中获取签名、公钥和消息，检查签名是否匹配。
由 Jeremy Rubin 与 Brandon Black 在 2024 年 11 月正式提出。
OP_CSFS 是实现更灵活 Covenants 的强大工具，因为它允许对交易输入进行“自省”（Introspection），即检查签名交易的完整内容或状态。
具体应用：
·
Covenants 实现：OP_CSFS 可用于创建复杂的条件逻辑，确保资金只能按特定规则花费。例如，验证者可以检查交易输入是否符合预设模板或限制。
·
安全增强：支持 Vaults 和去中心化协议，通过签名验证防止盗窃或未授权支出。
·
扩展性：与其他操作码（如 OP_CAT）结合，可构建更复杂的智能合约。
而提到了比特币的 Covenants 以及 BIP-119（CTV）BIP-348（CSFS）这两组提案，那么肯定是少不了 OP_CAT 的。
BIP 347：OP_CAT
历史：
早期存在：
OP_CAT 是比特币原始脚本语言的一部分，由中本聪（Satoshi Nakamoto）在 2009 年比特币推出时包含在内。它最初被设计为增强脚本的灵活性，支持更复杂的逻辑。
移除原因（2010 年）：
·
OP_CAT 在 2010 年被移除（禁用），原因是为了防止潜在的安全漏洞和资源滥用。
·
具体问题：如果不加限制，OP_CAT 可以被恶意用户用来生成无限长的数据（通过递归调用），导致“拒绝服务攻击”（DoS Attack），因为比特币节点需要处理这些数据，增加计算和存储开销。
·
当时比特币脚本语言被简化，保留了最基本的功能，确保协议的轻量化、安全性和去中心化。
定义与作用：
OP_CAT 是一个比特币脚本语言（Script）的操作码（Opcode），它不是直接的 Covenant 实现，但它是构建复杂 Covenant 逻辑的潜在工具。相比于上述两个操作码，OP_CAT 更通用，适合数据操作，但需要与其他操作码结合才能实现复杂功能。
现状：
比特币社区近年来重新讨论 OP_CAT 的回归，此前以较为社区玩性符号的 BIP-420 提案的形式出现，不过目前以BIP-347编号正式合并到 bitcoin/bips 仓库。
进展如何
据 Coindesk 消息，在过去的几周内，许多西方比特币开发者在 Twitter 上纷纷表达了对 CTV 和 CSFS 的支持 — — 这无疑是一个强烈信号，表明至少在社交媒体圈内，部分比特币社区正朝着接受这些变更的方向迈进。
此外，开发者普遍认为这两个提案的定义较为“狭窄”。通俗来说，这意味着一旦激活，被用户意外滥用的可能性较低。比特币开发者社区历来对比特币的变更持谨慎态度。例如，尽管 BIP 119 已经搁置近五年，但在不久前，CTV 还曾被视为过于激进，不宜激活。
这两个提案的共同发起者 Jeremy Rubin 早前为推广 CTV 所进行的活动曾遭到强烈反对 — — 尤其是来自一些拥有大量追随者的比特币意见领袖，如 Adam Back 和 Jimmy Song 的批评。种种批评最终演变为比特币社区中广泛的不满，迫使 Rubin 最终淡出了比特币领域。
那么，究竟是什么促成了这种变化？近期对 OP_CAT 操作码的倡导，似乎拓宽了被认为“可接受”的比特币提案的范围，将 CTV 与 CSFS 框定为相对“保守”的选项。值得注意的是，大多数支持 OP_CAT 的人士也同样支持 BIP 119 和 BIP 348（以及大多数其他提案）。
接下来我们可以期待什么？首先，讨论还将持续。预计开发者将在几场技术会议上进一步探讨这些提案，例如计划于 4 月举行的 OPNEXT、7 月的 BTC++ 以及 10 月的 TABConf。一旦开发者初步达成共识，软分叉的实际激活便将移交给矿工、社区和投资者进行最终确认。
如何跟进 BIPs 在社区的讨论进展/软发叉的流程？
答案是很难！
比特币的技术社区通常会就这些提案进行深入讨论。但这是一个看似晦涩且循环往复的讨论流程。
简单来说，比特币软分叉的流程需要大致估计比特币各利益相关方的支持程度，这包括开发者、托管者、投资者以及矿工。而最直观的支持指标通常来自矿工，因为他们能通过在所挖区块中发出信号来表明对代码库变更的认可。通常，Bitcoin Core 要求在一段时间内 95% 的区块发出支持信号，之后才会将更新锁定以待激活。
