Cluster mempool

相互花费的未确认交易构成一张依赖关系图，多年来，软件只能通过粗略的上限来处理它，即限制单个条目可以有多少祖先交易和后代交易。版本31.0用一条规则取代了这些上限：任何相互关联的交易组，交易数不得超过64笔，虚拟大小不得超过101 kB。由此，手续费提升和交易替换都变得更可预测。

运作方式

簇（cluster）是内存池中的一个连通分量。任取一笔未确认交易，沿父交易和子交易的链接向两个方向追溯，所有能到达的交易都属于同一个簇。

旧设计分别追踪祖先交易和后代交易，各自的上限为25，另有一个大小上限。这种做法计算成本低，但在一个重要方面是错误的：它只告诉节点一组关联交易有多大，却没有告诉节点理性矿工会按什么顺序选取这些交易，因此内存池无法回答自己的核心问题：如果现在必须构建一个区块，哪些交易会被放进去？

Cluster mempool 通过让每个簇始终保持线性化来回答这个问题。线性化是一个被划分为若干块的排序，每一块是一组会被一起挖出的交易，并共享同一个有效费率。对这些块排序后，便得到整个内存池的费率图，现在各项决策都以这张图为衡量标准。

每个簇的上限是64笔交易和101 kB 的虚拟大小，它们完全取代了祖先交易和后代交易的数量限制。CPFP 例外（过去允许多出一笔子交易越过后代交易上限的一项例外）也随之被删除，因为任何交易都不得绕过簇的数量限制。

好处体现在交易替换上。旧的 replace-by-fee 规则是拼凑在一起的若干条件，可能被人利用：在共享交易上附加廉价的垃圾交易，使替换它的成本高得离谱。比较费率图则只需一项检验：如果替换后的费率图在任何位置都不比原来差，并且在某些位置更好，该替换就会被接受。两个新的 RPC 暴露了这一机制：getmempoolcluster 用于查看簇的内容和排序，getmempoolfeeratediagram 用于获取费率图本身。

在哪里会遇到它

Cluster mempool 会以两种形式出现：一是当您串联了过多未确认的花费时出现的错误信息，二是在您预期会遇到麻烦的地方成功完成的手续费提升。

钱包用户会在一种常见情形下遇到这一限制：在繁忙时段反复花费未确认的找零。这个上限对个人而言绰绰有余，对批量支付的服务而言则较紧，这个数字大致就是为后者设定的。当钱包拒绝一笔花费并提到簇时，解决办法是等待一次确认，而不是提高手续费。

另一个不那么显眼的好处是，子交易为父交易付费（CPFP）现在名副其实。以较高费率花费一笔卡住的交易的输出来提升其手续费，节点可以立即判断这一对交易是否胜过队列中已有的交易，因此您一步就能得到明确的答案，而不是一个近似结果。

Cluster mempool vs 内存池

内存池是节点所持有的交易集合；cluster mempool 是一个程序在内部组织这一集合的方式。没有任何共识规则发生变化，也没有发生分叉，仍在运行旧版本的节点持有的是相同的交易，只是记账方式较差。这一区别很重要，因为这一变化有时被报道成仿佛比特币新增了一条关于交易链的全网规则。事实并非如此。这属于策略层面，由各节点自行选择，任何运营者都可以通过命令行参数在自己的机器上调整这些限制。