latest、safe、finalized有何区别？

同一时刻查询latest、safe和finalized，得到的区块高度往往不同。越靠近链头越新，越靠近最终性越稳定。标签不是三个“确认数预设”，而是执行层把权益证明共识状态暴露给应用的不同视图。选择时要先回答：业务能承受多大延迟，又能承受多大回滚。

标签	位置	重组可能性	常见用途
latest	节点当前规范链头	正常短重组可能发生	即时界面、待确认监控
safe	已justified的安全头	需要严重延迟或攻击	较稳索引、业务预确认
finalized	已最终确定检查点及之前	回滚代价极高	结算、不可逆业务门槛

latest适合快，但要会回滚

读latest余额或日志能最快反映新交易，可是新区块可能被竞争链替换。索引器应按blockHash保存数据，检测parentHash变化并撤销孤块事件；前端则应把latest状态标成待确认，不能立刻触发不可逆的站外发货。

safe head已在信标链获得justification，在正常网络条件下预期会进入最终链。它比固定等待几个执行区块更直接表达共识状态，但仍保留极端回滚可能。应用要处理节点暂不支持标签、返回null或safe高度暂时不前进。

“12个确认就等于finalized”并不严格；确认数是从链头向后数，finalized来自共识检查点。另一方面，finalized也不是数学上永不改变，客户端错误或灾难级社会共识事件仍需运营预案，只是它提供了协议级最强常规保证。

finalized区块已经经过权益证明最终性。制造冲突最终性需要大规模共识违规并触发质押罚没，因此风险显著低于链头。代价是数据更旧；交易所可先在safe阶段显示入账待用，在finalized后开放不可逆提现或跨系统结算。

日志索引回滚可结合eth_getLogs与removed处理；交易状态查看回执字段，账户证明应固定区块并参考eth_getProof。