MATT提案通过OP_CCV为比特币(BTC)带来带状态合约

给比特币脚本装上“记忆”的 opcode

比特币核心代码库中目前有一个开放的提案,试图给网络脚本带来一种前所未有的能力:记忆。MATT(Merkleize All The Things)框架的目标是在基础层实现带状态的合约和可扩展的欺诈证明,其最直接的落地路径是OP_CHECKCONTRACTVERIFY(简称OP_CCV),该opcode由第32080号拉取请求承载。所谓契约(covenant),是一种脚本规则,用来约束未来的交易中这些币只能花向何处。标准比特币脚本对每笔交易独立求值,不记录此前花费发生过什么,因此合约无法把信息向后传递并随合约演进而更新。事实上,每一份契约提案都在某种程度上允许带状态的UTXO。 Sapio这类构建在OP_CTV之上的脚本语言,把地址当作一个有限状态自动机来处理,每笔交易对应一次状态转移。契约议题多年来一直活跃在比特币协议提案之列,原因正是普通Script无法提供上述保证。问题在于,自动机范式没有干净的办法表达数值逻辑,而这正是MATT要填的空档。MATT允许被提交的数据在花费时重新计算并嵌入下一个输出,因此每次花费都可以动态推导出新状态,而不是从一组预设状态里挑选。该opcode面向Taproot输出设计:承诺信息直接挂在公钥本身上,而不是依赖额外的脚本数据。这个差别决定了合约到底能随余额变化而自适应,还是只能固化在一棵事先约定好的结果树上。这个提案针对的是比特币(BTC)价格之下的脚本层,与任何图表上可见的东西无关,但它定义了这种资产在简单结算之外还能做什么:从在花费时重新计算提款条件的金库,到只验证单个争议计算步骤的欺诈证明系统,都建立在其之上。

改造过的密钥与三种检查模式

每个Taproot输出都包含一个基础公钥,称为内部密钥(internal key),它可以通过密码学方式被修改(即tweak),以提交额外的信息。改造后的密钥形如Q = P + t·G,其中P是内部密钥,G是secp256k1椭圆曲线的生成元,t是对P与被提交数据做带标签哈希的结果。在普通的Taproot输出中,这个承诺通常编码的是一棵taptree的Merkle根,树里存放着隐藏的花费路径。MATT复用了同一机制,把合约状态也嵌入密钥之中,于是链上只需验证每次状态转移是否有效,而不必执行合约逻辑。该opcode接收状态数据、输出索引、公钥、一个可选的taptree和一个模式。三种模式用于检查输出,另有单独一种模式检查输入。默认模式(default)把输入UTXO的全部价值分配给指定输出;扣减模式(deduct)只分配与输出金额相等的部分,剩余部分可自由用于其他输出;忽略模式(ignore)只验证脚本和数据承诺,不约束金额。由于默认模式和扣减模式把价值锁在被检查的输出内,交易手续费必须通过单独的付费输入来支付;专用的费用输入和找零输出可以随交易并行存在,不会与契约约束冲突。这就避免了OP_CTV或SIGHASH_ANYPREVOUT这类更原始的契约方案可能造成的资金误烧,也修复了预签名交易式契约的局限:后者把金额写死在前,无法应对动态手续费调整或部分解押。当OP_CCV与OP_CAT(在Script中实现字节拼接)配合时,表达能力会再度扩展。两者可以在链上针对第二棵树构造并验证Merkle证明,这棵树存放的是合约数据而非花费脚本,然后强制下一个输出提交到更新后的根。欺诈证明系统随之成立:漫长的计算在链下运行,只有存在争议的那一步及其在二叉树上的路径会被揭示并在链上验证。前提是该计算必须先被编译成逐步的二进制表示,这正是elftrace二进制电路工具要解决的问题。这一构造与以太坊乐观rollup如出一辙,同样的欺诈证明模型也支撑着众多跨链桥。它还能省掉BitVM为强制状态一致性所依赖的Lamport一次性签名和预签名交易图,并且可以复现OP_VAULT提出的金库功能;OP_VAULT的作者James O'Beirne曾表示,OP_CCV是更通用、更稳健的设计,实际上取代了他此前的提案。

审查之路还很长

把OP_CCV与早期契约草案区分开的,正是手续费处理设计。由于默认和扣减模式把价值锁在被检查的输出内、费用走独立输入,带状态的设计在活跃的手续费市场中依然可行,而预签名流程在这一点上会失效。目前尚无任何合并动作。该拉取请求没有附带激活时间表,即便最终被采用,也需要节点运行者升级到执行新共识规则的软件,这是每一项比特币变更都要走的慢路。对持币者而言,更近期的意义在于设计空间:原生金库可以减少自托管保障对包装比特币的依赖,状态树则能拓展比特币DeFi在无需受托机构的情况下能结算的范围。接下来的动作掌握在Bitcoin (BTC) Core的审查者和更广大的开发者社区手里:他们必须先审计该opcode的共识行为,上述一切才有机会进入主网。