脚本的四道天花板：共识硬上限与政策标准线各管什么

一笔脚本交易要闯两层门

比特币脚本不是想写多大就多大。限制分两层：第一层是共识规则，写在协议实现里，全球每个验证节点无条件执行，越线即无效块、无效交易；第二层是政策规则（标准性），决定节点”愿不愿意”中继和打包一笔合法但奇怪的脚本，各实现默认值可以不同，也能用配置开关改变。很多”交易广播不出去”的困惑，根源就是把两层门混为一谈。

共识层的四个数字

锁定的脚本本身不超过一万字节：超过这个长度的脚本直接不可能被花（协议规定长度超过上限的输出一律视为不可花费），常量是比特币核心源码里的 MAX_SCRIPT_SIZE。单个脚本里的非推送操作码不超过 201 个，防止验证耗时失控；执行栈深度不超过 1000 项；被压进栈的单个数据元素不超过 520 字节——签名、公钥、哈希都受这条约束。还有一条作用于整个区块：全块的签名操作成本不超过 80000，多签和复杂脚本按计价单位分摊这块公共预算。这些数字在比特币核心源码的脚本头文件与共识头文件里可逐一核对，多年未变。

政策层把线画得更低

合法不等于受欢迎。默认的比特币核心只中继它认为”标准”的脚本：标准交易的总权重不超过 400000（约十万虚拟字节）；作为标准脚本被对待的 P2WSH 兑现脚本上限是 3600 字节，低于共识的一万；解锁脚本区的标准长度上限 1650 字节；裸多签、未来版本的见证程序、超大的数据推送，默认都会被政策挡在内存池外。政策存在的意义是防御：一笔合法但笨重的脚本，可以让全网白白浪费验证资源，用”标准性”提前过滤比等共识层受伤再补救便宜得多。

谁来执法，怎么区分两类失败

两类失败的现场截然不同。共识性无效的交易，节点对广播者记惩罚分并断连，交易在任何节点都进不了块；政策拒绝的交易，节点只是安静地不收，同一笔交易在放宽政策的节点（例如以政策严格著称的 Bitcoin Knots 的某些默认组合）那里可能畅通无阻。所以排查时第一步是判断”这台节点拒收”还是”全网拒收”：后者要修脚本，前者往往只需要调对端设置或找政策不同的中继伙伴。

什么时候会撞到天花板

最典型的是大型多签与脚本路径的 Taproot：二十路公钥的 multisig 解锁体积逼近签名操作预算，2-of-15 已经能明显看到手续费台阶上升。其次是数据载荷类交易：写入区块的字节都要按权重计费，共识没有”数据脚本”豁免，只有针对小额数据输出的中继政策。再者是自动化脚本工具：生成的脚本如果包含非规范编码或冗余包装，可能在共识层合法、政策层碰壁。设计花费策略时的正确顺序是：先用共识上限验证可行性，再用标准性检查可广播性，最后用权重换手续费——三层账都算清，交易才真正可部署。

把天花板当预算表用

更实用的读法是把四道上限当作设计预算而非障碍清单。想搭一个 n-of-m 多签：每个公钥约三十三字节，签名约七十多字节，套上二十一条非推送操作码和一万个字节的脚本体积限制，可以算出 m 大约能开到十几路仍留有余量，但每加一路，解锁时提交的签名条数、脚本长度与签名操作成本三线同涨，手续费按最贵的那条线收费。想给 Taproot 的脚本路径做多分支：单路径脚本再自由，整段承诺脚本也要计入脚本树开销，分支数量实际受签名字节与栈深度的联合约束。写自动化工具时最省事的防御是：生成脚本后立即执行与节点相同的两项自检——共识尺寸检查与标准性检查，任何一项报警就回到设计阶段减分支或换结构（如用聚合签名替代明文多签），而不是指望某个宽松节点的施舍。天花板一直在，变化只发生在你的结构能不能在预算内把故事讲完。