解讀L2事務實現的全過程：每個階段的安全性能如何？

作者： Nic@ imToken Labs

我什麼時候可以確定 L2 事務將包含在區塊中？ 我什麼時候可以確定 L2 交易的收入不會因為重組而被丟棄？

本文將介紹 L2 事務實現的全過程，並分析事務處理各個階段的安全性能。

先決條件：

• L1（第 1 層）交易的整個過程
• 重組的原因和影響 *瞭解乙太坊在PBS架構中的當前角色及其工作原理
• 瞭解樂觀匯總和有效性 （ZK） 匯總之間的差異

瞭解 L1 事務

交易流程

L1 事務流示意圖

重組后仍有可能交易收入區塊，要等到重組不太可能發生時才能確信交易已經敲定。

重組的概率和成本會根據鏈的共識演演演算法和資產的市值而有所不同，這裡不介紹重組成本的計算。

瞭解 L2 事務

交易流程

L2 使用者生成並簽署交易后，通常會直接發送給負責對交易進行排序的 Sequencer，然後 Sequencer 將他的交易收集到 L2 塊中。 然後，當 Sequencer 通過 L1 事務將 L2 塊數據寫回 L1 時，使用者可以看到他們的事務包含在最新的 L2 塊中。

但需要注意的是，由於 L2 區塊數據是通過 L1 交易上傳到 L1 的，因此仍有可能遇到 L1 重組發生的情況，導致 L2 區塊最終沒有被寫入區塊鏈的歷史記錄，即相當於 L2 重組，因此使用者仍然需要等待 L1 重組的概率足夠低才能確保他的交易被寫入區塊鏈的歷史。

L2 事務流示意圖

使用者首先等待事務包含在 L2 區塊中，然後等待 L2 區塊通過 L1 事務上傳到 L1，最後等待 L1 事務完成。

雖然與 L1 交易相比，L2 交易還有額外的時間等待 L2 交易被 Sequencer 納入 L2 區塊，但實際上，當 L2 區塊大小足夠大，區塊生產速度足夠快時，這個等待時間不會花費太多時間，因為等待時間會主要將 L1 交易花在收入的確認上，所以總體來說，L1 交易和 L2 交易的體驗是相似的。

但如果用戶願意做出一些犧牲，能換取更好的體驗嗎？

預確認/快速確認/軟確認

用戶應該看到 L2 區塊（包含 L2 交易）包含在 L1 區塊中，甚至等到 Re-org 發生的概率足夠低，相信他的 L2 交易已經獲得。

但是，如果用戶願意信任Sequencer呢？ 也許 Sequencer 由 L2 開發團隊運營，由信譽良好的組織運營，如果 Sequencer 向使用者保證他的交易將立即在第 X 個區塊得到支付，那麼對於願意信任 Sequencer 的用戶來說，這種保證就足夠了。 就像使用者信任他正在使用的錢包一樣，在錢包提醒他交易已支付后，他不會可疑地去 Etherscan 進行仔細檢查。

該排序器提供的交易收入保證稱為預確認、快速確認或軟確認，可以理解為“提前”或“軟”交易收入保證。 它不需要等待 L2 事務包含在 L1 區塊中，但它只是 Sequencer 給出的口頭承諾，Sequencer 可能會因為 Bug 或惡意 Sequencer 會直接違背承諾而忘記當初的承諾，這可能會浪費用戶時間或成為“雙花攻擊”。

接下來，我們將介紹 L2 交易收入狀態的一些不同方式。

仲裁/樂觀的交易收入狀況

目前，在Arbitrum或樂觀上發送交易的用戶幾乎可以立即獲得交易收據，這將是交易執行的結果。 這意味著 Sequencer 已經在本地對交易的執行進行了排序和類比，並且此交易收據是使用者的預確認。

要瞭解有關 Arbitrum 的更多資訊，可以將交易生命週期的更詳細說明複製到以下瀏覽器參考官方文檔的連結：

有關樂觀交易生命週期的更詳細介紹，請將以下連結複製到瀏覽器參考官方文檔：

在仲裁上查看交易收入狀態

您在 Arbitrum 瀏覽器上看到的交易將包含預確認交易，即尚未上傳到 L1 的交易，如下圖所示，您可以看到區塊編號 145353000 旁邊有一個 Sequencer 確認指示器：

