【#區(qū)塊鏈# #解讀 L2 交易確認(rèn)收入的不同階段?#】

介紹 L2 交易實現(xiàn)的全部流程，并分析交易流程各個階段的安全性能。

撰文：Nic?@ imToken Labs

什么時候可以確信一筆 L2（Layer2）交易會被收入進(jìn)區(qū)塊中？什么時候可以確信一筆來自 L2 交易的收入不會因為 Re-org 而被丟棄？

本文將為讀者會介紹 L2 交易實現(xiàn)的全部流程，并分析交易流程各個階段的安全性能。

先備知識：

• L1（Layer1）交易的全部流程
• Re-org 發(fā)生的原因及影響
• 了解 Ethereum 目前 PBS 架構(gòu)中的角色及運(yùn)作方式
• 了解 Optimistic Rollup 與 Validity (ZK) Rollup 的不同

了解 L1 交易?

交易流程

用戶發(fā)出交易并簽名后，就會發(fā)送到 p2p 網(wǎng)絡(luò)當(dāng)中，并等待PoW 共識機(jī)制下的?Miner 或 PoS 共識機(jī)制下的?Proposer 將他的交易收入到區(qū)塊中。當(dāng)用戶發(fā)現(xiàn)他的交易被收入到最新一個區(qū)塊中時，還不能百分之百確認(rèn)交易一定會寫入該條區(qū)塊鏈的歷史中，這是因為區(qū)塊鏈可能會發(fā)生被稱為「Re-org」的情況，用戶必須歷經(jīng)等待，等到某個區(qū)塊發(fā)生 Re-org 的機(jī)率足夠低的時候，才能確信交易會被寫入?yún)^(qū)塊鏈的歷史中。

L1 交易流程圖示

交易收入?yún)^(qū)塊后還是有可能發(fā)生 Re-org，必須要等到 Re-org 不太可能發(fā)生才能確信交易已經(jīng)被 Finalized 。

Re-org 的機(jī)率和成本會因為一條鏈的共識算法與資產(chǎn)的市值而不同，在這里不會展開介紹 Re-org 成本的計算方式。

了解 L2 交易

交易流程

L2 用戶產(chǎn)出交易并簽名后，通常會直接送給負(fù)責(zé)排序交易的 Sequencer，由 Sequencer 將他的交易收入到 L2 區(qū)塊中。接著，當(dāng) Sequencer 將 L2 區(qū)塊數(shù)據(jù)透過一筆 L1 交易寫回 L1 上時，使用者就可以看到自己的交易被包含在最新一個 L2 區(qū)塊中。

不過，需要注意的是，因為 L2 區(qū)塊數(shù)據(jù)是透過 L1 交易上傳到 L1 上，所以還是有可能會碰到 L1 發(fā)生 Re-org 的情況導(dǎo)致該 L2 區(qū)塊最終沒有被寫進(jìn)區(qū)塊鏈的歷史中，也就是等同于 L2 Re-org，因此使用者還是要等 L1 Re-org 的發(fā)生機(jī)率足夠低時，才能確信他的交易會被寫入?yún)^(qū)塊鏈的歷史中。

L2 交易流程圖示

用戶先等待交易被收入 L2 區(qū)塊中，再等待 L2 區(qū)塊透過一筆 L1 交易上傳到 L1，最后再等待 L1 交易被 Finalized。

雖然和 L1 交易相比，L2 交易多了一段等待 L2 交易被 Sequencer 收進(jìn) L2 區(qū)塊的時間，但其實在 L2 區(qū)塊容量夠大、出塊速度夠快的情況下，此等待并不會耗費(fèi)多少時間，因為等待的時間主要都會是花費(fèi) L1 交易在對收入的確認(rèn)上，所以整體而言，L1 交易和 L2 交易的使用體驗是相似的。

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

Pre-Confirmation/Fast Confirmation/Soft Confirmation

