给一笔比特币资金写多重解锁条件——要么三年后自己直接取回，要么和三位合伙人里的任意两位随时花——听起来只是多写几行脚本，真动手却发现所有分支都得原样搬上链，哪怕永远只走其中一条。MAST（Merkelized Abstract Syntax Tree，默克尔化抽象语法树）就是针对这种”条件冗余”提出的：把所有备选分支整理成一棵哈希树的叶子，链上只放一个默克尔根，花币时才揭示你实际兑现的那片叶子。本文按体积、隐私、计费三本账拆解它，再交代 BIP114 的结局与 Taproot 的继承关系。
裸脚本的三本亏账
把分支条件平铺进脚本，第一亏在体积。比特币脚本引擎给整条脚本设了一万字节的上限，单个数据或操作码元素不得超过五百二十字节，求值栈深度上限一千（三个常量都写死在 Core 源码 script.h：MAX_SCRIPT_SIZE 一万、MAX_SCRIPT_ELEMENT_SIZE 五百二十、MAX_STACK_SIZE 一千）。多分支脚本加上所有分支的签名，很容易逼近上限——还没等收费，脚本先被规则拒收。
第二亏在隐私。哪怕你三年后只走”到期自取”这条路，链上观察者也一并读到了另外两条分支里的合伙人公钥与时间锁参数。没兑现的条件替你公开了合作结构，分支越多、暴露越细。
第三亏在计费。签名哈希与验证成本按交易里的脚本字节计——闲置分支的字节也在收你的费，等于为一辈子不执行的代码长期买单价。
MAST 的解法：承诺一棵树，揭示一条路
MAST 的思路分三步。第一步，把每条解锁条件写成一片叶子：每片叶子自带一个小型内层脚本，声明”满足什么条件这片叶子才算数”，叶子各自做哈希。第二步，叶子两两配对归并哈希，长成一棵默克尔树；链上锁定输出只嵌一个归并根，外加一小段执行约定，分支的原始内容一个字节都不上链。第三步，花币时提交三样东西：选中的叶子脚本、从叶子到根的路径哈希、满足叶子条件的签名与参数。全节点做三次重算：沿路径归并回根、比对锁定输出里的承诺、逐片执行叶子。没选中的叶子不进交易、不计费、不公开；日后想给同一把锁加新分支，只要新旧叶子的根重新算好就行，链上的承诺形式不变。
BIP114 为什么关闭
2016 年 4 月，Johnson Lau 把 MAST 写成 BIP114（共识层软分叉提案），核心是新增一个分支验证原语：解锁数据先交脚本与哈希证明，验证通过后脚本自己再收签名，等于在脚本执行里嵌套一次脚本执行。提案最终状态是 Closed（已关闭），不是被证伪，而是社区在同期路线里选了别的路：几乎同期（2016 年 7 月），Graftroot 的构想出现在 bitcoin-dev 邮件列表，把”多分支”从脚本层挪到密钥层——给每个子集生成封装密钥、用签名聚合替代分支承诺；再往后就是 2021 年激活的 Taproot（BIP340 至 342），把”不揭示未用条件”做进密钥路径与脚本路径的二选一框架。嵌套执行原语的安全审查成本高、收益又能被这两条路分掉，BIP114 就此停在关闭货架上。
MAST 与 Taproot 的分野
两者共享同一个理想：只亮用上的路。差异在实现层。Taproot 的脚本路径承诺藏在输出密钥的聚合形式里，动用脚本路径时才揭示整棵叶表与所用分支；密钥路径（含 schnorr 多签聚合）则连脚本都不用出现。BIP114 式的脚本树原语从未部署，今天链上不存在对应的操作码。看文章或帖子提到”MAST 思路”时，先问一句：指脚本层树、密钥层聚合，还是 Taproot 叶表——三本账算出来完全不同。
一条直觉算术
给个量级感受：每条分支约四十字节、共八条分支，平铺方案约三百二十字节全量上链；MAST 化后链上先付三十二字节根，花币时揭示一条分支加三次哈希的路径（约九十六字节）。分支越多、真正常用的越稀疏，节省越接近”只走的路才付账”。这也是所有默克尔承诺类设计的共同卖点，从侧链跨链到提款凭证都在复用同一本账。
快速问答
问：MAST 现在能用吗？ 答：BIP114 已关闭、未部署；需要类似能力请走 Taproot 脚本路径，并确认钱包支持。
问：MAST 能隐藏金额吗？ 答：不能。它隐藏未用的解锁条件，金额与地址信息照常公开。
问：Graftroot 算 MAST 的变体吗？ 答：算同题不同解：同一批分支问题，Graftroot 用密钥封装与聚合解决，提案同样未部署。
风险提示：本文梳理提案历史与机制设计，不构成任何投资建议。多条件合约涉及资产锁定时，请先小额演练并核对当期规范。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。