此段落內的文章

檢視更多

L2 交易確認收入的不同階段

Avatar
Whale
  • 更新於
追蹤

解读 L2 交易确认收入的不同阶段 - 01.jpg

L2 交易確認收入的不同階段

什麼時候可以確信一筆 L2 交易會被收入進區塊中？什麼時候可以確信一筆被收入的 L2 交易不會因為 Re-org 而被丟棄？

這篇文章將會介紹一筆 L2 交易的生命週期，以及在週期裡各個階段的安全假設與可靠程度。

  • 作者：Nic @ imToken Labs

  • 校對：Members at imToken Labs
  • 封面來源：Dylan Ferreira on Unsplash
  • 先備知識：
    • 一筆 L1 交易的生命週期
    • Re-org 發生的原因及影響
    • 知道 Ethereum 目前 PBS 架構中的角色及運作方式
    • 知道 Optimistic Rollup 與 Validity (ZK) Rollup 的不同

首先我們會先複習 L1 的交易生命週期，接著再進入主題 – L2 交易的生命週期及確認收入的可靠程度。

L1 交易

生命週期

使用者產出交易並簽名後，就會發送到 p2p 網路當中，並等待礦工（PoW）或 Proposer（PoS）將他的交易收入到區塊中。當使用者發現他的交易被收入到最新一個區塊中時，他還不能百分之百確認交易一定會寫入該條區塊鏈的歷史中，這是因為區塊鏈會發生 Re-org 的情況，他必須要等到那個區塊發生 Re-org 的機率夠低才能確信交易會被寫入歷史中。

生命週期：

解读 L2 交易确认收入的不同阶段 - 02.png

交易收入區塊後還是有可能發生 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 交易确认收入的不同阶段 - 03.png

使用者先等待交易被收入 L2 區塊中，再等待 L2 區塊透過一筆 L1 交易上傳到 L1，最後再等待 L1 交易被 Finalized

雖然和 L1 交易相比，L2 交易多了一段等待 L2 交易被 Sequencer 收進 L2 區塊的時間，但其實在 L2 區塊容量夠大、出塊速度夠快的情況下，這並不會耗費多少時間。主要的等待時間都會是花在 L1 交易確認收入上，所以使用體驗是差不多的。

但如果使用者願意做一些犧牲的話，是否可以換得更好的體驗？

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 更詳細的交易生命週期介紹可以參考官方文件。

關於 Optimism 更詳細的交易生命週期介紹可以參考官方文件。

在 Arbitrum 上檢查交易收入狀態

在 Arbitrum Explorer 上看到的交易會包含 Pre-Confirmation 的交易，也就是還未上傳到 L1 的交易，像是下面截圖中的這一筆交易，可以看到 Block Number 145353000 旁邊有一個 Confirmed by Sequencer 標示：

解读 L2 交易确认收入的不同阶段 - 04.png

只有被 Sequencer 確認但還未上傳到 L1 的交易

如果是像下面這一筆已經被上傳到 L1 的交易，它的狀態已經變成 69 L1 Block Confirmations，代表的是它已經被上傳到 L1 且包含這筆交易資料的 L1 區塊已經有 69 個區塊接在它後面了：

解读 L2 交易确认收入的不同阶段 - 05.png

包含這筆交易資料的 L1 區塊已經有 69 個區塊接在它後面，越多區塊接在它後面表示越安全

或像是這筆交易，包含這筆交易資料的 L1 區塊已經有 6174 個區塊接在它後面了，已經非常安全。

解读 L2 交易确认收入的不同阶段 - 06.png

但其實這邊可以做得更好的地方是結合 L1 的 Finality 資訊來呈現。單純告訴使用者有多少個 L1 Block Confirmation 的幫助有限，使用者還要自己去理解和計算這樣數量的 Block Confirmation 代表的安全程度是多少，而既然 L1（也就是 Ethereum）都已經有 Casper FFG 這樣的 Finality 機制了，Explorer 其實可以直接顯示該 L1 區塊目前在 L1 是否已經被 Finalized。而 Optimism 的 Explorer 就做到了這一點。

在 Optimism 上檢查交易收入狀態

在 Optimism Explorer 上看到的交易也會包含 Pre-Confirmation 的交易，也就是還未上傳到 L1 的交易，像是下面截圖中的這一筆交易，可以看到 Block Number 111526300 旁邊有一個 Confirmed by Sequencer 標示：

解读 L2 交易确认收入的不同阶段 - 07.png

只有被 Sequencer 確認但還未上傳到 L1 的交易