使用者應(yīng)該要親眼看到（包含 L2 交易的）L2 區(qū)塊被收進(jìn) L1 區(qū)塊里，甚至要等到 Re-org 發(fā)生機(jī)率足夠低的時候，才能相信他的 L2 交易已經(jīng)被收入。

但如果用戶愿意相信 Sequencer 呢？可能 Sequencer 是由 L2 的開發(fā)團(tuán)隊運(yùn)營、由一個名聲顯著的機(jī)構(gòu)來運(yùn)營，如果 Sequencer 在收到用戶交易時就向用戶保證他的交易會馬上被收入、會在第 X 個區(qū)塊被收入，那對愿意相信 Sequencer 的使用者來說，這個保證其實足夠了。就像一個使用者如果相信他在使用的錢包，他不會在錢包已經(jīng)提醒他交易被收入后，還疑神疑鬼地到 Etherscan 去反復(fù)檢查。

而這個 Sequencer 提供的交易收入保證會被稱做 Pre-Confirmation、Fast Confirmation 或 Soft Confirmation，可以理解為「提前的」「軟性的」交易收入保證。它不需要等到 L2 交易被收入到 L1 區(qū)塊，但它只是 Sequencer 給的口頭承諾，Sequencer 可能因為 Bug 導(dǎo)致它忘記原本的承諾或是惡意的 Sequencer 會直接違反承諾，輕則浪費(fèi)使用者時間，重則被「雙花攻擊」。

接下來，我們會介紹若干不同的 L2 交易收入狀態(tài)的呈現(xiàn)方式。

Arbitrum/Optimism 的交易收入狀態(tài)

目前，用戶在 Arbitrum 或 Optimism 上送出交易后，幾乎都能馬上獲得交易的收據(jù)（Transaction Receipt），里面會是交易執(zhí)行的結(jié)果。這表示 Sequencer 已經(jīng)在它本地端將交易排序好并仿真執(zhí)行過一次了，這個交易收據(jù)就是給用戶的 Pre-Confirmation。

了解更多

關(guān)于 Arbitrum 更詳細(xì)的交易生命周期介紹可以復(fù)制下方鏈接到瀏覽器參考官方文件：

https://docs.arbitrum.io/tx-lifecycle

關(guān)于 Optimism 更詳細(xì)的交易生命周期介紹可以復(fù)制下方鏈接到瀏覽器參考官方文件：

https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

在 Arbitrum 上檢查交易收入狀態(tài)

在 Arbitrum Explorer 上看到的交易會包含 Pre-Confirmation 的交易，也就是還未上傳到 L1 的交易，如下圖所示的這一筆交易，可以看到 Block Number 145353000 旁邊有一個 Confirmed by Sequencer 標(biāo)示：

上圖所示是只有被 Sequencer 確認(rèn)但還未上傳到 L1 的交易

如果是像下圖所示的這一筆已經(jīng)被上傳到 L1 的交易，它的狀態(tài)已經(jīng)變成 69 L1 Block Confirmations，代表的是它已經(jīng)被上傳到 L1 且包含這筆事務(wù)數(shù)據(jù)的 Layer1 區(qū)塊已經(jīng)有 69 個區(qū)塊接在它后面了：

?包含這筆事務(wù)數(shù)據(jù)的 L1 區(qū)塊已經(jīng)有 69 個區(qū)塊接在它后面，越多區(qū)塊接在它后面表示越安全。

或是如下方截圖所示的這筆交易，包含這筆事務(wù)數(shù)據(jù)的 L1 區(qū)塊已經(jīng)有 6174 個區(qū)塊接在它后面了，已經(jīng)非常安全。

但其實這邊可以做得更好的地方是結(jié)合 L1 的 Finality 信息來呈現(xiàn)。

