比特币核心 v31.0 把内存池换成了簇（cluster）设计：过去那套”祖先不超过 25 条、后代不超过 2 万 kvB”的线性限额退场，取而代之的是两条围绕”连通分量”的新闸门——-limitclustercount 与 -limitclustersize。本文按 v31.0 源码把这两个参数与它们的三个前任逐项拆开。
新旧分工
发布说明（v31.0 doc/release-notes.md）说得很直接：内存池不再执行祖先/后代体积与条数限制，改为两个默认策略限额管辖内存池中经由父子关系直接或间接相连的交易集合，即簇；簇被限制在 64 条交易以内、虚拟体积不超过 101 kB。
源码里四个参数的现状分三档。第一档是现役：-limitclustercount=<n> 的帮助文本写着”不要接受与 <n> 条及以上其他未确认交易直接或间接相连的交易（默认 64，最大 64）“——默认值 DEFAULT_CLUSTER_LIMIT 在 src/policy/policy.h 里定义为 64，上限 MAX_CLUSTER_COUNT_LIMIT 同为 64，写在 src/txgraph.h。-limitclustersize=<n> 管辖”交易连同其全部内存池内连通交易的虚拟体积”，默认 DEFAULT_CLUSTER_SIZE_LIMIT_KVB 为 101（单位千虚拟字节）。这两个都是 DEBUG_ONLY 类别的参数，藏在 -help-debug 输出里。
第二档是半退休：-limitancestorcount 与 -limitdescendantcount 的帮助文本被改写成 “Deprecated setting … replaced by cluster limits (see -limitclustercount) and only used by wallet for coin selection”。也就是说节点收包层面它们已经不说话，但钱包找币算法仍用它们限定可接受的依赖链深度——把这两个参数当纯摆设删掉，会悄悄改变钱包选 UTXO 的行为。
第三档是彻底空转：-limitancestorsize 与 -limitdescendantsize 在 src/init.cpp 里只触发一条启动警告——“该选项无效，祖先/后代体积限制已被簇体积限制取代”，除此之外什么都不做。老配置文件里留着它们，等于每次启动多打一行日志。
为什么限额形状变了
旧规则沿”父→子”的链形思考，但真实流量里更多是”一笔父交易带多个子”的树形与网状结构，链式限额对这类包既松又紧：松在攻击者可以用宽扇出入库存量，紧在合法的多子结构（比如多个独立加急子交易）互相挤占额度。簇限额直接对”连通分量”总量设闸，把整张网当成一个记账单元。v31.0 发布说明里同一节还记录了两个连带变化：CPFP carve-out（给包内额外留一个小子的额度）随旧限额一起删除，预期这类需求改用 TRUC 交易与兄弟驱逐机制；内存池排序改为按”整簇被挖出所需费率”组织，选块、驱逐、中继都看同一份费率阶梯。
调参的实际后果
这两条参数都是节点本地策略，改了不影响你与全网共识的兼容性，但影响你对等端的体验：把 -limitclustercount 调到 1 意味着拒绝任何带依赖的未确认交易进入本节点内存池，CPFP 加急与闪电锚定包的费率会经不到你这条路；调大簇上限则增加内存池被复杂包结构塞满的攻击面，且注意上限硬编码在 64，命令行传更大的值会被拒绝。-limitclustersize 抬高到远超默认值时，同样体积下你能容纳更多低费率依赖链，代价是驱逐计算更重。对绝大多数部署，动这两个参数的正当理由只有一个：你跑的协议软件确实构造超出默认簇形态的交易包，且你清楚自己在中继什么。
怎么确认你的节点现在的取值
簇参数不进常规帮助输出，最快的核对方式是用 -help-debug 搜 limitcluster 两行；运行中想看效果，getmempoolentry 在 v31.0 起会附带每笔交易所在簇的分块（chunk）体积与费用，getmempoolcluster 则直接返回某笔交易所在簇的成员、排序与分块分组——两个命令都是本次簇改造新增的观测面。把前者当体检单、后者当放大镜，比翻日志猜簇结构可靠得多。改参数前后各取一次同一个高依赖时段的采样，就能直观看到限额松紧如何改变内存池的簇分布。
风险提示：本文为节点策略机制说明，参数改动请先在测试网观察；本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。