不過目前該 Explorer 似乎沒有明確規範 Confirmed by Sequencer的含義，它說「Sequencer confirmations are equivalent to a few block confirmations on L1.」，表示 Confirmed by Sequencer 代表的是已上傳到 L1 且已經有數個區塊接在後面了：

解读 L2 交易确认收入的不同阶段 - 08.png

但其實最新出現的交易一樣也都是顯示為 Confirmed by Sequencer，甚至數十天以前，都已經過了挑戰期的交易的狀態還是 Confirmed by Sequencer：

解读 L2 交易确认收入的不同阶段 - 09.png

數十天前的交易狀態還是停留在「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 的：

解读 L2 交易确认收入的不同阶段 - 10.png

點進 3480 這個 State Batch，可以看到它的狀態是 Finalized，這個 Finalized 對應到的是 L1（也就是 Ethereum）的 Finalized 狀態，是順利累積兩個 Epoch 驗證者們投票的、非常安全的狀態。

解读 L2 交易确认收入的不同阶段 - 11.png

State Batch 3480 在 L1 Block 18457449 被收入，而 Block 18457449 已經被 Finalized，來源：https://etherscan.io/block/18457449

如果是上傳了但還未在 L1 被 Finalized 的 Batch 的話，就會顯示為 Unfinalized：

解读 L2 交易确认收入的不同阶段 - 12.png

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 更詳細的交易生命週期介紹可以參考官方文件。

在 Starkscan 這個 StarkNet Explorer 上看到的交易也會包含 Pre-Confirmation 的交易，像是下面截圖中的這一筆交易，可以看到 Status 目前是 Accepted on L2，表示已經被 Sequencer 排進 L2 區塊裡：

解读 L2 交易确认收入的不同阶段 - 13.png

「Accepted on L2」表示已經被 Sequencer 排進 L2 區塊裡，但還沒有上傳到 L1

Accepted on L2 前面兩個狀態分別是 Received 與 Pending，代表「交易被收到且驗證通過」與「交易正在被 Sequencer 處理中」，交易處理執行完後就會進到 Accepted on L2 的狀態：

解读 L2 交易确认收入的不同阶段 - 14.png

交易被收到且驗證通過

解读 L2 交易确认收入的不同阶段 - 15.png

交易正在被 Sequencer 處理中

等到交易資料被上傳到 L1 後，狀態才會變成 Accepted on L1，像是下面這筆交易：

解读 L2 交易确认收入的不同阶段 - 16.png

交易資料已經被上傳到 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 更詳細的交易生命週期介紹可以參考官方文件。

在 zkSync Explorer 上看到的交易也會包含 Pre-Confirmation 的交易，像是下面截圖中的這一筆交易，可以看到 Status 目前是 zkSync Era Processed，表示已經被 Sequencer 排進 L2 區塊裡：

解读 L2 交易确认收入的不同阶段 - 17.png

這筆交易已經被 Sequencer 排進 L2 區塊，目前正等待被上傳至 L1（Ethereum Sending）

當 Sequencer 製作完 L2 區塊後，接著該區塊及裡面的交易會依序經過 Committed、Proven 與 Executed 三個階段，分別表示「區塊被上傳至 L1」、「區塊有效性已被證明」與「區塊內交易執行完後的 L2 狀態被更新到 L1」。以下分別展示三個處於不同階段的區塊與交易：

解读 L2 交易确认收入的不同阶段 - 18.png

Batch 292700 已經被上傳至 L1，進入 Committed 階段。來源：https://explorer.zksync.io/batch/292700

解读 L2 交易确认收入的不同阶段 - 19.png

Batch 292700 裡面的交易目前狀態，從 Ethereum Sending 變成 Ethereum Validating ，表示等待被零知識證明驗證其有效性

箭頭移到 Ethereum Validating 圖示上還會顯示不同階段，前一階段（Sending）的交易連結也會附上：

解读 L2 交易确认收入的不同阶段 - 20.png

這筆交易進入「Validating」階段，前一階段（Sending）上傳 Batch 到 L1 的交易連結在這裡也可以直接看到，相當完整

Batch 292000 的有效性已經被證明，所以進入 Proven 階段：

解读 L2 交易确认收入的不同阶段 - 21.png

Batch 被證明後進入 Proven 狀態，並附上執行 Prove 動作的交易連結

解读 L2 交易确认收入的不同阶段 - 22.png

裡面的交易也會從「Validating」進入到「Executing」階段，也就是等待被執行

