getmempoolcluster怎么读？

Bitcoin Core 31 的 getmempoolcluster 会按交易依赖组成交易簇，并给出按挖矿顺序排列的 chunk。本文拆解chunkfee、chunkweight、sigops调整权重与实时快照边界。

getmempoolcluster 不是“下一块交易名单”。它从本节点当前内存池中找出与目标交易存在祖先或后代关系的一组交易，再把这组关系整理成可按收益比较的 chunk。读它的关键是分清交易簇、chunk、调整权重和最终区块四个层次。

一张返回树先看层级

getmempoolcluster接收一个当前内存池交易txid，并返回该交易所在簇的数据。输入目标 txid 后，响应描述的是该交易所在的依赖簇。父交易尚未确认、子交易依赖父输出时，它们不能被当成完全独立的费率点。相互依赖的交易可能组成一个 cluster，cluster 又被切成若干 chunk。

目标交易
  └─ cluster：所有相关祖先与后代
       ├─ chunk 1：按当前算法优先考虑的一组交易
       ├─ chunk 2：剩余交易中的下一组
       └─ txs：chunk内按挖矿顺序排列的txid

API读取前要保存节点版本、链、查询时刻、目标txid和完整原始响应。不同节点的内存池策略与收到交易的顺序不同，即使在同一分钟查询也可能得到不同交易簇。

chunk比较值如何复算

返回对象包含clusterweight、txcount和按挖矿顺序排列的chunks。接口返回的每个 chunk 包含 chunkfee、chunkweight 和 txs。每个 chunk 的比较不能只看其中某笔交易；若页面自行计算费用密度，必须直接使用这一组聚合字段，并在单位栏说明费用单位与weight单位。一个不改变单位的基础比较式是：

chunk_fee_density = chunkfee / chunkweight

它只是便于同口径比较的费用密度，不应在未完成单位换算时直接标成 sat/vB。若要展示常用费率单位，必须注明 chunkfee 的原始单位，并明确从调整后weight到虚拟字节的换算步骤；不能把 chunkweight、BIP141原始weight和vsize混列。

层次	应保存的值	最常见误读
transaction	txs数组里的txid与顺序	RPC直接返回单笔费用明细
cluster	clusterweight、txcount	等于矿工必选集合
chunk	chunkfee、chunkweight、txs	可任意拆开比较
snapshot	节点、版本、时间	对全网永久有效

sigops为什么会改变有效大小

每个chunk包含chunkfee、chunkweight和按挖矿顺序排列的txs；权重是按BIP141并结合-bytespersigop调整后的权重。区块空间不只受字节或weight限制，签名操作也有资源约束。该RPC直接给出的 clusterweight 与 chunkweight 已是结合 -bytespersigop 调整后的权重；因此两个原始字节大小相近的交易集合，若签名验证开销不同，用于排序比较的权重也可能不同。接口没有同时返回每笔交易的原始weight与vsize，若页面需要这些字段，应通过其他节点接口另行取得并标明来源。

用依赖图而不是排行榜解释顺序

假设父交易 A 费率低、子交易 B 费率高，B 不能脱离 A 单独进入区块。算法可能把 A+B 作为一个高于 A 单独费率的包考虑。若另一个独立交易 C 费率介于两者之间，简单按单笔费率排序会给出错误顺序。

复核步骤可以固定为：

保存 clusterweight、txcount 和全部 chunks，先核对txid总数。
按响应给出的 chunk 顺序列出成员，不先按单笔费率重排。
用 chunkfee 与 chunkweight 复算同口径费用密度。
若要画父子依赖图，再用 getmempoolentry 等接口补取依赖，不假装本响应已经给出边。
隔一段时间重查，记录新增、替换、确认或移除造成的变化。

Bitcoin Core 31发布说明称内存池采用cluster mempool设计，簇由父子交易连接形成，并把簇限制为最多64笔交易。 64笔上限是cluster mempool的设计约束，不是“每个区块只选64笔交易”。getmempoolcluster 提供的是节点当前策略视图，不是矿工模板承诺；新区块、RBF替换、新交易到达、节点重启或策略差异都会改变结果。