原创主题配图: 链观 BTC866 原创主题图解 · ChainView BTC866 Editorial · CC BY 4.0
确认代表区块中的位置
交易被某个区块收录后，通常开始累计确认数；后续区块继续建立在该历史上，重新改写交易位置的成本通常增加。确认数是观察链状态的指标，不是由客服发放的保证。不同网络的共识机制、区块间隔和安全假设不同，不能把一个网络的六次确认机械地换算成另一个网络相同程度的保障。
短暂分叉为何出现
传播延迟可能使不同节点短时间看到不同的链头，节点随后按各自规则选择有效历史。重组会使原先被收录的交易回到待确认状态，或者被冲突交易替代；它不等于所有历史都被随意删除。观察时记录旧区块和新区块的哈希、共同祖先及涉及交易，区分真实重组与浏览器显示延迟或索引错误。
概率最终性与经济最终性
工作量证明通常通过累积工作量提高改写难度，权益证明网络可能设置检查点和最终性投票。经济最终性依赖惩罚机制、参与条件与攻击假设，也不意味着软件绝不出现严重缺陷。阅读文档时区分“头部”“合理化”“最终确定”等状态，确认数据接口的含义；某个平台显示“完成”可能只是其内部业务状态。
离线与网络异常情景
节点长时间离线后，需要重新同步并核对共识状态。网络分区、客户端故障或验证者参与不足可能减慢确认或最终确定，不能用平常出块时间推算确定到账时刻。运营者应记录同步进度、对等连接和最终性滞后，必要时暂停依赖低确认的业务，而不是仅靠增加浏览器刷新次数来判断网络恢复。
应用层为何继续等待
交易平台、桥和商户会根据金额、资产与风险设置额外确认阈值。链上已最终确定但平台尚未入账，可能与账户审查、备注字段或维护有关。用交易哈希区分链上状态和业务状态，再查阅接收方要求。对于不可逆交付，不应只依据钱包通知；应从可信节点或多个独立数据源核验预期金额和接收条件。
设计最终性记录表
记录表至少包含网络、交易哈希、首次见到时间、收录高度、区块哈希、确认状态和接收方入账时间。发生重组时保留前后状态，避免用单张截图覆盖整个过程。测试可以使用公开历史样本或测试网，无需发送真实资金。记录的价值在于识别等待发生在哪一层，而不是声称达到某个数字后所有风险都会消失。
具体核验案例
假设交易先进入高度一百的区块，随后节点切换到另一条分支，使该交易重新进入等待状态。记录旧块哈希、新链头与最终重新收录高度，不能只保留最后“成功”的截图。若平台要求更多确认，还应另记其入账时间。这个时间线可以解释链上重组和业务等待分别占用多久，也能防止把平台延迟错误归咎于协议最终性或把短暂重组误报为永久丢失。