單純地告訴使用者有多少個 L1 Block Confirmation ，對使用者的幫助有限，因為使用者還要自己去理解和計算這樣數(shù)量的 Block Confirmation 代表的安全程度是多少。而既然 Layer1（也就是 Ethereum）已經(jīng)擁有 Casper FFG 這樣的 Finality 機(jī)制，Explorer 其實就可以直接顯示該 Layer1 區(qū)塊目前在 Layer1 是否已經(jīng)被 Finalized。目前，Optimism 的 Explorer 已經(jīng)實現(xiàn)了這樣的功能。

在 Optimism 上檢查交易收入狀態(tài)

在 Optimism Explorer 上看到的交易也會包含 Pre-Confirmation 的交易，也就是還未上傳到 L1 的交易，如下圖所示的這一筆交易，我們可以看到 Block Number 111526300 旁邊有一個 Confirmed by Sequencer 的標(biāo)示：

只被 Sequencer 確認(rèn)但還未上傳到 L1 的交易

不過目前該 Explorer 似乎沒有明確規(guī)范 Confirmed by Sequencer 的含義，它說「Sequencer confirmations are equivalent to a few block confirmations on L1.」，表示 Confirmed by Sequencer 代表的是已上傳到 L1 且已經(jīng)有數(shù)個區(qū)塊接在后面了：

但其實最新出現(xiàn)的交易也一樣是顯示為 Confirmed by Sequencer，甚至數(shù)十天以前，都已經(jīng)過了挑戰(zhàn)期的交易的狀態(tài)還是 Confirmed by Sequencer：

數(shù)十天前的交易狀態(tài)還是停留在「Confirmed by Sequencer」

閱讀提示：上述情況也有可能是該 Explorer 將不同狀態(tài)標(biāo)示在不同地方：Block Number 后面的 Confirmed By Sequencer 是告訴使用者這個區(qū)塊有被 Sequencer 確認(rèn)，至于上傳到 L1 后的狀態(tài)使用者要自己再透過其他信息來確認(rèn)，例如下文馬上會提到的「L1 State Batch」信息。

另外如下方截圖所示的這一筆已經(jīng)被上傳到 L1 的交易，還多了兩個信息：「L1 State Batch Index」 與「L1 State Root Submission Tx Hash」。這兩個信息所代表的就是這筆 L2 交易被包含在哪個 State Batch 里，以及這個 State Batch 是透過哪一筆 L1 交易上傳到 L1 的：

點(diǎn)進(jìn)?「3480」這個 State Batch，可以看到它的狀態(tài)是 Finalized，這個 Finalized 對應(yīng)到的是 L1（即 Ethereum 主網(wǎng)）的 Finalized 狀態(tài)，是已經(jīng)順利累積兩個 Epoch 驗證者投票的、非常安全的狀態(tài)。

△ State Batch 3480 在 L1 Block 18457449 被收入，而 Block 18457449 已經(jīng)被 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 區(qū)塊是否已經(jīng)被 Finalized，而不是自己去判斷 Block Confirmation 數(shù)量所對應(yīng)的安全程度。

StarkNet 的交易收入狀態(tài)

目前，用戶在 StarkNet 上送出交易后，雖然可以很快就查詢到交易的收據(jù)，但通常收據(jù)里顯示的交易狀態(tài)會是 RECEIVED 的狀態(tài)，這代表節(jié)點(diǎn)已經(jīng)收到交易且交易經(jīng)過驗證后沒有問題，會等待被 Sequencer 收入 L2 區(qū)塊并執(zhí)行，而在 RECEIVED 狀態(tài)的交易還不會有任何交易執(zhí)行的結(jié)果。用戶可以透過 StarkNet Explorer 上顯示的交易狀態(tài)來得知自己交易的處理進(jìn)度。

閱讀提示：如果 Sequencer 處理得夠快，那就有可能直接跳過 RECEIVED 狀態(tài)，進(jìn)到交易已經(jīng)被處理的狀態(tài)。關(guān)于 StarkNet 更詳細(xì)的交易流程介紹可以復(fù)制下方鏈接到瀏覽器查閱官方文件。

官方文件：https://docs.starknet.io/documentation/architecture_and_concepts/Network_Architecture/transaction-life-cycle/

