祖先限额退休、簇限额上岗：v31 内存池四个参数的交接账

比特币核心 v31 把内存池重写成了”集群内存池”，随之发生的不只是内核数据结构的变化，还有一整套老限流参数的退休与新旋钮的上岗。发布说明用一整段讲述了这场换防，但真正把配置文件里哪些行该删、哪些警告要当回事说清楚的，是源码本身。本文按 v31.0 源码逐个盘点这批参数的现状。

新闸门：簇的笔数与体积

新设计里，内存池不再以”祖先链/后代链”为限流单位，而是以”簇”——同一内存池里通过任意父子关系直接或间接相连的一组交易算一个连通分量。v31.0 源码 src/policy/policy.h 给出两把默认锁：每簇最多 64 笔交易、整簇虚拟体积最多 101 千虚拟字节，对应命令行参数 -limitclustercount 与 -limitclustersize。

这里有一个容易被忽略的细节：-limitclustercount 的上限就是 64。源码 src/txgraph.h 把最大允许值定义为常量 64，与默认值相同——也就是说这个旋钮只允许你拧紧，不允许拧松。想给资金依赖链腾更大空间，改参数没有出路，只能换交易结构设计（TRUC 交易与同辈驱逐机制就是为此保留的官方通道）。

旧参数的三种下场

第一类是”降级留用”：-limitancestorcount 与 -limitdescendantcount（默认各 25）在帮助文本里被明确标注为已弃用——内存池接纳交易时不再执行祖先数、后代数考核，但钱包选币环节仍然按这两个数字避开过深的依赖链。换句话说，它们从共识政策参数变成了钱包行为参数。

第二类是”名存实亡”：-limitancestorsize 与 -limitdescendantsize 在 v31 里被登记为隐藏参数，帮助页查不到说明；更关键的是，如果你在配置文件里还留着它们，节点启动时不会沉默——会输出一条初始化警告，大意是”该参数已给出但体积限额已被簇体积限额取代，此选项无效果”。升级后翻一眼启动日志，就能确认自己的配置有没有踩到这颗哑弹。

第三类是”彻底退场”：曾经给小额子交易开后门的 CPFP carve-out（在后代限额已满时，允许再多收一个仅有一个父交易、不超过 10 千虚拟字节的子交易）随集群重写被移除，发布说明直言不再有任何交易能绕过簇限额。

换防之后，行为上能感知到什么

发布说明列出的连锁改动包括：交易按”预期能被一起打包的费率”排序，这套排序同时服务于块模板构造、内存池满时的驱逐和向邻居宣告；替换交易只有在让整池费率图”严格变好”时才被接受，对孤立交易则只要求费与费率双高；getmempoolentry 的输出里新增了分块体积与费用；配套还上了 getmempoolcluster 与 getmempoolfeeratediagram 两个新查询命令。这些都不需要改参数，属于免费的行为升级。

升级检查清单

动手之前按序核对：配置文件里是否残留四个老限额参数——size 类的会触发无效果警告，count 类的要明白它们只影响钱包；是否原本靠 CPFP carve-out 支撑的子交易加速流程，现在会被簇限额硬顶住；有没有脚本在解析这些 RPC 输出或参数行为，需要按 v31 语义重测。所有调整动作都建议在测试网先走一遍。

新闸门之前，先看清交易图的形状

对普通单父单子的日常转账，簇限额几乎不可见；它改变的是依赖图比较密的用例。同一连通分量里的交易不分方向地合并记账：一条加费链、一组并列的兄弟交易、一段嵌套的批量付款，只要两两之间存在父子边，就整体受六十四笔与 101 千虚拟字节的约束。动手设计之前，建议把交易依赖图先画出来，按整簇估算笔数与体积，而不是只盯单笔的祖先包。

风险提示：本文讨论内存池政策参数与节点软件行为，不构成投资建议；所述默认值与参数语义以比特币核心 v31.0 源码及发布说明为准，后续版本可能继续调整。