Cointelegraph Research 发布了比特币契约系列的第五部分，详细介绍名为 MATT（Merkleize All The Things）的新框架以及 OP_CHECKCONTRACTVERIFY（OP_CCV）操作码。该提案旨在赋予比特币在多个交易间携带可变合约状态的能力，而标准比特币脚本因每笔交易独立评估而缺乏此功能。

BTC / USD
来源：CoinGecko。价格仅供参考。

MATT 如何在 Taproot 密钥中嵌入状态

MATT 基于 Taproot 已有的调节机制构建，其中 Taproot 输出的公钥 Q 通过 Q = P + t·G 计算得到，P 为内部密钥，t 为待提交数据的标签哈希。MATT 不仅提交脚本树的 Merkle 根，还将合约状态嵌入调节值。状态经过哈希后加入调节，使得下一个输出能够携带重新计算后的新状态，在花费时生效。

OP_CHECKCONTRACTVERIFY 强制状态转移

MATT 的核心原语是 OP_CHECKCONTRACTVERIFY。报告称 OP_CCV 让脚本能够验证 Taproot 输入或输出密钥是否已使用特定状态数据进行调节。该操作码的栈格式为 <data> <index> <pk> <taptree> <mode> OP_CHECKCONTRACTVERIFY，支持三种模式：default（完整输入价值转移至指定输出）、deduct（仅转移输出金额，剩余用于其他输出）和 ignore（仅验证不受金额约束）。这些模式在保值的同时允许独立的费用输入，避免了早期契约设计如 OP_CTV 或 SIGHASH_ANYPREVOUT 中出现的资金燃烧问题。

使用 OP_CAT 扩展表达能力

当 OP_CHECKCONTRACTVERIFY 与 OP_CAT 结合时，框架能够在链上构建并验证 Merkle 证明。每个 Taproot 输出关联两棵 Merkle 树：标准脚本树和存储中间计算步骤的状态树。OP_CAT 用于连接字节串，使脚本能够重建当前状态的 Merkle 证明，计算转移后的新根，然后通过 OP_CCV 强制下一个输出提交该新根。此设计支持类似乐观汇总的防欺诈系统，大部分计算在链下完成，仅将有争议的步骤上链验证。

后续关注点

MATT 的下一步将是正式的 BIP 提案以及在 Bitcoin Core 中对 OP_CHECKCONTRACTVERIFY 实现的社区测试。请关注比特币开发者邮件列表以及任何展示有状态合约、欺诈防护金库或系列中提及的其他用例的测试网部署。

FAQ

什么是 OP_CHECKCONTRACTVERIFY？

OP_CHECKCONTRACTVERIFY 是一种提议中的比特币操作码，用于验证 Taproot 输出的密钥已被调节以提交特定合约状态数据，从而实现有状态 UTXO。

MATT 与早期契约提案有何区别？

MATT 在花费时支持动态计算新状态并允许灵活的费用输入，而早期提案如 OP_CTV 需要固定金额且缺乏动态状态更新。