在 Starkscan 這個 StarkNet Explorer 上看到的交易也會包含 Pre-Confirmation 的交易，如下圖所示的這一筆交易，可以看到 Status 目前是 Accepted on L2，表示已經(jīng)被 Sequencer 排進(jìn) L2 區(qū)塊里：

「Accepted on L2」表示已經(jīng)被 Sequencer 排進(jìn) L2 區(qū)塊里，但還沒有上傳到 L1

Accepted on L2 前面兩個狀態(tài)分別是 Received 與 Pending，代表「交易被收到且驗證通過」與「交易正在被 Sequencer 處理中」，事務(wù)處理執(zhí)行完后就會進(jìn)到 Accepted on L2 的狀態(tài)：

交易被收到且驗證通過

交易正在被 Sequencer 處理中

等到事務(wù)數(shù)據(jù)被上傳到 L1 后，狀態(tài)才會變成 Accepted on L1，如下圖所示的這筆交易：

事務(wù)數(shù)據(jù)已經(jīng)被上傳到 L1

雖然 StarkNet 的交易有更豐富的狀態(tài)，能讓用戶知道交易的處理進(jìn)度，但交易被上傳到 L1 的時間可能還需要等待四、五個小時（可能是因為產(chǎn)生零知識證明會需要比較久的時間），因此，這段時間的使用者都是仰賴 Sequencer 的 Pre-Confirmation。

另外 Explorer 針對上傳到 L1 的交易也只有顯示 Accepted on L1，沒有搭配 L1 的 Finality 或 Block Confirmation 的信息，等于用戶要自己去查 L1 區(qū)塊是否有足夠多的區(qū)塊接在后面或是是否已被 Finalized。

整體來說，因為 StarkNet 本身效能瓶頸讓用戶需要仰賴 Pre-Confirmation 很長一段時間，以及 Explorer 沒有支持 L1 Finality 信息，導(dǎo)致 StarkNet 交易收入確認(rèn)的使用體驗不太好，這是未來 StarkNet 需要改進(jìn)的地方。

zkSync 的交易收入狀態(tài)

和 StakrNet 相似，zkSync 也有 PENDING 的狀態(tài)，代表的是節(jié)點(diǎn)已經(jīng)收到交易且交易經(jīng)過驗證后沒有問題，會等待被 Sequencer 收入 L2 區(qū)塊并執(zhí)行，而在 PENDING 狀態(tài)的交易還不會有任何交易執(zhí)行的結(jié)果。

用戶可以透過 zkSync Explorer 上顯示的交易狀態(tài)來得知自己交易的處理進(jìn)度。

閱讀提示：如果 Sequencer 處理得夠快，那就有可能直接跳過 PENDING 狀態(tài)，進(jìn)到交易已經(jīng)被處理的狀態(tài)。

關(guān)于 zkSync 更詳細(xì)的交易流程介紹，可以復(fù)制下方鏈接到瀏覽器查閱：https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum

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

這筆交易已經(jīng)被 Sequencer 排進(jìn) L2 區(qū)塊，目前正等待被上傳至 L1（Ethereum Sending）

當(dāng) Sequencer 制作完 L2 區(qū)塊后，接著該區(qū)塊及里面的交易會依序經(jīng)過 Committed、Proven 與 Executed 三個階段，分別表示「區(qū)塊被上傳至 L1」、「區(qū)塊有效性已被證明」與「區(qū)塊內(nèi)交易執(zhí)行完后的 L2 狀態(tài)被更新到 L1」。以下分別展示三個處于不同階段的區(qū)塊與交易：

Batch 292700 已經(jīng)被上傳至 L1，進(jìn)入 Committed 階段。來源：https://explorer.zksync.io/batch/292700

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

箭頭移到 Ethereum Validating 圖標(biāo)上還會顯示不同階段，前一階段（Sending）的交易鏈接也會附上：

