一笔交易带一个孩子的契约：v3 交易与 TRUC 政策怎么保护加急

合约协议的老麻烦：加急钱放哪

比特币的费用提升里有一条路线叫 CPFP：一笔交易没确认，就花它的输出再发一笔高费率的子交易，用子交易把整包的费用率抬上去。这对普通转账够用，但对闪电通道这类合约协议有个体面问题——开户交易的花费权属于双方共有，任何一方想单方面加急，都需要一笔能合法花那个共有输出的子交易。2019 年 Core 为此加了 CPFP carve out 例外，让闪电结构在后代限制上略有豁免。这个补丁能用，但代价是任何一笔普通交易理论上都可以成为这个例外的宿主，规则变得难推理。

后来的答案是给合约协议一种交易版本契约：交易版本号写为 3 的交易，接受一套严格的拓扑限制，换取加急路径的长期可预测性。

TRUC 规则到底限制了什么

TRUC 是 Topologically Restricted Until Confirmation 的缩写，中文可以译作确认前拓扑受限。Bitcoin Core 28.0（2024 年 10 月发布）的发行说明把这套政策说得很具体：版本号为 3 的交易自动声明可替换（即使没有传统 RBF 信号位）；未确认状态下，一笔 v3 交易的未确认父辈与子辈也必须是 v3，且未确认父辈与未确认子辈各至多一个，不再享有 CPFP carve out 豁免；单事务体积上限为一万虚拟字节；配合包提交与包替换接口，还出现了兄弟驱逐机制——新的竞争交易可以按替换规则驱逐那个唯一的旧子交易。这些规则的形式化描述写在 BIP431 里。

把这些规则合起来读，契约的意图就清楚了：牺牲交易结构的自由度，换两件事。第一，节点对一笔 v3 交易未来最坏打包前景的推理变简单，接收决策更敢做；第二，协议的加急结构（父加一个子）永远保持合法尺寸，谁也不能用堆砌依赖的方式把你的加急路堵死。配套的还有一个无脚本锚点输出模板，让加急的所有权规则只用见证结构表达，不再依赖旧的哈希锁形式。

版本字段的哲学

值得停一下的是版本号本身。比特币交易的版本字段原本用于启用新脚本或签名语义，v3 却把它用于策略声明——我不要求新共识规则，只请求节点按这套限制接待我。这是一个软分叉思维之外的务实发明：政策信号写进数据结构，旧节点照常验证，新节点据此施加更严的接受规则。

对闪电用户而言，这条演进线的现实收益是通道开户与状态更新的加急行为更稳定；对普通用户而言，除非你运营依赖未确认依赖链的服务，否则感知很淡。在 v31.0 引入的集群内存池下，这套拓扑契约与按簇推理的模型天然契合——1 父 1 子正是最小规格的簇。

快速问答

问：v3 交易和 RBF 冲突吗？ 答：不冲突。RBF 仍是交易字段声明的可替换机制，v3 管的是未确认依赖的形状约束，两者维度不同。

问：普通钱包要改用 v3 吗？ 答：不需要，v3 是为协议开发者设计的政策通道，普通交易继续用现行版本即可。

问：TRUC 是共识规则吗？ 答：是节点接受政策层面的规则，描述在 BIP431，改变的是标准性与中继判断而非区块有效性。

常见误区

一是把 v3 当成新交易格式上链后要全网迁移，它复用的仍是既有交易结构，只是策略分岔。二是把限制当成只享好处不设代价，TRUC 的宽松面（例如符合条件时可低于最低中继费率的父交易）正是以那套严格拓扑换来的，普通交易的政策照旧。三是把它与未来的包 relay 大协议混谈，TRUC 是当前已部署的最小可用契约，更大的包语义仍在继续演进。

风险提示：本文为交易机制科普，不构成投资建议；政策细节随客户端版本变化，请以当期发行说明与 BIP 文本为准。