比特币脚本设计里有一对宿敌：省到什么程度，和藏住多少东西。MAST 谱系的答案是把多个备选条件种进一棵默克尔树，花币时只暴露走通的那一条枝。2018 年 2 月，Gregory Maxwell 在 bitcoin-dev 抛出 Graftroot，主张同一问题的另一解：备选条件不该是预埋的脚本分支，而该是随时可以追加的授权委托。它建立在同一前提上——先有 taproot 式的承诺（存在一组公钥，其授权可作为任何复杂条件的替代），再在其上做文章。
代理脚本怎么委托花币权
起点与 Taproot 相同：一群有权花这笔钱的人先聚合出一把阈值密钥，可以附带一个 taproot 式的脚本备选。Graftroot 的新零件叫 surrogate script（代理脚本）：任何时刻，掌钥者可以拿这把聚合密钥对一个替代脚本单独签名——注意只签脚本本身，不针对任何交易——再把”脚本加签名”分享给任何人。日后真要走代理路径时，出示代理脚本与那份委托签名，并用 Schnorr 的非交互聚合技巧把各份 S 值并成交易总签名的一部分，公开部分每份 graft 只需约一个三十二字节的 R 值——与 taproot 单签同量级。作者还指出这个聚合有副作用之利：公开出来的 R 值把这份 graft 绑定到了特定交易，能挡掉一部分复用事故。结果分两种：掌钥者配合时按普通单签上链，链上看不出任何多人结构的存在；不配合或不可达时，代价也只是约三十二字节加脚本本身，而且事后那份委托签名反过来证明脚本确曾被全体授权。Maxwell 原文的卖点正落在这里：授权可以事后、链下、向任何人追加，不需要新交易，也不需要在链上预埋任何结构。
为什么落选的是它
Optech 的 2018 年度综述把那一年的创意排成一串，Graftroot 在列；随后几年的主网演进给出的却是另一条线——2021 年激活的 Taproot（BIP341 与配套的两个 BIP）采用默克尔化的脚本树路线。原因可以从工程面复盘，而不必假定概念有错：Graftroot 的委托模型要求各方长期保管”别人脚本的委托签名”，密钥轮换、脚本变更时全体重签的协调成本在多方场景里相当繁琐；它难以在不改动聚合结构的前提下回答”现在到底有哪些合法支出路径”这一审计问题，因为路径可以随时被追加；而 Taproot 把支出策略一次性锁进承诺哈希，钱包、多签服务、链下协议这些成熟生态更容易对齐与验证。同期围绕 Graftroot 是否应设为可选、是否与后续升级冲突的讨论持续了多年，连 Eltoo 一类链下协议的设计讨论里也能看到它被拿来对照，最终这一票投给了可审计性与生态适配。
它留下的方法论
Graftroot 从未部署，读它不等于主网具备它，这条边界必须先划清。但它的方法论比实现更长寿：用密钥聚合与签名委托在链下组合支出策略，是 MuSig 一类多方签名与”脚本即承诺”方案共同的思想母题；而”协作时零额外开销、对抗时只多几十字节”这个差值，至今仍是评估任何脚本改进的实用标尺——同样一个多签结构，走这条路在链上看起来和单人转账没有区别，走另一条会留下明显的脚本痕迹。另外值得记住的是它与隐私的关系：Graftroot 省的是结构与数据，真正的路径隐藏仍要依赖 Schnorr 签名与 taproot 承诺这套底层，单靠构造本身造不出隐私。对想理解”为什么比特币多签长这样”的读者，这类落选提案是极好的对照读物：它们记录了同一约束下的另一组取舍，也解释了现行方案为何不是唯一解。本文只讨论密码学机制，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。