比特币契约提案（五）：MATT 与 OP_CHECKCONTRACTVERIFY 如何让比特币在交易间延续状态

OP_CCV 将契约状态直接嵌入 Taproot 输出公钥，并在链上强制验证有效的状态转换。这使比特币能够实现有状态契约和紧凑型欺诈证明。

这是 Cointelegraph Research 关于比特币契约提案的技术系列第五篇。有状态契约能够在多笔交易间传递信息，并随着契约演进更新这些信息。标准比特币脚本不具备这种能力，因为每笔交易都会独立执行，不会记忆此前的执行结果。

各种契约提案都在一定程度上支持携带状态的 UTXO。例如，基于 OP_CTV 构建的脚本语言 Sapio，会用地址表示有限状态自动机，并将交易作为状态转换。不过，这种模式难以优雅地实现数值逻辑。MATT 填补了这一空缺，其拟议实现方式之一是 OP_CCV。MATT 允许在花费时计算已承诺的数据，并将其重新嵌入下一个输出，因此每次花费都能动态推导新状态，而不必从预先设定的一组状态中选择。

理解 MATT 提案前，可以先了解 Taproot 如何通过公钥承诺数据。每个 Taproot 输出都包含一个称为内部公钥的基础公钥，该公钥可以经过加密学上的修改，即“调整”，以承诺额外信息。形式上，调整后的公钥为 Q = P + t·G，其中 P 是内部公钥，G 是 secp256k1 椭圆曲线的生成元，t 是由 P 和承诺数据计算得出的带标签哈希值。

在普通 Taproot 输出中，这种承诺通常编码 taptree 的默克尔根，其中包含隐藏的花费路径。MATT 在此基础上进一步将契约状态嵌入公钥。它不把复杂逻辑直接写入比特币脚本语言，而是将计算编码为一系列状态承诺，由区块链验证每次状态转换是否有效。

MATT 可通过不同的操作码组合实现。最直接且规范最明确的一种实现依赖 OP_CHECKCONTRACTVERIFY（OP_CCV）。OP_CCV 提供了在 Taproot 中实现携带状态 UTXO 的基础操作，使脚本能够验证 Taproot 输入或输出公钥是否经过调整，以承诺特定状态数据。首先，内部公钥会根据契约当前状态的哈希进行调整，之后再叠加 Taproot 标准的 taptree 调整。因此，最终输出公钥同时承诺了 tapscript（即花费条件集合）和契约当前状态。