区块链 >区块链 > 解读 L2 交易确认收入的不同阶段

解读 L2 交易确认收入的不同阶段

更新时间：2024-01-03 09:31:19

简介介绍L2交易实现的全部流程，并分析交易流程各个阶段的安全性能。撰文：Nic @imTokenLabs 什么时候可以确信一笔L2（Layer2）交易会被收入进区块中？什么时候可以确信一笔来自L2交易的收入不会因为Re-org而被丢弃？本文将为读者会介绍L2交易实现的全部流程，并分析交易流程各个阶段的安全性能。先备知识： L1（Layer1）交...

介绍 L2 交易实现的全部流程，并分析交易流程各个阶段的安全性能。

撰文：Nic @ imToken Labs

什么时候可以确信一笔 L2（Layer2）交易会被收入进区块中？什么时候可以确信一笔来自 L2 交易的收入不会因为 Re-org 而被丢弃？

本文将为读者会介绍 L2 交易实现的全部流程，并分析交易流程各个阶段的安全性能。

先备知识：

L1（Layer1）交易的全部流程
Re-org 发生的原因及影响
了解 Ethereum 目前 PBS 架构中的角色及运作方式
了解 Optimistic Rollup 与 Validity (ZK) Rollup 的不同

了解 L1 交易

交易流程

用户发出交易并签名后，就会发送到 p2p 网络当中，并等待PoW 共识机制下的 Miner 或PoS 共识机制下的 Proposer 将他的交易收入到区块中。当用户发现他的交易被收入到最新一个区块中时，还不能百分之百确认交易一定会写入该条区块链的历史中，这是因为区块链可能会发生被称为「Re-org」的情况，用户必须历经等待，等到某个区块发生 Re-org 的机率足够低的时候，才能确信交易会被写入区块链的历史中。

L1 交易流程图示

交易收入区块后还是有可能发生 Re-org，必须要等到 Re-org 不太可能发生才能确信交易已经被 Finalized 。

Re-org 的机率和成本会因为一条链的共识算法与资产的市值而不同，在这里不会展开介绍 Re-org 成本的计算方式。

了解 L2 交易

交易流程

L2 用户产出交易并签名后，通常会直接送给负责排序交易的 Sequencer，由 Sequencer 将他的交易收入到 L2 区块中。接着，当 Sequencer 将 L2 区块数据透过一笔 L1 交易写回 L1 上时，使用者就可以看到自己的交易被包含在最新一个 L2 区块中。

不过，需要注意的是，因为 L2 区块数据是透过 L1 交易上传到 L1 上，所以还是有可能会碰到 L1 发生 Re-org 的情况导致该 L2 区块最终没有被写进区块链的历史中，也就是等同于 L2 Re-org，因此使用者还是要等 L1 Re-org 的发生机率足够低时，才能确信他的交易会被写入区块链的历史中。

L2 交易流程图示

用户先等待交易被收入 L2 区块中，再等待 L2 区块透过一笔 L1 交易上传到 L1，最后再等待 L1 交易被 Finalized。

虽然和 L1 交易相比，L2 交易多了一段等待 L2 交易被 Sequencer 收进 L2 区块的时间，但其实在 L2 区块容量够大、出块速度够快的情况下，此等待并不会耗费多少时间，因为等待的时间主要都会是花费 L1 交易在对收入的确认上，所以整体而言，L1 交易和 L2 交易的使用体验是相似的。

但如果使用者愿意做一些牺牲的话，是否可以换得更好的体验？

Pre-Confirmation/Fast Confirmation/Soft Confirmation

使用者应该要亲眼看到（包含 L2 交易的）L2 区块被收进 L1 区块里，甚至要等到 Re-org 发生机率足够低的时候，才能相信他的 L2 交易已经被收入。

但如果用户愿意相信 Sequencer 呢？可能 Sequencer 是由 L2 的开发团队运营、由一个名声显著的机构来运营，如果 Sequencer 在收到用户交易时就向用户保证他的交易会马上被收入、会在第 X 个区块被收入，那对愿意相信 Sequencer 的使用者来说，这个保证其实足够了。就像一个使用者如果相信他在使用的钱包，他不会在钱包已经提醒他交易被收入后，还疑神疑鬼地到 Etherscan 去反复检查。