這筆交易進(jìn)入「Validating」階段，前一階段（Sending）上傳 Batch 到 L1 的交易鏈接在這里也可以直接看到。

Batch 292000?的有效性已經(jīng)被證明，所以進(jìn)入 Proven 階段：

Batch 被證明后進(jìn)入 Proven 狀態(tài)，并附上執(zhí)行 Prove 動作的交易鏈接。

里面的交易也會從「Validating」進(jìn)入到「Executing」階段，也就是等待被執(zhí)行。

當(dāng) Batch 被證明后，接著會進(jìn)入一段等待時間（官方文件說是 21 小時左右），然后才會執(zhí)行里面的交易并更新 L1 上記錄的 L2 狀態(tài)。這主要是因為目前還在 Alpha 階段所加上的一個保護(hù)措施，確保有任何 Bug 出現(xiàn)時能有充足時間反應(yīng)。當(dāng) Batch 被執(zhí)行后，就會進(jìn)入最終的 Executed 階段：

Batch 被執(zhí)行后進(jìn)入最終的 Executed 狀態(tài)，并附上執(zhí)行 Execute 動作的交易鏈接。

Batch 里面的交易狀態(tài)也更新為「Executed」

相比于 StarkNet 交易從 L2 到 L1 是在一個步驟內(nèi)完成，zkSync 將交易從 L2 到 L1 的過程則被拆解成更加細(xì)節(jié)的三個階段：Committed → Proven → Executed。

雖然作為保護(hù)措施，是整個交易過程的時間拉長到大約一天左右，但 Committed 狀態(tài)讓使用者可以很快就知道自己的交易是否已經(jīng)被收入（交易進(jìn)入 Committed 后就不再只是 Pre-Confirmation），而不需持續(xù)仰賴對 Sequencer 的信任。

并且，zkSync Explorer 針對不同階段都提供了豐富、完整的數(shù)據(jù)展示，任何人都可以通過 Explorer 掌握交易最新狀態(tài)，甚至能夠親自去驗證每一個階段轉(zhuǎn)換（例如從 Committed 到 Proven、從 Proven 到 Executed）的交易執(zhí)行。

但要注意的是，作為 Alpha 階段的保護(hù)措施， 目前，zkSync Sequencer 是可以修改歷史記錄的。

這表明即便交易可以很快脫離 Pre-Confirmation，進(jìn)入 Committed 階段，但其實到交易進(jìn)入 Executed 階段之前，Sequencer 都可以從歷史記錄中移除用戶交易。因此，使用者還是需要信任 Sequencer 長達(dá)一天的時間。

L1 也可以支持 Pre-Confirmation

如果可以提前知道誰是負(fù)責(zé)產(chǎn)出區(qū)塊的人，那 L1 也可以支持 Pre-Confirmation。

以 Ethereum 為例，目前實際產(chǎn)出區(qū)塊的人是 Builder，Builder 就可以提供 Pre-Confirmation 的服務(wù)，給用戶一個交易收入保證。但因為 Builder 并非一定能獲得某個產(chǎn)出某個區(qū)塊的權(quán)利，而是必須去競標(biāo)每個區(qū)塊產(chǎn)出的權(quán)利，因此這個 Pre-Confirmation 的效力就會比較差，而且還要考慮 Builder 的實力，如果 Builder 的競爭力不夠強(qiáng)，那這個 Builder 就很難獲得產(chǎn)出區(qū)塊的權(quán)利，因此這個 Builder 所提供的 Pre-Confirmation 服務(wù)就會大打折扣。

如果要避免上述問題，一個比較好的辦法是讓 Proposer 來提供 Pre-Confirmation 服務(wù)，因為「第幾個區(qū)塊由哪一個 Proposer 來提出」通常是預(yù)先計算好的、確定性的情況。

