字节数之外的第二种预算
比特币限制区块时，过去只看一个数字：总大小不超过一百万字节。但字节数是字节数，活儿是活儿——往一个区块里塞满需要椭圆曲线验签的交易，和塞满只需搬运数据的交易，节点验证时花的 CPU 时间差着量级。验签恰恰是所有验证步骤里最贵的一环。为了让制造验证负担的成本被显式计价，协议给每个区块加了第二本账：Sigops，签名操作计数。规则从一开始就存在：任何区块里被计数的签名验证操作总数超过两万次，这个块就不合法。这条线从早期版本就写进代码，目的朴素：给最坏情况的验签开销封顶。
隔离见证重记这本账
按 BIP141 的规定，隔离见证生效后 Sigops 规则做了两处调整。第一处是换算：旧脚本区域（非见证脚本）里的每个签名操作按 4 倍计数，同时把区块总预算抬高到八万成本单位。用意是记账单位与新的权重体系对齐——见证数据在权重账里按一字节一单位计，旧脚本数据按三加一的口径计，Sigops 跟着放大，新旧节点承担的验签负载才能放在同一把尺子上称。第二处是细则：P2WPKH（bc1q 那类地址）的每个输入无论含几把密钥，一律计 1 个 sigop；见证脚本里的 OP_CHECKSIG 计 1；OP_CHECKMULTISIG 的计数看写法——前面带 OP_1 到 OP_16 前缀时按实际公钥数计一到十六，裸写没有前缀则按最坏情况计 20。
一个多签例子
拿最常见的多签来算账。一个 OP_CHECKMULTISIG 的收多少，只看写法：前面带 OP_1 到 OP_16 前缀时按实际公钥数计，十五把钥匙计 15；裸写没有前缀，规范按最坏情况一律计 20。这条规则在旧式 P2SH 的 redeem script 和 P2WSH 的 witness script 里口径一致。再叠加 P2WPKH 每输入统一计 1 的细则，同样一套密钥结构，编码进不同的脚本与写法，被节点收取的验签预算差别不小——钱包选脚本模板时，Sigops 是它必须算的成本项之一。
它和区块权重的关系
现在回头看区块预算就清楚了：比特币给每个块配了两把卡尺。一把是权重（BIP141 定义区块权重不超过四百万），量的是数据搬运与传播负担；另一把就是本文的签名操作预算，量的是验签的 CPU 负担。一笔交易能否进块，取决于它在两把尺子下的综合表现。矿工打包时优先挑两者都划算的交易，普通用户感知到的差别，通常只是复杂多签或特殊脚本的交易在拥堵时段费率估算略高一筹。
费率之外的另一条拥挤信号
平时看内存池工具，费率高低是显性的，验签预算是隐性的。但在特殊时段，比如大量用户集中动用的季度结算日，链上同时刷出海量多签与批量支付交易时，即便费率不差，某些模板组合会先撞 sigops 预算线——这类交易的费率估算在拥堵时段跳得比同尺寸普通交易更厉害，是钱包费用算法里一条不起眼的修正项。理解它，你就能解释为什么同样字节数的两笔交易，有时报价差出一截。
快速问答
问：一笔普通 P2PKH 转账占多少 sigops？ 答：解锁脚本里一个 OP_CHECKSIG 计 1，几乎可以忽略。
问：这条预算线会调整吗？ 答：历史上随隔离见证做过四倍换算与上限放大，任何再调整都属于改变共识规则级别的决策。
问：用户需要设置什么参数吗？ 答：不需要，计数由节点自动完成，只影响交易的脚本选型与费用估算。
常见误区
一是把 sigops 当手续费单位，它衡量的是验证负担而非价格，两者通过矿工的打包选择间接相连。二是以为多签人数不受限，人数、脚本尺寸、sigops 三条约束要同时满足。三是把裸 CHECKMULTISIG 记成按实际密钥数计费，没有前缀修饰时规范一律按二十计，这正是引导大家写带前缀形态的原因。
风险提示：本文为协议机制科普，不构成任何投资建议；多签与脚本配置涉及资产安全，请以钱包官方文档为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。