而这个 Sequencer 提供的交易收入保证会被称做 Pre-Confirmation、Fast Confirmation 或 Soft Confirmation，可以理解为「提前的」「软性的」交易收入保证。它不需要等到 L2 交易被收入到 L1 区块，但它只是 Sequencer 给的口头承诺，Sequencer 可能因为 Bug 导致它忘记原本的承诺或是恶意的 Sequencer 会直接违反承诺，轻则浪费使用者时间，重则被「双花攻击」。

接下来，我们会介绍若干不同的 L2 交易收入状态的呈现方式。

Arbitrum/Optimism 的交易收入状态

目前，用户在 Arbitrum 或 Optimism 上送出交易后，几乎都能马上获得交易的收据（Transaction Receipt），里面会是交易执行的结果。这表示 Sequencer 已经在它本地端将交易排序好并仿真执行过一次了，这个交易收据就是给用户的 Pre-Confirmation。

了解更多

关于 Arbitrum 更详细的交易生命周期介绍可以复制下方链接到浏览器参考官方文件：

https://docs.arbitrum.io/tx-lifecycle

关于 Optimism 更详细的交易生命周期介绍可以复制下方链接到浏览器参考官方文件：

https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

在 Arbitrum 上检查交易收入状态

在 Arbitrum Explorer 上看到的交易会包含 Pre-Confirmation 的交易，也就是还未上传到 L1 的交易，如下图所示的这一笔交易，可以看到 Block Number 145353000 旁边有一个 Confirmed by Sequencer 标示：

上图所示是只有被 Sequencer 确认但还未上传到 L1 的交易

如果是像下图所示的这一笔已经被上传到 L1 的交易，它的状态已经变成 69 L1 Block Confirmations，代表的是它已经被上传到 L1 且包含这笔事务数据的 Layer1 区块已经有 69 个区块接在它后面了：

包含这笔事务数据的 L1 区块已经有 69 个区块接在它后面，越多区块接在它后面表示越安全。

或是如下方截图所示的这笔交易，包含这笔事务数据的 L1 区块已经有 6174 个区块接在它后面了，已经非常安全。

但其实这边可以做得更好的地方是结合 L1 的 Finality 信息来呈现。

单纯地告诉使用者有多少个 L1 Block Confirmation ，对使用者的帮助有限，因为使用者还要自己去理解和计算这样数量的 Block Confirmation 代表的安全程度是多少。而既然 Layer1（也就是 Ethereum）已经拥有 Casper FFG 这样的 Finality 机制，Explorer 其实就可以直接显示该 Layer1 区块目前在 Layer1 是否已经被 Finalized。目前，Optimism 的 Explorer 已经实现了这样的功能。

在 Optimism 上检查交易收入状态

在 Optimism Explorer 上看到的交易也会包含 Pre-Confirmation 的交易，也就是还未上传到 L1 的交易，如下图所示的这一笔交易，我们可以看到 Block Number 111526300 旁边有一个 Confirmed by Sequencer 的标示：

只被 Sequencer 确认但还未上传到 L1 的交易

不过目前该 Explorer 似乎没有明确规范 Confirmed by Sequencer 的含义，它说「Sequencer confirmations are equivalent to a few block confirmations on L1.」，表示 Confirmed by Sequencer 代表的是已上传到 L1 且已经有数个区块接在后面了：

但其实最新出现的交易也一样是显示为 Confirmed by Sequencer，甚至数十天以前，都已经过了挑战期的交易的状态还是 Confirmed by Sequencer：

数十天前的交易状态还是停留在「Confirmed by Sequencer」

阅读提示：上述情况也有可能是该 Explorer 将不同状态标示在不同地方：Block Number 后面的 Confirmed By Sequencer 是告诉使用者这个区块有被 Sequencer 确认，至于上传到 L1 后的状态使用者要自己再透过其他信息来确认，例如下文马上会提到的「L1 State Batch」信息。

