协议演进 / BIP/比特币改进提案 / BIP-440
BIP-440
为脚本运行定一套按操作数长度计价的、按交易计算的预算，把 BIP-342 的签名操作预算推广到非签名操作，为恢复更强的脚本能力提供防滥用的成本框架。本 BIP 目前处于草案状态。
一、档案卡
| 编号 | BIP-440 |
|---|---|
| 标题 | Varops Budget For Script Runtime Constraint |
| 作者 | Rusty Russell <[email protected]>, Julian Moik <[email protected]> |
| 指定日期 | 2026-03-25 |
| 层级 | Consensus (soft fork)（共识（软分叉）） |
| 类型 | Specification（规范类） |
| 状态 | Draft（草案） |
| 阅读版 | https://bips.dev/440 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0440.mediawiki |
二、放在哪一族
脚本能力恢复（Great Script Restoration）一族的基础设施文档。它本身不恢复任何操作码，而是先给脚本运行定一套统一的成本账，后续提案才能在这套账之内放宽能力。
直接关系：
BIP-342：Tapscript 的签名操作预算（sigops budget），本 BIP 把这套思路推广到非签名操作
BIP-441：恢复已禁用脚本（Tapleaf 0xC2），明确依赖本 BIP 的预算来防止当年导致 CVE-2010-5137 的过度计算
原文定位很清楚：它是一个供其他 BIP 借用的框架（framework），文中给出的操作码示例，其限制都比现行规则更宽松，而不是更严。
三、它要解决什么
自比特币 v0.3.1 修复 CVE-2010-5137 以来，脚本能力被大幅收紧，目的是防止计算时间与内存占用过高带来的拒绝服务攻击。这些早期防护在当时是必要的。
但随着使用方式变复杂，限制开始碍事：新提案往往必须逐个交代性能风险——要么大幅缩小自己的适用范围，要么引入专门的缓存策略缓解执行成本，要么借用现有的签名操作预算，临时拼凑动态执行上限。每个提案各算各的账，既不系统，也不透明。
BIP-440 要做的，是一套简单、系统、显式的成本框架：按操作与栈数据的交互方式定价，以最坏情况为限。原文强调，即使用这种悲观假设，仍可通过静态分析证明大类脚本在所有可能输入下都不会超预算。
四、规则本身
4.1 预算怎么算
- 每笔交易有一个整数型的变操作数预算（varops budget）：交易总权重 × 固定系数 10,000。系数取 10,000，是为了让所有操作成本都能取整数。
- 预算按整笔交易计算，而不是按单个输入计算。理由是支持跨输入自省（cross-input introspection）：一个小输入，合理地访问较大的输入，不应被单输入预算卡死。
- 操作码执行时按其参数的长度（一般不是数值本身）消耗预算；一笔交易一旦超预算，验证即失败。
4.2 成本模型的前提
“varops”这个名字来自定价方式：除签名操作外，脚本操作的瓶颈主要取决于它处理多长的栈数据。模型的基本假设包括：
- 栈向量本身的操作（如 OP_DROP）成本忽略不计，OP_ROLL 例外；
- 内存分配与释放开销忽略不计；
- 脚本解释本身的成本不计，它已由区块大小限制兜底；
- 实现使用简单的线性连续内存数组、对栈数据做线性访问；
- 对象大小以整笔交易为上限（最坏 4,000,000 字节）；
- 每个操作码都按最坏情况定价。
原文也说明：正常使用中小而热的对象远快于模型估计；实现比模型更高效没有问题，只有最坏情况显著更差的实现才有问题。
4.3 六类成本
原文按基准测试把操作分成六类并定价：
- 签名操作：每次 500,000 单位（即 10,000 × 50），沿用 BIP-342 的签名成本——50 权重单位换一次签名，整块仍限制在 80,000 次签名以内；
- 哈希操作：每哈希 1 字节 50 单位；
- OP_ROLL：每移动一个栈元素另加 48 单位；
- 快速操作（比较字节、与零比较、清零）：每输出 1 字节 2 单位；
- 复制字节：每输出 1 字节 3 单位，略贵于快速操作，因为有内存分配开销；
- 算术操作：每输出 1 字节 6 单位；其余操作：每输出 1 字节 4 单位。
成本用基准测试校准：在 14 台覆盖 x86_64、ARM64 及 Linux、macOS、Windows 的机器上构造最昂贵的脚本实测，原文报告所有机器上启用这套预算后的最坏区块时间与现有规则之比都低于 1.0，即不引入新的最坏情况。推导时还区分脚本可见的字节长度（length）与按 64 位字对齐的长度（wordspan），不同公式按操作实际检查或写出的范围选用。
4.4 示例操作码
原文以几组现有操作码示范定价方法，例如 OP_EQUAL 长度不同时成本为 0、相同时按比较字节数计；OP_DUP、OP_2DUP 等按复制字节计；OP_SHA256、OP_HASH160、OP_HASH256 按哈希字节数计；OP_ROLL 除读操作数外，还要按移动的栈元素个数计费——它是唯一一个栈操作本身成本可变的操作码。
五、谁必须动
普通持币人：现在不必做任何事。本 BIP 仍是草案，未激活；它本身也不恢复任何操作码、不改变日常交易形式。
钱包开发者：现在不必动。若将来随相关提案激活，构造复杂脚本时需要按这套预算估算最坏成本，避免脚本在某些输入下超预算而失效。
全节点与矿工：若将来激活，验证时要为每笔交易累计变操作数成本，超预算的交易判为无效。这是收紧验证规则的软分叉式变更，未升级节点不会因此把旧规则下无效的区块误认有效。
共识层：本 BIP 定义的是约束框架。单独看它，文中示例操作码的定价都比现行规则宽松；真正放宽哪些能力，要看引用它的提案（如 BIP-441）如何落地。
六、现在算不算数，以及一个常见误读
状态为 Draft（草案）。它尚未部署、未激活：今天的主网验证既不计算变操作数预算，也不会因为超这套预算而拒绝交易。它的参考实现在原文中标注为进行中（Work in progress）。
常见误读：
“有了 BIP-440，被禁用的操作码就恢复了。”
不对。BIP-440 只定预算这本账，不启用任何新操作码。恢复操作码是 BIP-441 的事，而且 BIP-441 明确依赖本 BIP：先有能防过度计算的预算，才谈得上在预算之内把能力放回来。两份目前都是草案。
七、延伸
- 阅读版：https://bips.dev/440
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0440.mediawiki
- 相关：BIP-342 Tapscript 与签名操作预算、BIP-441 恢复已禁用脚本
- 仓库总目录：https://github.com/bitcoin/bips