写这份介绍的时候，我把一份候选条件全摊开的比特币脚本打印过一遍：一个多路径合约的全部逻辑能拉到几十行，而真实花费一次往往只走其中三五行。问题就出在这里——条件全摊开意味着每一条分支都写进了锁定的脚本里，分支越少还没什么，条件一多，链上空间、隐私和脚本体积上限全都在为“根本没用到的那些分支”付账。BIP-116 提议的 MERKLEBRANCHVERIFY（下面简称 MBV）就是冲着这个浪费来的。
先把它的处境交代清楚。MBV 由 Mark Friedenbach、Kalle Alm 和 BtcDrak 在 2017 年 8 月起草，状态至今是 Draft，从未上主网。它被安排去重新定义 NOP4 这个占位操作码——旧规则里 NOP4 什么都不做直接通过，这种“本来就没用”的位置正是软分叉启用新语义的经典落点。
它解决的具体问题是“承诺一篮子可能性，只揭示其中一个”。设想一个合约有一百条支出路径：要么 A 和 B 联名，要么等满半年由 C 单独花，诸如此类。传统写法是把一百条路径的脚本全部塞进 scriptPubKey 或 redeem script；MBV 的写法是先把一百条路径组织成一棵默克尔树，脚本里只写一个 32 字节的树根。真正花钱时，签名者把选中的那条路径连同它的包含性证明一起压进栈里，节点重算路径的哈希、沿树拼回树根，对上了才继续执行。没被选中的路径从头到尾不进链，既省空间，也不暴露“这个人本来还有哪几种花法”。
机制上，MBV 对栈的要求相当具体。执行到这条指令时，栈顶必须是一个不超过两字节的非负极小编码整数 N，第二项必须正好 32 字节、也就是默克尔根，第三项是一段按 BIP-98 格式序列化的包含性证明，里面恰好包含向下取整的 N 除以二 个 VERIFY 哈希。N 的最低位决定证明叶子的哈希口径：最低位为零时，其余各栈元素按双 SHA-256 现算哈希；最低位为一时，各元素本身就必须是 32 字节的已序列化哈希。BIP-98 里那对 VERIFY 操作码是 2017 年 3 月就随 SegWit 时代收尾软分叉激活过的现成工具，MBV 等于是给它配了一个“由脚本主动发起验证”的入口，而不只是交易级预设。
它和 MAST 类提案的关系值得单独说一段。同期还有一个 BIP-114 主张直接把 MAST（默克尔化脚本树）做进共识层：启用后你写一条新输出，节点自动把整棵分支树的根算进脚本。MAST 是“打包好的一整套方案”，MBV 加 BIP-117 尾调用则是“先给一块能验证分支的积木，合约布局交给上层拼装”，两条路线都停在 Draft，殊途同归于“少往链上写没走到的分支”。
常见误区有三个。一是把 MBV 当成已上线功能——在主流钱包里构造含 MBV 的输出，节点只会把它当 NOP4 放行，实际花费根本花不出去。二是以为省空间等于省费用，证明本身也要占见证和脚本空间，路径少的时候反而比摊开写更啰嗦，这笔账要用字节精确算。三是把 N 理解成栈里数据总条数，它描述的是这份证明覆盖的元素数量，和输入栈的元素对不上号时脚本直接失败。
快速问答。问：MBV 验证失败会怎样？答：整条脚本判定失败，交易被拒绝，不存在部分通过。问：为什么状态一直是 Draft？答：同期有功能重叠的 MAST 提案在竞争，社区对要不要为此付软分叉成本始终没有共识，资源也长期流向了别的扩容路线。问：普通用户需要关心吗？答：不需要更换任何操作习惯；它只是一段停留在文档里的脚本积木。
一条直觉线帮你记住这件事：MBV 就像保险柜的说明书写着“柜内有二十四格，取哪格自己挑”，但你开柜时只把手伸进那一格——其余二十三格的内容，全世界都不用知道。这个比喻的局限也要讲明白：真实脚本里树根必须提前锁死，事后一格都改不了，这和可自由更换内容的保险柜完全不同。
风险提示：本文讨论的是停留在提案阶段的脚本机制，不构成对任何资产、协议或投资标的的推荐；涉及具体钱包与交易操作时请以官方文档为准，注意区分主网已激活规则与提案文本。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。