另外如下方截图所示的这一笔已经被上传到 L1 的交易，还多了两个信息：「L1 State Batch Index」与「L1 State Root Submission Tx Hash」。这两个信息所代表的就是这笔 L2 交易被包含在哪个 State Batch 里，以及这个 State Batch 是透过哪一笔 L1 交易上传到 L1 的：

点进「3480」这个 State Batch，可以看到它的状态是Finalized，这个 Finalized 对应到的是 L1（即 Ethereum 主网）的 Finalized 状态，是已经顺利累积两个 Epoch 验证者投票的、非常安全的状态。

△ State Batch 3480 在 L1 Block 18457449 被收入，而 Block 18457449 已经被 Finalized。

来源：https://etherscan.io/block/18457449

如果是上传了但还未在 L1 被 Finalized 的 Batch 的话，就会显示为Unfinalized：

State Batch 3494 虽然被上传到 L1 了，但收入该 Batch 的 L1 Block 还未被 Finalized。

相较于 Arbitrum Explorer，Optimism Explorer 为交易提供了更多的信息（State Batch），且它会直接将 L1 Finality 信息串接到 L2 Explorer 上，直接让使用者知道 L1 区块是否已经被 Finalized，而不是自己去判断 Block Confirmation 数量所对应的安全程度。

StarkNet 的交易收入状态

目前，用户在 StarkNet 上送出交易后，虽然可以很快就查询到交易的收据，但通常收据里显示的交易状态会是 RECEIVED 的状态，这代表节点已经收到交易且交易经过验证后没有问题，会等待被 Sequencer 收入 L2 区块并执行，而在 RECEIVED 状态的交易还不会有任何交易执行的结果。用户可以透过 StarkNet Explorer 上显示的交易状态来得知自己交易的处理进度。

阅读提示：如果 Sequencer 处理得够快，那就有可能直接跳过 RECEIVED 状态，进到交易已经被处理的状态。关于 StarkNet 更详细的交易流程介绍可以复制下方链接到浏览器查阅官方文件。

官方文件：https://docs.starknet.io/documentation/architecture_and_concepts/Network_Architecture/transaction-life-cycle/

在 Starkscan 这个 StarkNet Explorer 上看到的交易也会包含 Pre-Confirmation 的交易，如下图所示的这一笔交易，可以看到 Status 目前是 Accepted on L2，表示已经被 Sequencer 排进 L2 区块里：

「Accepted on L2」表示已经被 Sequencer 排进 L2 区块里，但还没有上传到 L1

Accepted on L2 前面两个状态分别是 Received 与 Pending，代表「交易被收到且验证通过」与「交易正在被 Sequencer 处理中」，事务处理执行完后就会进到 Accepted on L2 的状态：

交易被收到且验证通过

交易正在被 Sequencer 处理中

等到事务数据被上传到 L1 后，状态才会变成 Accepted on L1，如下图所示的这笔交易：

事务数据已经被上传到 L1

虽然 StarkNet 的交易有更丰富的状态，能让用户知道交易的处理进度，但交易被上传到 L1 的时间可能还需要等待四、五个小时（可能是因为产生零知识证明会需要比较久的时间），因此，这段时间的使用者都是仰赖 Sequencer 的 Pre-Confirmation。

另外 Explorer 针对上传到 L1 的交易也只有显示 Accepted on L1，没有搭配 L1 的 Finality 或 Block Confirmation 的信息，等于用户要自己去查 L1 区块是否有足够多的区块接在后面或是是否已被 Finalized。

整体来说，因为 StarkNet 本身效能瓶颈让用户需要仰赖 Pre-Confirmation 很长一段时间，以及 Explorer 没有支持 L1 Finality 信息，导致 StarkNet 交易收入确认的使用体验不太好，这是未来 StarkNet 需要改进的地方。

zkSync 的交易收入状态

