何时算已确认

大多数时候，钱包先显示待处理，然后显示完成。在这里，这两个词之间有三个独立的时刻，它们保证的东西各不相同。

三个时刻

时刻	它是什么
预确认	带签名的迷你区块10 毫秒的调度目标。排序器已对这一排序和这一结果作出承诺
确认	EVM 区块250 毫秒的调度目标。钱包和浏览器看到的东西
最终性	以太坊结算重新推导该区块所需的数据已提交到以太坊，且该提交本身已是最终的

把它想成在柜台寄一封信，而柜员的动作非常快。首先，柜员读信、算出答案并给你一张签了名的收据：这就是预确认，几乎在你递出信的同时就完成了。稍后，柜员把它登入当天的账簿，那是其他所有人都能查到的东西：这就是确认。最后，账簿的一份副本被送往店外一个店里任何人都无法改动的保险库：这就是最终性。每一步都比上一步慢，也都比上一步更难撤销。

你的交易在到达排序器的那一瞬间就执行，所以结果在任何区块存在之前就已经存在。排序器以 10 毫秒的调度目标封存一个迷你区块，装入该区间内执行的所有内容并签名。这个签名就是预确认：排序器已对这一排序和这一结果作出承诺，若之后的区块与之矛盾，签过名的区块头就是对它不利的证据。

排序器以 250 毫秒的调度目标封存一个标准的以太坊形态的 EVM 区块，包裹该区间的迷你区块。这就是确认：钱包或浏览器向你展示的那个区块，带有区块号和哈希。

最终性即以太坊结算。当重新推导一个区块所需的数据已提交到以太坊，且该提交本身已是最终的，这个区块就是最终的。只有到那一刻，记录才完全不再依赖排序器。

执行与准入同步，所以回执在所在区块封存之前就已存在。以 10 毫秒的调度目标产出的迷你区块携带该区间的交易、回执和日志、状态差异哈希、微秒级时间戳，以及排序器密钥对区块头的签名；它通过自己的 RPC 方法和一个 WebSocket 订阅暴露出来，供对延迟敏感的应用据以行动。以 250 毫秒的调度目标产出的 EVM 区块包裹该区间的迷你区块，且下一个区块的时间戳在上一次封存时就已固定，这正是让独立的重新执行能够复现区块哈希的原因。最终性是 L1 收件箱合约中点名该区块派生载荷的提交，它本身在以太坊上是最终的。迷你区块的间隔是一个共识参数，而不是运营者的调节旋钮，因为副本节点必须就如何切分执行流达成一致。

调度目标不是承诺

两个间隔都是调度目标而非延迟保证，也都不是吞吐量声明。它们描述的是排序器力求达到的节律，而不是它在每一拍都必须满足的期限。

每一个保证了什么

预确认证明排序器说过：这件事发生了，按这个顺序，得出这个结果。它依赖排序器的诚实，并且它是证据：若之后的区块与签过名的区块头矛盾，就说明排序器食言了。
确认把交易放进每个工具都理解的规范区块序列中。它仍然依赖排序器，因为排序器是唯一封存区块的一方。
最终性意味着区块的内容已从以太坊得到提交。从那一刻起，任何人都能从公开数据重新推导该区块，排序器无法在不被每个副本节点察觉分歧的情况下改写它。

区别何时重要

对于一个人做的大多数事情，预确认就是那个重要的时刻：应用可以显示结果，而除非排序器与自己的签名矛盾，结果就不会改变。游戏、交易界面或柜台前的付款都可以据此行动。

确认是普通工具所报告的，所以它是钱包显示为完成的那一刻。最终性则是任何完全不能依赖排序器的事情所需要的时刻：正因如此，通过跨链桥提取到以太坊的操作，会在放款之前先对照一份已最终确定的规范回执重新验证。

你会看到的词

待处理：钱包已发送，尚未看到区块。在 Pickle 上，这通常比钱包自己的刷新周期还短。
已预确认：一个读取迷你区块的应用表示排序器已为它签名。
已确认：它已在一个有编号的 EVM 区块中。
最终：它所在区块的数据已从以太坊得到提交。本站不把这个词用于其他任何含义。