但因為目前的 PBS 架構(gòu)中，Proposer 只是提出區(qū)塊的角色，實際制作區(qū)塊、決定區(qū)塊內(nèi)容的角色是 Builder，所以 Proposer 沒辦法直接在區(qū)塊塞入某筆交易或是要求 Builder 塞入某筆交易。等到未來 PBS 架構(gòu)改變，例如加入 Inclusion List 或是允許 Proposer 能參與區(qū)塊制作，那 Proposer 就有機(jī)會提供 Pre-Confirmation 的服務(wù)。

閱讀提示：更多關(guān)于 PBS 的介紹，請復(fù)制下方鏈接到瀏覽器閱讀：https://mirror.xyz/0x347c9872A2a1dE370D798f9FE96341A9A0E05af8/oG_4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss。

改善 Pre-Confirmation

Pre-Confirmation 只是 Builder 或 L2 Sequencer 的口頭承諾，對方?jīng)]有履行承諾的義務(wù)、不履行也沒有懲罰機(jī)制。

是否可以讓這個承諾更有保證呢？其實也是可以的，因為負(fù)責(zé)產(chǎn)出區(qū)塊的人和其承諾的內(nèi)容（例如「在第 1350000 區(qū)塊收入這筆交易」）都是可以寫成條件檢查的。因此我們可以藉由智能合約來規(guī)范 Builder 或 Sequencer，請它們提供 Pre-Confirmation 服務(wù)時順便在智能合約內(nèi)抵押押金，并且在給出交易收入的承諾時要對內(nèi)容簽名，當(dāng)使用者發(fā)現(xiàn) Builder 或 Sequencer 沒有履行承諾時便可將承諾內(nèi)容及對方的簽名送至智能合約，智能合約便可以檢查承諾是否有被履行（例如「在第 1350000 區(qū)塊收入這筆交易」）。

雖然上述合約的應(yīng)用場景還在概念驗證階段，但下方鏈接展示的演講視頻里講述了是其中一個合約應(yīng)用的例子，詳情請復(fù)制下方鏈接到瀏覽器查看：https://www.youtube.com/watch?v=Uw5HxSYXwYo

總結(jié)

• L1 交易被收入進(jìn) L1 區(qū)塊后，發(fā)生 Re-org 的概率會逐漸降低，用戶對交易被收入的信心會逐漸上升。
• L2 交易比 L1 交易多出的一個交易工作流程是：「L2 交易被收進(jìn) L2 區(qū)塊，并等待被上傳至 L1」的階段。
• 但在 L2 交易相比 L1 交易多出的交易工作流程中，由于在這個階段，數(shù)據(jù)還沒上傳至 L1，依舊存在變量發(fā)生的可能，因此使用者在此階段所能獲得的、關(guān)于交易收入的保證就是 Sequencer 的口頭承諾，稱為 Pre-Confirmation 或 Fast Confirmation、Soft Confirmation。
• ?如果 Sequencer 是惡意的，或是單純出現(xiàn) Bug，那?Sequencer 給出的承諾就有可能被違背，導(dǎo)致用戶的 L2 交易沒有收入確認(rèn)。
• 目前，大部分 L2?在其 Explorer 里呈現(xiàn)的交易狀態(tài)都包含有 Pre-Confirmation 的狀態(tài)，例如 Arbitrum/Optimism 的 Confirmed by Sequencer 或 StarkNet 的 Accepted on L2。大家看到這樣的信息時，請注意關(guān)注這些信息所提供的交易收入保證的時間效力。
• 如果不想信任 Sequencer 提供的 Pre-Confirmation，那就需要等待久一點(diǎn)時間，并透過 L2 Explorer 所提供關(guān)于 L2 數(shù)據(jù)被上傳到 L1 的信息去進(jìn)行驗證。
• Pre-Confirmation 可以加上經(jīng)濟(jì)激勵機(jī)制的設(shè)計，例如在 Sequencer 違反承諾時，可以通過智能合約進(jìn)行懲罰，讓使用者獲得更明確的保障。

下方表格展示的是 L1 交易 與 L2 交易在不同的交易流程階段提供的交易收入保證和相對應(yīng)的風(fēng)險情形：