當 Batch 被證明後，接著會進入一段等待時間（官方文件說是 21 小時左右），然後才會執行裡面的交易並更新 L1 上紀錄的 L2 狀態。這主要是因為目前還在 Alpha 階段所加上的一個保護措施，確保有任何 Bug 出現時能有充足時間反應。當 Batch 被執行後，就會進入最終的 Executed 階段：

解读 L2 交易确认收入的不同阶段 - 23.png

Batch 被執行後進入最終的 Executed 狀態，並附上執行 Execute 動作的交易連結

解读 L2 交易确认收入的不同阶段 - 24.png

Batch 裡面的交易狀態也更新為「Executed」

相比於 StarkNet 交易從 L2 到 L1 是在一步驟內完成，zkSync 將交易從 L2 到 L1 的過程拆成更細的三個階段：Committed → Proven → Executed。雖然因為保護措施的關係，整個過程拉長到約一天左右才會完成，但 Committed 狀態讓使用者可以很快就知道自己的交易是否已經被收入（交易進入 Committed 後就不再只是 Pre-Confirmation），而不需持續仰賴對 Sequencer 的信任。

而且 zkSync Explorer 針對不同階段都有提供豐富完整的顯示，讓任何人透過 Explorer 就能夠掌握交易最新狀態，甚至能夠親自去驗證每一個階段轉換（例如從 Committed 到 Proven、從 Proven 到 Executed）的交易執行。

但要注意的是目前 zkSync Sequencer 是有權利可以修改歷史紀錄的，主要也是作為 Alpha 階段的保護措施。這表示即便交易可以很快脫離 Pre-Confirmation，進入 Committed 階段，但其實到交易進入 Executed 階段之前，Sequencer 都還是可以從歷史紀錄中移除使用者交易的，所以實際上使用者還是得相信 Sequencer 長達一天的時間。

L1 也可以支援 Pre-Confirmation

如果可以提前知道誰是負責產出區塊的人，那 L1 也可以支援 Pre-Confirmation。以 Ethereum 為例，目前實際產出區塊的人是 Builder，Builder 就可以提供 Pre-Confirmation 的服務，給使用者一個交易收入保證。但因為 Builder 並非一定能獲得某個產出某個區塊的權利，而是必須去競標每個區塊產出的權利，因此這個 Pre-Confirmation 的效力就會比較差，而且還要看那個 Builder 的實力，如果它競爭力不夠強那就很難獲得產出區塊的權利，那它所提供的 Pre-Confirmation 服務就會大打折扣。

比較好的辦法是讓 Proposer 來提供 Pre-Confirmation 服務，因為「第幾個區塊由哪一個 Proposer 來提出」是預先算好、非常肯定的。但因為目前的 PBS 架構中，Proposer 只是提出區塊的角色，實際製作區塊、決定區塊內容的角色是 Builder，所以 Proposer 沒辦法直接在區塊塞入某筆交易或是要求 Builder 塞入某筆交易。等到未來 PBS 架構改變，例如加入 Inclusion List 或是允許 Proposer 能參與區塊製作，那 Proposer 就有機會提供 Pre-Confirmation 的服務。

註：更多關於 PBS 的介紹可以參考這一篇。

改善 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 的機率會逐漸降低，使用者對交易被收入的信心會逐漸上升
  • 相比於 L1 交易，L2 交易的生命週期多了一個階段是「L2 交易被收進 L2 區塊，並等待被上傳至 L1」的階段
  • 但這個階段因為資料還沒上傳至 L1，所以有可能有變數發生。使用者在這個階段所能獲得關於交易收入的保證就是 Sequencer 給的口頭承諾，稱為 Pre-Confirmation 或 Fast Confirmation、Soft Confirmation
  • 如果 Sequencer 是惡意的或是單純出現 Bug，那承諾就有可能被違背，導致使用者的 L2 交易沒被收入
  • 目前大部分 L2 在它們Explorer 呈現的交易狀態都有包含 Pre-Confirmation 的狀態，例如 Arbitrum/Optimism 的 Confirmed by Sequencer 或 StarkNet 的 Accepted on L2。大家看到這樣的資訊時請記得它所提供的交易收入保證的效力
  • 如果不想相信 Sequencer 提供的 Pre-Confirmation，就會需要等待久一點時間，並透過 L2Explorer 所提供關於 L2 資料被上傳到 L1 的資訊去驗證
  • Pre-Confirmation 可以加上經濟激勵機制的設計，例如在 Sequencer 違反承諾時透過智能合約懲罰它，讓使用者獲得更明確的保障

目前 L1 與 L2 交易在不同生命週期階段所提供的交易收入保證及相對應的風險

解读 L2 交易确认收入的不同阶段 - 25.png