上圖顯示了僅由 Sequencer 確認但尚未上傳到 L1 的交易

如果交易已經上傳到 L1，如下圖所示，其狀態已更改為 69 個 L1 區塊確認，這意味著它已上傳到 L1 並包含交易數據區塊，其背後有 69 個區塊：

包含此交易數據的 L1 區塊後面已經有 69 個區塊，它後面的區塊越多，它就越安全。

或者下面截圖顯示的交易，包含此交易數據的L1區塊後面有6174個區塊，已經非常安全了。

但這裡可以做得更好的是結合 L1 最終性資訊。

簡單地告訴使用者有多少個 L1 區塊確認對用戶的説明有限，因為用戶必須理解和計算這麼多區塊確認所代表的安全級別。 由於第 1 層（即乙太坊）已經具有 Casper FFG 等最終機制，因此資源管理器實際上可以直接顯示第 1 層塊當前是否在第 1 層中完成。 目前，樂觀主義的瀏覽器已經實現了這樣的功能。

在樂觀狀態上查看交易收益狀態

我們在樂觀瀏覽器上看到的交易還將包括預確認交易，即尚未上傳到 L1 的交易，如下圖所示，我們可以看到區塊編號 111526300 旁邊有一個 Sequencer 確認符號：

僅由 Sequencer 確認但尚未上傳到 L1 的交易

但是，資源管理器似乎沒有明確說明 Sequencer 確認的含義，說“Sequencer 確認相當於 L1 上的幾個塊確認”，表明 Sequencer 確認表示已上傳到 L1 的多個塊，後跟幾個：

但實際上，最新交易也顯示為 Sequencer 確認，甚至幾十天前，已經過了挑戰期的交易狀態依然是 Sequencer 確認：

幾十天前，交易狀態還停留在“由Sequencer確認”

閱讀提示：上述情況也可能是資源管理器在不同的地方標記了不同的狀態：區塊號后的 Confirm By Sequencer 告訴使用者該區塊已經被 Sequencer 確認，使用者在上傳到 L1 後要通過其他資訊確認狀態，比如下面提到的“L1 狀態批處理”資訊。

此外，已上傳到 L1 的事務（如下面的螢幕截圖所示）有兩個附加資訊：“L1 狀態批處理索引”和“L1 狀態根提交 Tx 哈希”。 以下兩條資訊表示包含 L2 事務的狀態批處理和將狀態批處理上傳到 L1 的 L1 事務：

點擊“3480”狀態批處理，可以看到它的狀態是 Finalized，對應的是 L1（即乙太坊主網）的 Finalized 狀態，這是一個非常安全的狀態，已經成功積累了兩個 Epoch 驗證者的投票。

△ 國家批次3480已在L1第18457449座收購，第18457449區塊已經完成。

資料來源：

如果批次已上傳但尚未在 L1 中完成，則將顯示為未完成：

儘管狀態批處理 3494 已上傳到 L1，但批處理中包含的 L1 塊尚未最終確定。

與 Arbitrum 瀏覽器相比，樂觀瀏覽器為交易提供了更多資訊（狀態批處理），它會直接將 L1 Finality 資訊串到 L2 資源管理器中，以便使用者可以直接知道 L1 區塊是否已經定型，而不是判斷區塊確認數量對應的安全程度。

斯塔克網的交易收益狀況

目前，使用者在StarkNet上發送交易后，雖然可以快速查詢到交易的收據，但收據中顯示的交易狀態通常會處於RECEIVED狀態，這意味著節點已經收到交易，交易驗證后沒有問題，會等待Sequencer L2區塊接收到交易並執行，而處於RECEIVED狀態的交易不會有任何交易執行結果。 用戶可以通過StarkNet Explorer上顯示的交易狀態來檢查其交易進度。

閱讀提示：如果 Sequencer 處理速度足夠快，則可以跳過 RECEIVED 狀態並轉到已處理事務的狀態。 有關StarkNet交易流程的更詳細介紹，您可以複製下面的連結以在瀏覽器中查看官方檔。

官方檔： _and_concepts/網络_Architecture/交易生命週期/

