Arbitrum 一笔交易的确认分几层？软确认、safe 与 finalized 三档读法

为什么 L2 的确认不是一个开关

在以太坊这样的 L1 上，“确认”相对直接：区块被放进规范链，链的最终性规则给出答案。Rollup 上情况更复杂：交易先进入排序器的内存执行，批次数据稍后才压缩发到以太坊，以太坊自身敲定之后这批数据才算钉死。执行、数据发布、以太坊敲定三个时点并不重合。Arbitrum 官方文档因此把确认分成 soft confirmation、safe 和 finalized 三档，让集成方按业务风险选择等待哪一档。

软确认：排序器的一句话承诺

三层确认分层的概念示意（图片由 Agnes 生成，非产品界面或数据图）

交易被排序器接收并排进 L2 区块的那一刻就是软确认。官方文档对排序器端点的描述是：eth_sendRawTransaction 返回成功时，排序器已经把这笔交易排进区块并执行完毕，调用会阻塞到区块创建才返回。排序器同时通过一条实时消息流（Sequencer Feed）向外广播完整的交易顺序，节点不必等批次上链就能跟着最新顺序走。软确认带来亚秒级响应，但官方文档同时写明，这只是排序器的承诺，尚未获得父链背书——排序器出错或被更换时，软确认之前的顺序承诺可能被改写。高频场景依赖这一档换取速度，代价是承担排序器层面的重组风险。

safe：批次数据进入父链

包含目标区块的批次被发布到以太坊上的收件箱合约、并且该发布交易达到以太坊的 safe 区块之后，交易进入 safe 档。此时数据已经在以太坊上落了地，除非以太坊本身发生深度重组，交易不会再消失。引入了数据可用性证明与证书机制之后，批次可以靠委员会签名的 DACert 保证数据可取回，但官方文档明确区分：证书只保证数据可检索，不等于区块已在父链结算。数据可用与最终结算是两条独立的时间线。

finalized：把安全性交回以太坊

当批次发布交易达到以太坊的 finalized 区块，这条 L2 上的交易获得硬最终性。官方文档还提醒了嵌套情形：如果一条 L3 结算在 Base 这样的父链上，它的 finalized 不可能比 Base 的 finalized 更最终，而 Base 最终追踪以太坊共识。确认层级是层层嵌套的信任栈，上层多快敲定、下层就最多多快，任何数据可用性优化都改变不了以太坊自身的敲定时间。

软确认失守时的兜底路径

软确认依赖排序器持续正常运作。官方文档同时描述了两条兜底：其一是不走排序器的普通交易通道——交易可以提交到公开的普通端点，进入专用队列，运转正常的排序器通常在约十分钟内把它们纳入；其二是延迟收件箱，任何网络参与者都可以把被搁置超过二十四小时的交易强制收录进主收件箱，排序器能做的只是暂时延迟而无法永久封杀。此外排序器长期停摆还会触发审查超时机制，让链切换到直接从父链读交易的运行方式。这些机制决定了三档确认不是并列选项：软确认是速度换风险的快路径，后两档加上强制收录，才是任何情况下都走得通的底线。

集成时怎么选、怎么排障

官方文档给出的路径清晰：低延迟场景接受软确认；金额敏感的场景等 safe 或 finalized；直接调用排序器端点时注意其排队行为——交易在内部队列超过默认超时未被接收会返回 context deadline exceeded，这类失败意味着未被接受，可以退避重试，而 nonce too low 或合约回滚属于终局错误，不应盲目重发。若依赖 safe 与 finalized 标签，先确认自己这条链的父链暴露最终性数据、节点已配置跟踪它们，再向集成方文档化预期的确认延迟。