多金快讯 / 知识读本 · 以太坊 · 2 分钟阅读
浏览器显示交易成功，说明它在某个区块的执行结果成功；这和该区块已获得最终确定并不是同一个判断。对于交易所入账、跨链消息和大额结算，应明确自己依赖的是链尖状态、较稳定状态还是最终确定状态。
执行成功与历史稳定分开看
交易回执中的成功标记描述执行是否回滚。区块能否成为长期保留的历史，还取决于共识选择。以太坊权益证明通过验证者的投票和检查点机制形成最终性，不能把它简化为“过了若干秒就绝对不可更改”。
短暂分叉可能让链尖附近的交易改变位置。在最终性正常推进时，已最终确定的历史具有更强经济约束；若网络出现严重异常，最终性可能停滞，应用需要能够识别这种状态，而不是只按墙上时钟倒计时。
算例：两笔看似相同的成功转账
假设甲付款被收录在当前链尖区块，乙付款所在区块已经处于节点返回的 finalized 状态。两笔回执都成功，但一个跨链系统若承诺只依据最终确定状态释放资产，就不应同时把两者当成完成。
应用可以记录交易哈希、区块哈希和查询时的状态标签，再在目标状态达到后推进业务。若只记交易哈希而不记区块位置，很难判断后来看到的是原收录位置还是重组后重新收录的结果。
| 状态 | 回答的问题 | 仍需核查 |
|---|---|---|
| 执行成功 | 本次调用是否回滚 | 收款对象及实际结果 |
| 已包含 | 交易是否位于当前链上 | 重组与后续共识状态 |
| 已最终确定 | 历史是否达到协议最终性 | 节点可靠性及业务规则 |
数据接口也有信任边界
部分节点接口提供 latest、safe 和 finalized 等区块标签，帮助应用指定查询基准。但服务商可能同步落后、缓存过期或错误处理标签，关键结算仍应确认客户端能力及多个数据来源的一致性。
同一地址在 latest 状态下的余额，可能包含尚未达到业务要求的资金。不能先以这个余额启动后续不可撤回支付，再把“最终性还没到”视作仅仅显示层面的延迟。
异常期间如何停止自动化
把共识状态与业务状态分别保存：广播、已包含、执行成功、达到最终性、内部审核完成。遇到最终确定高度长时间不前进时，触发告警并暂停依赖它的结算，保留人工复核路径。
恢复后需要重新读取区块哈希与回执，而非直接把排队任务全部标成完成。对无法承担停机的产品，也应在上线前决定备用策略的信任成本，并向使用者准确说明其实际保障。
实用检查清单
- 给“完成”定义明确的区块状态和业务条件。
- 保存区块哈希，允许链尖阶段的状态回退。
- 监测最终性推进，异常时暂停依赖结算。
常见问题
有最终性是否就不用检查地址了？
仍然需要。最终性说明历史的稳定程度，无法判断付款对象是否正确、合约是否可信，也不能撤销用户主动批准的错误交易。
二层显示成功就等于主网最终确定吗？
不一定。排序器收据、批次发布、证明或争议流程及主网最终性可能是不同阶段。必须查具体二层网络的状态定义和退出规则。