在StarkNet瀏覽器Starkscan上看到的交易也將包括預確認交易，如下圖所示，您可以看到狀態當前在L2上為“已接受”，這意味著它已被Sequencer排名到L2區塊中：

“在 L2 上接受”表示它已被 Sequencer 放置在 L2 塊中，但尚未上傳到 L1

L2 上接受的前兩個狀態是「已接收」和「掛起」，這意味著「事務已收到並驗證」和「事務正在由 Sequencer 處理」，事務執行後將在 L2 上進入「已接受」狀態：

交易被接收並驗證

交易正在由 Sequencer 處理

交易數據上傳到 L1 後，L1 狀態將變為已接受，如下圖所示：

事務資料已上傳到 L1

雖然StarkNet的交易狀態更豐富，可以讓使用者知道交易的進度，但交易上傳到L1可能需要四五個小時（可能是因為生成零知識證明需要很長時間），所以這段時間的使用者依賴Sequencer的預確認。

此外，對於上傳到 L1 的交易，資源管理器僅在 L1 上顯示已接受，並且沒有 L1 的終結或區塊確認資訊，這意味著使用者必須檢查 L1 區塊中是否有足夠的區塊或是否已經完成。

總體來看，由於StarkNet本身的性能瓶頸，使用者需要長期依賴預確認，而資源管理器不支援L1最終資訊，導致StarkNet交易收入確認體驗不佳，這是StarkNet未來需要改進的地方。

zkSync 的交易收入狀況

與 StakrNet 類似，zkSync 也具有 PENDING 狀態，這意味著 Node 已經收到交易並且交易已經過驗證，沒有問題，它會等待交易被 Block 並由 Sequencer L2 執行，而處於 PENDING 狀態的交易不會有任何交易執行結果。

用戶可以通過 zkSync 資源管理器上顯示的事務狀態瞭解其事務進度。

閱讀提示：如果 Sequencer 處理速度足夠快，則可以跳過 PENDING 狀態並轉到已處理事務的狀態。

有關 zkSync 交易流程的更詳細介紹，您可以複製以下連結在瀏覽器中查看：

您在 zkSync 資源管理器上看到的交易還將包括預確認交易，例如下面螢幕截圖中的交易，您可以看到狀態當前為 zkSync 時代已處理，這意味著它已被排序器排名到 L2 區塊中：

該交易已被Sequencer放置在L2區塊中，目前正在等待上傳到L1（乙太坊發送）

Sequencer 創建 L2 區塊後，區塊及其中的交易將依次經歷三個階段：已提交、已證明和 uted，表示“區塊已上傳到 L1”、“區塊有效性已證明”、“區塊交易執行後 L2 狀態已更新為 L1”。 不同階段的區塊和交易如下所示：

批處理 292700 已上傳到 L1，處於提交階段。 資料來源：

批次 292700 中的交易當前狀態已從乙太坊發送更改為乙太坊驗證，表明它正在等待零知識證明的驗證。

將箭頭移到乙太坊驗證圖示上也會顯示不同的階段，並且還將附加上一階段（發送）的交易連結：

此事務進入“正在驗證”階段，也可以在此處看到前一階段（發送中）將 Batch 上傳到 L1 的事務的連結。

批次 292000 的有效性已得到證明，因此請進入驗證階段：

驗證 Batch 後，它將進入「已驗證」狀態，其中包含指向執行「證明」操作的事務的連結。

交易也將從“驗證”變為“uting”，即等待執行。

當批次被證明時，它會進入等待期（在官方檔中約為 21 小時），然後執行內部交易並更新 L1 上記錄的 L2 狀態。 這主要是由於在alpha階段添加了保護措施，以確保有足夠的時間對出現的任何錯誤做出反應。 當批次處理被執行時，它進入最後的uted階段：

執行批處理后，它將通過執行 ute 操作的事務連結進入最終 uted 狀態。

批處理中的事務狀態也已更新為“uted”

與 StarkNet 相比，L2 到 L1 的交易一步完成，zkSync 將 L2 放在 L1 的過程分為三個更詳細的階段：承諾→驗證→ uted。

雖然作為保障措施，整個交易過程延長到大約一天左右，但 Commit 狀態允許使用者快速知道交易是否已獲得（並且不再只是交易進入 Commit 後的預確認），而不必持續依賴對 Sequencer 的信任。

