先把交易池与正式区块分开
交易池常被写作mempool或transaction pool，它保存的是节点当前掌握、尚待处理的一组交易。比特币开发文档用候选入块的未确认交易说明它的作用；以太坊网络文档也明确使用“本地交易池”的概念。这里的本地很重要：不是全网只有一份统一清单。
区块则把选中的交易放进有顺序的记录，由接收区块的节点继续验证。留在池中的请求与进入区块的交易处在不同阶段。钱包显示已经广播，只能说明发送流程达到某一步，不能据此把它写成已确认。
传播是节点之间交换信息，不是同步数据库提交
比特币的点对点说明描述了先告知交易标识、再按请求发送交易数据的传播过程。以太坊执行客户端也会在执行层网络中传播待处理交易。这类消息要经过连接、传输和本地处理，不会像修改同一张数据库表那样瞬间出现在每个观察点。
设想观察节点甲刚收到交易，而节点乙还没有获得它：甲的页面能查到，乙的页面暂时查不到，这本身并不矛盾。这个例子只说明传播的观察范围，并非断言任何一次查询缺失都是网络延迟；网络选错或查询对象不对，也需要另行核对。
被池接收，仍没有获得下一块的座位
以太坊网络文档将待处理交易交换与区块构建分成两项工作：构建者从候选交易中选取内容形成执行载荷，区块再经过传播与验证。交易池提供候选材料，不是承诺按到达顺序全部处理的售票系统。
因此，不能拿自己的提交时间，直接推导它在全网队列中的固定名次。某个服务展示的排序是该服务按自身数据和规则形成的视图，并不是协议已经为每笔交易签发的排期。本文不据交易池规模预测等待时间，也不指导加费或重复发送。
池中的记录会变化，消失原因需要证据
交易被纳入节点接受的区块后，便不再属于同一意义上的待处理集合。比特币文档还说明，链上发生重组时，原区块中的一些交易可能重新进入池，之后又随替代区块的确认被移出。因此，查询结果应当带上观察时间，而不是永久标签。
反过来，只看到一条交易从某个池列表消失，不能独立证明它已经确认。需要进一步查区块记录与交易标识是否对应。不同客户端版本的保留和持久化策略也不能一概而论，尤其不应从历史资料中的关机行为推断所有当前节点。
给内容或看板保留最小可复核记录
记录待处理状态时，可同时保留网络名称、交易标识、查询入口和观察时刻；记录入块状态时，再补充对应区块及查询结果。前者回答“这个入口当时看到了什么”，后者才开始回答“它是否进入了这个网络的区块”。
这样的分层记录能避免把一个网页截图升级成全网结论。交易池适合观察候选请求，却不能代替链上确认记录，更不能凭空给出收款完成承诺。读者无需把每种客户端策略都背下来，但应保留“本地、当时、待处理”这三个限定。