一笔交易被打包进区块后，钱包或区块浏览器会开始显示“1 个确认”“6 个确认”。这个数字有用，但它回答的问题和最终确定性回答的问题并不相同：确认数说的是这笔交易后面又叠了多少个区块，最终确定性说的是交易所在的那段链是否已经进入“回滚要付出极高经济代价”的状态。确认数增加，不等于协议层面已经最终确定。
三个层次，分开看
| 层次 | 发生了什么 | 能回答的问题 | 不能回答的问题 |
|---|---|---|---|
| 被区块包含 | 交易进入某个区块，执行结果写入该区块 | 交易是否已经上链 | 后面会不会被换掉 |
| 后续确认增加 | 该区块之后又接上新的区块，确认数累加 | 交易埋入链的深度 | 是否已达到协议级最终确定 |
| 最终确定性 | 协议通过检查点投票与后续链接最终确定 | 回滚是否要付出极高经济代价 | 平台是否已经入账 |
还有一个边界要提前说清：节点状况、网络条件和协议参数都会影响从“被包含”走到“最终确定”所需的时间，不存在可以承诺的固定秒数；交易所或支付平台显示“已到账”，还可能叠加自己的风控与入账规则，和链上最终确定性是两套判断。
以太坊 PoS 的最终确定性在保证什么
以太坊在 2022 年转向 PoS 后，验证者需要质押 ETH 参与共识，行为不诚实可能被罚没质押。时间被划分为时隙和时段，每个时段开头有一个检查点区块。验证者对检查点对投票，协议通过检查点投票和后续链接最终确定。
这里的关键是：最终确定性是一种强经济安全保证，而不是“经济上绝对不可能逆转”。要回滚一个已最终确定的检查点，攻击者需要承担至少三分之一总质押 ETH 被罚没的代价。另外，最终确定性保护的是已最终确定检查点及其祖先；判断一笔交易是否被覆盖，要看它所在的链段是否落在这个范围里，而不是去找“包含这笔交易的检查点”。
还要注意，不能把一次三分之二投票直接说成“已经最终确定”。在客户端或浏览器明确显示 finalized 之前，不应按已最终确定处理。
一个教学计算：确认数不等于安全等级
假设某条链平均每 12 秒出一个块，一笔交易在区块 N 中被包含，看到 6 个确认，大约意味着经过了 5 个后续区块，名义时间约 60 秒。这是明确假设下的算术，不是对任何真实链上到账时间的承诺。
这 60 秒只说明“埋了 5 层”，不说明“已最终确定”。从包含到最终确定可能横跨多个时段；节点同步慢、网络延迟、验证者参与率波动，都会让实际等待时间变化。所以正确用法是：确认数用来估埋入深度，最终确定性用来判是否进入强保证区间，两者分开设阈值。
确认数的口径本身也可能不同：有的按“包含交易的区块之后又接了多少块”计，有的把包含块本身算作第一个确认，不同工具显示的“6 个确认”未必对应同一深度。跨工具比较时，先确认口径，再谈数字。
判定顺序
- 先确认交易所在区块：交易哈希能查到，且区块已被节点接受，这是“被包含”。
- 再看确认数是否持续增长：确认数在涨，说明后续区块在接续，短程被替换的风险在下降。
- 查该交易所在链段是否已被最终确定：只有这一步给出协议级强保证。若客户端或浏览器显示 finalized，才按已最终确定处理。
- 平台到账单独判断：即使链上已最终确定，平台仍可能按自己的确认数政策、风控或人工审核决定何时可用。
对于金额较大或不可撤销的交付场景，把“已最终确定”作为放行条件更稳妥；但不宜反过来推导“小金额就可以只看少量确认放行”——小额交易同样可能涉及后续结算、对账或凭证效力，是否放行应由业务自己定义风险阈值，而不是由确认数单独决定。
常见误区
- “确认数越多就一定越安全”：确认数增加降低的是短程重组风险，最终确定性是另一层强经济保证，不能互相替代。
- “看到 1 个确认就是到账”：被包含只是第一步，后续确认和最终确定都可能还需要时间。
- “一次三分之二投票就等于最终确定”：在客户端或浏览器明确显示 finalized 之前，不应按已最终确定处理。
- “所有链都一样”：不同共识机制、不同客户端配置下，最终确定性的实现和等待条件不同，不能把一条链的参数套到另一条链。
- “平台显示到账等于链上最终确定”：平台到账是平台规则，可能早于也可能晚于链上最终确定。
确认数回答“埋得多深”，最终确定性回答“回滚要付出多大代价”。把这两个问题分开，才不会在需要强保证的场景里，把一个确认数误当成终点。