解讀L2交易實現全流程：各個階段的安全性能如何？

什麽時候可以確信一筆 L2（Layer2）交易會被收入進區塊中？什麽時候可以確信一筆來自 L2 交易的收入不會因爲 Re-org 而被丟棄？

本文將爲讀者會介紹 L2 交易實現的全部流程，併分析交易流程各個階段的安全性能。

先備知識：

1.L1（Layer1）交易的全部流程

2.Re-org 髮生的原因及影響

3.了解 Ethereum 目前 PBS 架構中的角色及運作方式

4.了解 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

總結

1. L1 交易被收入進 L1 區塊後，髮生 Re-org 的概率會逐漸降低，用戶對交易被收入的信心會逐漸上升。
2. L2 交易比 L1 交易多出的一個交易工作流程是：「L2 交易被收進 L2 區塊，併等待被上傳至 L1」的階段。
3. 但在 L2 交易相比 L1 交易多出的交易工作流程中，由於在這個階段，數據還沒上傳至 L1，依舊存在變量髮生的可能，因此使用者在此階段所能穫得的、關於交易收入的保證就是 Sequencer 的口頭承諾，稱爲 Pre-Confirmation 或 Fast Confirmation、Soft Confirmation。
4. 如果 Sequencer 是惡意的，或是單純出現 Bug，那Sequencer 給出的承諾就有可能被違背，導緻用戶的 L2 交易沒有收入確認。
5. 目前，大部分 L2在其 Explorer 裡呈現的交易狀態都包含有 Pre-Confirmation 的狀態，例如 Arbitrum/Optimism 的 Confirmed by Sequencer 或 StarkNet 的 Accepted on L2。大家看到這樣的信息時，請註意關註這些信息所提供的交易收入保證的時間效力。
6. 如果不想信任 Sequencer 提供的 Pre-Confirmation，那就需要等待久一點時間，併透過 L2 Explorer 所提供關於 L2 數據被上傳到 L1 的信息去進行驗證。
7. Pre-Confirmation 可以加上經濟激勵機製的設計，例如在 Sequencer 違反承諾時，可以通過智能合約進行懲罰，讓使用者穫得更明確的保障。

下方錶格展示的是 L1 交易 與 L2 交易在不衕的交易流程階段提供的交易收入保證和相對應的風險情形：

聲明：

1. 本文轉載自[imToken Labs]，著作權歸屬原作者[Nic]，如對轉載有異議，請聯繫Gate Learn團隊，團隊會根據相關流程盡速處理。
2. 免責聲明：本文所錶達的觀點和意見僅代錶作者個人觀點，不構成任何投資建議。
3. 文章其他語言版本由Gate Learn團隊翻譯， 在未提及Gate.io的情況下不得覆製、傳播或抄襲經翻譯文章。