交易被 BUSY 拒绝之后：Hedera 限速体系的网络桶与节点桶

拥堵不用价格战来解

多数 EVM 链的拥堵逻辑是拍卖：谁的小费高谁先进块，慢交易靠等待。Hedera 走了另一条路——每种操作配一个固定速率闸门，容量不够时直接拒绝，收费表与拥堵程度脱钩。这个体系叫 throttle（节流器），官方博客把它的设计目标写得很直白：在保持网络稳定的同时，让所有用户不因出价高低失去被服务的机会。理解它，才能理解为什么在 Hedera 上会看到一笔“签名有效、余额充足”的交易返回 BUSY，以及为什么账户创建这类操作的可用速率远低于转账。

漏桶：桶、组与两个层级

官方的心智模型是一个底部漏水的桶：桶的容量代表可攒的突发额度，漏水速度代表稳态速率。配置放在 Hedera Services 仓库的 throttles.json 里，速率用 opsPerSec 或更细粒度的 milliOpsPerSec（除以一千）表达。一个桶可以挂多个节流组，每组给一批操作名单定自己的速率——桶是总水池，组是池内的分账本。一个操作可以同时关联多个桶，只有所有相关桶都有余量才被放行，任何一个满了就整体拒绝，这就是多桶配置防“单一业务吃光资源”的用途。

关键一层是网络与节点的双重记账：throttles.json 里写的是全网速率；单个节点的额度等于网络速率除以活跃节点数。节点本地按这份配额放行或回 BUSY，全局因此近似受控。另一层补救是突发窗口（burst period）：允许节点在若干秒内用掉多秒的额度，只要时间平均不超速——对每节点每秒不足一笔的低速桶尤其必要，否则流量抖动会让这类操作长期饿死。被拒的客户端会收到状态码 BUSY，官方语义是“稍后重试”。

EVM 的两道 gas 闸

合约操作不吃“每秒笔数”这一套，Hedera 为其单列两道按 gas 每秒计的闸。第一道是前端节流器，管节点每秒愿意接收多少 gas 的入站 gRPC 交易，超了当场回 BUSY；第二道是共识节流器，管一个共识周期里真正执行多少 gas，作用相当于以太坊的区块 gas 上限，超了的交易拿到的状态码是 CONSENSUS_GAS_EXHAUSTED。两者的上限不在 throttles.json，而是写在全局动态参数里，由 0.0.121 号系统文件的配置项 contracts.frontendThrottleMaxGasLimit 与 contracts.consensusThrottleMaxGasLimit 控制——调参走治理流程，不需要发版。合约交易同时也仍可能落入普通操作组管辖的 opsPerSec 桶，两套闸各自独立生效。

一张参数表与它的时效

主网文档公开了各操作的节流值，几个常被引用的例子：转账类交易每秒一万笔，账户创建只有每秒两笔，主题创建每秒五笔，合约执行与创建各按每秒一千五百万 gas 计，查询类则按“每节点每秒”计。这类数字是治理决定的运营参数，官方保留随时调整的空间，引用时以主网文档页面当时的版本为准，本文不为任何数值担保“现在仍然如此”。另外，面向高吞吐建实体（批量开户、大额铸造）的并行高速节流系统是较新的 HIP 提案方向，是否已启用、阈值多少，同样以官方文档现状为准。

设计代价与核对清单

这套体系的取舍可以逐项看。得到的是可预算性：费率表固定、被拒就是被拒，不存在 gas 价格战和“同一笔合约费忽高忽低”；节点容量随网络扩容线性摊薄。代价也有三处：低速率桶（如每秒两笔的建账户）遇到铸造日会形成长队；BUSY 只说明闸门满，不指示排队位置，重试策略要客户端自造；查询配额按节点计，换节点连接等于换水池，单点连接看到的“限流”未必是全网真相。对开发者的落地清单是：把 BUSY 与 CONSENSUS_GAS_EXHAUSTED 分开处理，前者退避重试、后者拆小合约调用或降低并发 gas 预算，并按主网文档为每类操作预配速率假设，而不是照搬 EVM 链的 gas 估算习惯。本文只做机制解释，不构成任何投资建议。