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

本文将为读者会介绍 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 訊息，導致Star​​kNet 交易收入確認的使用體驗不太好，這是未來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_-TweXHXX_LMagyJk_FpEDAp、pEDApFsss。

改善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 交易在不同的交易流程階段提供的交易收入保證與相對應的風險情形：