什麼時候可以確信一筆 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 交易在不同的交易流程階段提供的交易收入保證和相對應的風險情形：

聲明：

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