v31.0 把比特币核心的内存池换成了新架构（集群内存池），顺手留下两个新面孔：一条叫 getmempoolfeeratediagram 的新 RPC，和一条写进替换规则的新条款——“替换交易必须严格改善内存池的费率阶梯图”。这两样东西背后是同一个图形化概念：feerate diagram，费率阶梯图。它不是给矿工看的新仪表盘，而是这次大改版用来统一”排序、驱逐、替换判断”三件事的那把尺子。这篇把这把尺子本身讲清楚：图怎么画、RPC 怎么读、规则怎么用。
先画这张图。把内存池里所有交易按”预期会被一起打包”的分组（chunk，一笔独立交易是一个 chunk，父交易和带依赖的子交易组合也是一个 chunk）排成一个序列，从序列头部开始一路累加：横轴走到某个点，代表累计打包了前若干 weight（按 sigop 折算调整过的权重）；纵轴是对应的累计手续费。把这些累加点连成阶梯线，就是内存池的费率阶梯图。直觉读法：曲线越”陡”，说明每多占一块区块空间能多收多少手续费；图整体在另一张图上方（且不相交），就说明一个池子比另一个池子在每一个区块长度上都收得更多费。两张图一旦交叉，就不能说谁全面更好。
在这个表示下，v31 的三件老事获得了同一个判据。第一件是打包排序：块模板不再按单笔费率从高到低贪心，而是沿着整条阶梯最优地取 chunk，父带子的组合费率被一次性正确计入——这正是旧模型里”祖先费率 vs 子孙费率”反复拉扯的根源。第二件是满载驱逐：从阶梯底部开始丢 chunk，被丢掉的永远是”继续打包最不值钱”的那组。第三件是这次真正的新规则：一笔 RBF 替换要成功，条件是替换后的内存池阶梯图严格不差于替换前、且至少有一处更好（政策文档 mempool-replacements.md 第 6 条，v31.0 起与集群内存池同步启用）。它堵住的漏洞是：旧规则下，替换交易可能让池子里的费率曲线在某个区块长度上更低——比如把一笔高费交易换成两笔低费依赖交易，矿到特定长度时反而少收钱。这种”对矿工更亏的替换”在 v31 起被系统性地拒绝了。官方文档的表述是：替换后未来每个区块的费用都会上升（忽略区块尾部的边缘效应）。
getmempoolfeeratediagram 就是这张图的机器可读版。按 v31.0 源码 rpc/mempool.cpp 的定义，它没有参数，返回一个 chunk 数组，每个元素两个字段：weight 是到该 chunk 为止的累计 sigop 调整权重，fee 是对应的累计手续费。也就是说，返回值本身就是阶梯的拐点序列——按 weight 排序后相邻两点连线的斜率，就是那一段的边际费率。拿它做什么？对比两个时点或两个节点的图，可以量化”这次替换到底改善了没有”；给自己的打包器做基准测试，可以直接拿官方实现的阶梯当参考实现；排查自家节点与网络费差分布差异时，两条阶梯叠在一张图里一眼见高低。
几个使用提醒。第一，这个返回是整池快照，在大型拥堵时段数组会很长，做轮询监控要控制频率——它计算并不廉价。第二，阶梯图依赖 chunk 分组，而 chunk 由依赖关系决定：你自己发的交易若和别人的子交易形成依赖，会被并进同一个 chunk，图上的位置由组合费率决定，不由你单笔的报价决定。第三，chunk 排序里有一个隐藏知识点：文档把”对某段区块长度做最优打包”表述为在给定 weight 预算下沿阶梯的走法，两个节点即使内存池内容相同，若打包器没有沿阶梯取 chunk（比如还停留在逐笔贪心的老思路），产出的块费也会有系统性差距——这正是 v31 用图统一排序后，矿工侧建块代码值得对照复核的地方。第四，版本边界要划死：这条严格改善规则和这条 RPC 都自 v31.0 起存在，v30 及更早版本既不会用这个判据拒绝替换，也没有这条 RPC；跨版本写运维脚本时要先探测再依赖。
风险提示：内存池政策影响交易何时被中继与打包，理解它有助于选费与排障，但任何费率策略都不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。