和 StakrNet 相似，zkSync 也有 PENDING 的状态，代表的是节点已经收到交易且交易经过验证后没有问题，会等待被 Sequencer 收入 L2 区块并执行，而在 PENDING 状态的交易还不会有任何交易执行的结果。

用户可以透过 zkSync Explorer 上显示的交易状态来得知自己交易的处理进度。

阅读提示：如果 Sequencer 处理得够快，那就有可能直接跳过 PENDING 状态，进到交易已经被处理的状态。

关于 zkSync 更详细的交易流程介绍，可以复制下方链接到浏览器查阅：https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum

在 zkSync Explorer 上看到的交易也会包含 Pre-Confirmation 的交易，像是下面截图中的这一笔交易，可以看到 Status 目前是 zkSync Era Processed，表示已经被 Sequencer 排进 L2 区块里：

这笔交易已经被 Sequencer 排进 L2 区块，目前正等待被上传至 L1（Ethereum Sending）

当 Sequencer 制作完 L2 区块后，接着该区块及里面的交易会依序经过 Committed、Proven 与 Executed 三个阶段，分别表示「区块被上传至 L1」、「区块有效性已被证明」与「区块内交易执行完后的 L2 状态被更新到 L1」。以下分别展示三个处于不同阶段的区块与交易：

Batch 292700 已经被上传至 L1，进入 Committed 阶段。来源：https://explorer.zksync.io/batch/292700

Batch 292700 里面的交易目前状态，从 Ethereum Sending 变成 Ethereum Validating ，表示等待被零知识证明验证其有效性。

箭头移到 Ethereum Validating 图标上还会显示不同阶段，前一阶段（Sending）的交易链接也会附上：

这笔交易进入「Validating」阶段，前一阶段（Sending）上传 Batch 到 L1 的交易链接在这里也可以直接看到。

Batch 292000 的有效性已经被证明，所以进入 Proven 阶段：

Batch 被证明后进入 Proven 状态，并附上执行 Prove 动作的交易链接。

里面的交易也会从「Validating」进入到「Executing」阶段，也就是等待被执行。

当 Batch 被证明后，接着会进入一段等待时间（官方文件说是 21 小时左右），然后才会执行里面的交易并更新 L1 上记录的 L2 状态。这主要是因为目前还在 Alpha 阶段所加上的一个保护措施，确保有任何 Bug 出现时能有充足时间反应。当 Batch 被执行后，就会进入最终的 Executed 阶段：

Batch 被执行后进入最终的 Executed 状态，并附上执行 Execute 动作的交易链接。

Batch 里面的交易状态也更新为「Executed」

相比于 StarkNet 交易从 L2 到 L1 是在一个步骤内完成，zkSync 将交易从 L2 到 L1 的过程则被拆解成更加细节的三个阶段：Committed → Proven → Executed。

虽然作为保护措施，是整个交易过程的时间拉长到大约一天左右，但 Committed 状态让使用者可以很快就知道自己的交易是否已经被收入（交易进入 Committed 后就不再只是 Pre-Confirmation），而不需持续仰赖对 Sequencer 的信任。

并且，zkSync Explorer 针对不同阶段都提供了丰富、完整的数据展示，任何人都可以通过 Explorer 掌握交易最新状态，甚至能够亲自去验证每一个阶段转换（例如从 Committed 到 Proven、从 Proven 到 Executed）的交易执行。

但要注意的是，作为 Alpha 阶段的保护措施，目前，zkSync Sequencer 是可以修改历史记录的。

这表明即便交易可以很快脱离 Pre-Confirmation，进入 Committed 阶段，但其实到交易进入 Executed 阶段之前，Sequencer 都可以从历史记录中移除用户交易。因此，使用者还是需要信任 Sequencer 长达一天的时间。

L1 也可以支持 Pre-Confirmation

如果可以提前知道谁是负责产出区块的人，那 L1 也可以支持 Pre-Confirmation。

