先固定观测对象是哪一类接口
讨论区块链交易确认延迟时，先要标明样本来自哪一类节点视图。Bitcoin Core 28.0文档里的getmempoolinfo返回的是当前交易内存池的活动状态，字段包括已加载标记、交易笔数、按BIP141定义的虚拟大小合计、内存占用、手续费合计、容量上限以及接受交易的最低费率等。它描述的是某一时刻本节点队列里还在等待的对象，不是已经写入某个高度的结果。
同版getblockstats则按指定区块哈希或高度计算该块窗口内的统计量，金额以聪计，并可在裁剪节点上对部分高度失效。返回里可见平均/中位/分位费率、交易数、总手续费、块时间等。它回答的是“这个已经出现的区块里发生了什么”，与内存池瞬时快照不是同一张表。
队列字段不能直接当成确认耗时
若只记录getmempoolinfo的size或bytes变大，只能说明该节点当前积压的交易笔数或虚拟大小合计上升。文档没有把这些字段定义为“平均还要等多久才会确认”。最低费率字段反映的是进入该内存池的门槛，它由最小中继费与内存池限制费率等因素共同决定，同样不是对未来若干块确认概率的官方预测。
设一个完全虚构的对照：某次观察size为一千、bytes为两百万，稍后某高度getblockstats显示txs为两千。这两个数字不能相减得到“延迟秒数”，因为前者是未确认队列快照，后者是已确认块内统计，采样时刻、节点集合与交易集合都可能不同。例子只用于分清字段职责，不是实测网络数据。
入块结果要带着高度与时间一起存
整理确认相关资料时，对getblockstats应同时保留目标高度或块哈希、查询时点，以及选用的统计项。文档提醒该接口在部分裁剪高度上不可用，因此缺值本身也可能是节点存储范围问题，而不是网络“变慢”的证据。块时间与中位时间字段属于该块记录，不能外推为任意交易从广播到确认的通用耗时公式。
若需要比较费率与入块关系，应把内存池侧的费率门槛、块内费率分位和块高度写成并列记录，而不是先合成一个未定义的“延迟指数”。本文没有连接真实节点，也没有执行RPC或宣称某一时刻的全网拥塞等级。
队列结构讨论不等于当前默认实现
Bitcoin Optech对集群内存池（cluster mempool）的专题说明，讨论的是如何把未确认交易按关联关系组成集群，并在集群内形成按费率排序的分块，以便更好地推断“若本地区块模板与本地内存池一致，矿工可能如何选交易”。它明确这是一项设计与实现推进中的方案，用来解释为何仅看整池总量或单一祖先费率近似，不足以完整描述驱逐与出块选择的对应关系。
因此，阅读确认延迟材料时，可以把Optech文本当作理解“队列组织影响选择顺序”的第二组资料，但不能把提案中的集群/分块分数写成Bitcoin Core 28.0 getmempoolinfo已经返回的字段。归档时应分开标注：Core固定版RPC字段、采样时点，以及Optech专题的方案边界。配图中的流水线与计时装置只表示分阶段取样的概念，不代表实际测量仪表。