此外，zkSync Explorer 為不同階段提供了豐富完整的數據展示，讓任何人都可以通過資源管理器掌握交易的最新狀態，甚至能夠親自驗證每個階段過渡（如從提交到證明，從已驗證到uted）的交易執行情況。

但是，應該注意的是，作為alpha階段的保護措施，此時可以通過zkSync序列器修改歷史記錄。

這表明，即使交易可以快速退出預確認並進入提交階段，Sequencer 實際上也可以在交易進入 uted 階段之前從歷史記錄中刪除使用者交易。 因此，消費者仍然需要信任Sequencer長達一天的時間。

L1 也可以支持預確認

如果你能提前知道誰負責生產區塊，那麼L1也可以支持預確認。

以乙太坊為例，實際生產區塊的人是構建者，構建者可以提供預確認服務，給使用者交易收入保障。 但是由於建造者不一定獲得某個輸出和某個區塊的權利，而是必須競標每個區塊輸出的權利，所以這個預確認的有效性會比較差，並且必須考慮建造者的實力，如果建造者沒有足夠的競爭力，那麼建造者很難獲得生產區塊的權利，所以建造者提供的預確認 服務將受到很大影響。

如果你想避免上述問題，最好讓提議者提供預確認服務，因為“哪個提議者將提出第一個區塊”通常是一個預先計算的、確定性的情況。

但是，由於在目前的PBS架構中，提議者只提出區塊的角色，而實際製作區塊和確定區塊內容的作用是生成器，所以提議者不能直接將交易塞入區塊或要求構建者填充交易。 當PBS架構在未來發生變化時，例如添加包含清單或允許提議者參與區塊生產，提議者將有機會提供預確認服務。

閱讀提示：有關PBS的更多資訊，請複製以下連結以在瀏覽器中閱讀：_4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss。

改進預確認

預確認只是構建者或 L2 Sequencer 的口頭承諾，對方沒有履行承諾的義務，不履行也沒有懲罰機制。

有沒有可能讓這個承諾更有把握？ 實際上，是的，因為負責生產區塊的人和他的承諾內容（例如“在1,350,000個區塊中收入交易”）可以寫成條件檢查。 因此，我們可以利用智慧合約來規範構建者或Sequencer，要求他們在智慧合約中抵押押金時提供預確認服務，在給出交易收益承諾時對內容進行簽名，當用戶發現構建者或Sequencer沒有履行承諾時，可以將承諾的內容和對方的簽名發送到智慧合約，智慧合約可以檢查承諾是否已經履行（如“在第一個 本次交易的1,350,000塊收入“）。

雖然上述合約的應用場景仍處於概念驗證階段，但以下連結中顯示的演示視頻講述了其中一個合約申請的範例，請複製下面的連結，在瀏覽器中查看詳細資訊：

總結

• L1交易納入L1區塊后，重組概率將逐漸下降，使用者對交易收入的信心將逐漸上升。
• L2 事務比 L1 事務多一個事務工作流，即 L2 事務包含在 L2 區塊中並等待上傳到 L1 的階段。
• 但在 L2 筆交易多於 L1 筆交易的交易工作流中，由於現階段數據尚未上傳到 L1，因此仍有變數的可能，因此使用者現階段能夠獲得的交易收益保證是 Sequencer 的口頭承諾，稱為預確認或快速確認、軟確認。
• 如果 Sequencer 是惡意的，或者存在簡單的錯誤，則可能違反 Sequencer 的承諾，導致使用者的 L2 交易無法確認收入。
• 目前，瀏覽器中的大多數 L2 交易狀態都包含預確認狀態，例如 Arbitrum/Optimism 的 Sequencer 確認或 StarkNet 的 L2 接受。 當您看到此類資訊時，請注意此資訊提供的交易收益保證的時間有效期。
• 如果您不想信任 Sequencer 提供的預確認，則需要等待更長的時間，並使用 L2 資源管理器提供的有關上傳到 L1 的 L2 數據的信息進行驗證。
• 預確認可以與經濟激勵的設計相結合，比如當Sequencer違反承諾時通過智慧合約進行處罰，讓使用者得到更清晰的保護。

下表說明瞭L1交易和L2交易在交易過程不同階段提供的交易收入保證和相應的風險場景：