以 Ethereum 为例，目前实际产出区块的人是 Builder，Builder 就可以提供 Pre-Confirmation 的服务，给用户一个交易收入保证。但因为 Builder 并非一定能获得某个产出某个区块的权利，而是必须去竞标每个区块产出的权利，因此这个 Pre-Confirmation 的效力就会比较差，而且还要考虑 Builder 的实力，如果 Builder 的竞争力不够强，那这个 Builder 就很难获得产出区块的权利，因此这个 Builder 所提供的 Pre-Confirmation 服务就会大打折扣。

如果要避免上述问题，一个比较好的办法是让 Proposer 来提供 Pre-Confirmation 服务，因为「第几个区块由哪一个 Proposer 来提出」通常是预先计算好的、确定性的情况。

但因为目前的 PBS 架构中，Proposer 只是提出区块的角色，实际制作区块、决定区块内容的角色是 Builder，所以 Proposer 没办法直接在区块塞入某笔交易或是要求 Builder 塞入某笔交易。等到未来 PBS 架构改变，例如加入 Inclusion List 或是允许 Proposer 能参与区块制作，那 Proposer 就有机会提供 Pre-Confirmation 的服务。

阅读提示：更多关于 PBS 的介绍，请复制下方链接到浏览器阅读：https://mirror.xyz/0x347c9872A2a1dE370D798f9FE96341A9A0E05af8/oG_4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss。

改善 Pre-Confirmation

Pre-Confirmation 只是 Builder 或 L2 Sequencer 的口头承诺，对方没有履行承诺的义务、不履行也没有惩罚机制。

是否可以让这个承诺更有保证呢？其实也是可以的，因为负责产出区块的人和其承诺的内容（例如「在第 1350000 区块收入这笔交易」）都是可以写成条件检查的。因此我们可以藉由智能合约来规范 Builder 或 Sequencer，请它们提供 Pre-Confirmation 服务时顺便在智能合约内抵押押金，并且在给出交易收入的承诺时要对内容签名，当使用者发现 Builder 或 Sequencer 没有履行承诺时便可将承诺内容及对方的签名送至智能合约，智能合约便可以检查承诺是否有被履行（例如「在第 1350000 区块收入这笔交易」）。

虽然上述合约的应用场景还在概念验证阶段，但下方链接展示的演讲视频里讲述了是其中一个合约应用的例子，详情请复制下方链接到浏览器查看：https://www.youtube.com/watch?v=Uw5HxSYXwYo

总结

L1 交易被收入进 L1 区块后，发生 Re-org 的概率会逐渐降低，用户对交易被收入的信心会逐渐上升。
L2 交易比 L1 交易多出的一个交易工作流程是：「L2 交易被收进 L2 区块，并等待被上传至 L1」的阶段。
但在 L2 交易相比 L1 交易多出的交易工作流程中，由于在这个阶段，数据还没上传至 L1，依旧存在变量发生的可能，因此使用者在此阶段所能获得的、关于交易收入的保证就是 Sequencer 的口头承诺，称为 Pre-Confirmation 或 Fast Confirmation、Soft Confirmation。
如果 Sequencer 是恶意的，或是单纯出现 Bug，那 Sequencer 给出的承诺就有可能被违背，导致用户的 L2 交易没有收入确认。
目前，大部分 L2 在其 Explorer 里呈现的交易状态都包含有 Pre-Confirmation 的状态，例如 Arbitrum/Optimism 的 Confirmed by Sequencer 或 StarkNet 的 Accepted on L2。大家看到这样的信息时，请注意关注这些信息所提供的交易收入保证的时间效力。
如果不想信任 Sequencer 提供的 Pre-Confirmation，那就需要等待久一点时间，并透过 L2 Explorer 所提供关于 L2 数据被上传到 L1 的信息去进行验证。
Pre-Confirmation 可以加上经济激励机制的设计，例如在 Sequencer 违反承诺时，可以通过智能合约进行惩罚，让使用者获得更明确的保障。

下方表格展示的是 L1 交易与 L2 交易在不同的交易流程阶段提供的交易收入保证和相对应的风险情形：

本站提醒：投资有风险，入市须谨慎，本内容不作为投资理财建议。