OP_CCV 将合约状态直接嵌入到 Taproot 输出密钥中，并在链上强制执行有效的状态转换。这使得实现有状态的合约和紧凑的欺诈证明成为可能。

这是 Cointelegraph Research 有关比特币契约的技术文章系列的第 5 部分。要阅读上一篇文章，请点击此处。

MATT（Merkleize All The Things）是比特币的智能合约框架，可实现状态合约和可扩展的欺诈证明。有状态合约在多个交易中传递信息，并且可以随着合约的发展更新此信息。标准比特币脚本不提供此功能，因为每笔交易都是独立评估的，没有先前执行的记忆。

每个契约提案都在一定程度上允许状态承载 UTXO，如基于 OP_CTV 构建的 Sapio 等脚本语言所示。这是通过使用地址来表示有限状态自动机来实现的，其中事务充当状态转换。然而，在这种范式中无法优雅地实现数值逻辑，这一空白由 MATT 填补，特别是其通过 OP_CCV 提出的实现。由于 MATT 允许在花费时计算提交的数据并将其重新嵌入到下一个输出中，因此每次花费都可以动态派生一个新状态，而不是从预定的一组状态中进行选择。

OP_CCV 如何将状态提交到 Taproot key 中

要理解 MATT 提案，首先回顾一下 Taproot 如何通过公钥提交数据是很有用的。每个 Taproot 输出都包含一个基本公钥，称为内部密钥，可以对其进行加密修改或“调整”以提交额外信息。形式上，调整后的公钥为 Q = P + t·G ，其中 P 是内部密钥，G 是 secp256k1 椭圆曲线的生成器，t 是 P 和提交数据的标记哈希。

在常规 Taproot 输出中，此承诺通常对 Taptree 的 Merkle 根进行编码，其中包含隐藏的支出路径。 MATT 建立在该机制的基础上，还将合约状态嵌入到密钥中。 MATT 没有将复杂的逻辑直接嵌入到比特币的脚本语言中，而是将计算编码为一系列状态承诺，并且链仅验证每个状态转换是否有效。

MATT可以通过不同的操作码组合来实现。最直接且明确的实现依赖于 OP_CHECKCONTRACTVERIFY (OP_CCV)。 OP_CCV 提供了使状态承载 UTXO 在 Taproot 中可行的原语。 OP_CCV 允许脚本验证 Taproot 输入或输出键是否已被调整以提交特定的状态数据。首先使用合约当前状态的哈希值对内部密钥进行调整，然后在顶部应用 Taproot 的标准 Taptree 调整。因此，生成的输出密钥会同时遵守 Tapscript（支出条件集）和合约的当前状态。

然后 OP_CCV 可以强制将什么状态转入下一个输出。它允许脚本检查见证堆栈上提供的状态数据，对其执行计算，并要求在指定的输出中正确地重新提交生成的更新状态。这就是在链上执行状态转换的方式。堆栈格式为：

<数据> <索引> <pk> <taptree> <模式> OP_CHECKCONTRACTVERIFY

该操作码支持三种检查输出的模式以及单独的输入模式。默认模式下，输入UTXO的整个BTC值分配给指定输出；在扣除模式下，仅分配等于输出金额的部分，其余部分可用于进一步输出；在忽略模式下，验证脚本和数据承诺，不限制数量。由于默认和扣除模式旨在保留已检查输出的价值，因此交易费用必须通过单独的付费输入来支付。可以将专用的费用输入和找零输出添加到交易中，而不与契约的约束发生冲突。这可以防止在更原始的契约实现中发生的资金意外燃烧，例如 OP_CTV 或 SIGHASH_ANYPREVOUT。它还解决了预先签署的交易式契约的一个主要限制，这些契约通常预先定义金额，因此无法适应动态费用调整或部分取消保险库。

OP_CCV + OP_CAT：Merkle 证明和欺诈证明

当 OP_CCV 与 OP_CAT 结合使用时，完整的 MATT 框架变得更具表现力。 OP_CAT 支持在脚本中进行字节连接，从而可以直接在链上构造和验证 Merkle 证明。在这种安排中，两个不同的默克尔树与主根输出相关联。第一个是熟悉的 Taproot 脚本树（taptree），其叶子是合约的支出脚本。第二个是一个单独的状态树，其叶子是合约的数据，例如计算的中间步骤。 OP_CCV + OP_CAT 脚本可以根据当前状态树根验证 Merkle 证明，计算转换后更新的根，并使用 OP_CCV 强制下一个输出提交给它。

这种结构使得防欺诈系统具有削减条件，其中长计算在链外提交，并且只有特定的有争议的步骤（及其在二叉树中的路径）需要在链上显示和验证。类似的系统以乐观汇总的形式存在于其他区块链系统上：完整的计算在链外运行，链上合约仅在有人提出挑战时进行干预。欺诈证明要求将计算编译为二进制电路或等效的可提交到 Merkle 树中的逐步表示。 OP_CCV + OP_CAT 将无需 BitVM 所依赖的 Lamport 一次性签名和预签名交易图来强制执行状态一致性。

除了欺诈证明之外，OP_CCV 和 OP_CAT 组合还对金库产生影响。 OP_CCV 单独可以实现保管库，但是当与 OP_CAT 结合使用时，它可以实现功能齐全的保管库，这些保管库基本上等同于 OP_VAULT 提出的功能。正如 OP_VAULT 的作者 James O’Beirne 所指出的那样，OP_CCV 代表了一种更通用、更稳健的设计，有效地取代了他之前的提议。

在本系列的下一篇文章中，我们将从一般契约提案转向审查特定于应用程序的操作码，例如 OP_VAULT、OP_UNVAULT 和 OP_EVICT。每个操作码都旨在解决特定问题，而不是提供广泛的可编程性。