Bitcoin Core 仓库中目前开放的一份提案，将为网络脚本带来一项前所未有的能力：记忆。其背后的框架被称为 MATT（Merkleize All The Things），可在比特币基础层上实现有状态合约和可扩展的欺诈证明，而其最直接的实现路径是通过 Bitcoin Core 拉取请求 #32080 中提出的 OP_CCV 操作码。COINOTAG 于 2026 年 11 月 11 日报道了这一进展。

MATT 的设计目标

Bitcoin 现有的脚本语言对每笔交易输入单独求值，脚本没有内建机制来规定这些币此后如何被花费。MATT 由开发者 Salvatore Ingala 于 2022 年底在 Bitcoin-Dev 邮件列表上首次提出，正是针对这一空白：其目标是让 Bitcoin 脚本在交易之间携带状态——实际上就是赋予合约一种记忆——而只需对脚本语言做极小的扩展。这类构造通常被称为契约（covenant），它限制一笔币在未来交易中的花费方式，可实现金库（vault）以及其他自执行花费规则等设计，将恢复和花费条件直接附加到币本身。

契约类提案在 Bitcoin 社区已流传多年，MATT 加入了相关工作的行列，例如开发者 Jeremy Rubin 提出的 OP_CHECKTEMPLATEVERIFY（OP_CTV），共同寻求扩展基础层所能表达的能力。

欺诈证明与基础层验证

该框架的第二个目标是可扩展的欺诈证明：一种验证方案，其中链下计算只有在受到质疑时才在链上被检验，而不是完整重新执行——这一模式在其他平台的乐观汇总（optimistic rollup）设计中即有采用，计算发生在链下，只有存在争议的结果才需要基础层的审查。由于验证工作量与质疑次数挂钩，而非计算本身的规模，这类方案被称为可扩展的。在 MATT 的设计中，这种验证将直接在比特币基础层上运行，OP_CCV（OP_CHECKCONTRACTVERIFY 的缩写）作为执行合约逻辑的核心操作码。

审查而非激活

影响比特币共识的变更通过 Bitcoin Core GitHub 仓库中的公开拉取请求推进，技术审查和测试通常持续较长时间。由于比特币的共识规则最终由网络中全节点运营者执行，代码审查获得好评只是其中一步；更广泛生态的普遍采用才能将一项提案转变为有效的网络规则。比特币最近一次共识升级 Taproot，在历时数年的过程后于 2021 年 11 月激活，这一历程说明了此类工作可能耗时多久。拉取请求 #32080 与所有此类提案一样，在考虑激活之前都需要大量审查和广泛的社区共识；来源报道未给出时间表。GitHub 上的公开审查讨论串中，贡献者的技术评论和修订不断累积，为跟踪该提案的进展提供了直接途径。

本文内容最早发布于 COINOTAG：https://en.coinotag.com/matt-op-ccv-bitcoin-covenant-pull-request-32080