L2交易實現全流程解析:各階段安全性分析

L2交易相比L1交易多了一個重要步驟:等待L2區塊被上傳至L1。在這個階段,由於數據還未上傳L1,存在不確定性,用戶只能依賴Sequencer提供的"口頭承諾",即Pre-Confirmation。

主流L2解決方案的交易確認流程如下:

Arbitrum/Optimism

交易發送後,用戶幾乎立即獲得交易收據,表明Sequencer已本地排序並模擬執行。這是一種Pre-Confirmation。

Arbitrum Explorer顯示:

• "Confirmed by Sequencer":僅由Sequencer確認,未上傳L1
• "X L1 Block Confirmations":已上傳L1,後續接X個區塊

Optimism Explorer顯示:

• "Confirmed by Sequencer":Sequencer已確認
• "L1 State Batch Index"和"L1 State Root Submission Tx Hash":批次上傳L1信息
• "Finalized":對應L1的Finalized狀態

StarkNet

交易狀態流程:

1. Received:交易已接收並驗證
2. Pending:Sequencer處理中
3. Accepted on L2:已進入L2區塊
4. Accepted on L1:數據已上傳L1

由於生成零知識證明耗時,上傳L1需等待4-5小時,用戶較長時間依賴Pre-Confirmation。

zkSync

交易狀態流程:

1. PENDING:等待Sequencer處理
2. zkSync Era Processed:已進入L2區塊
3. Committed:區塊已上傳L1
4. Proven:區塊有效性已證明
5. Executed:L2狀態更新至L1

zkSync將L2到L1過程細分爲3個階段,提供更詳細的狀態展示。

總結

• L2交易多了"等待上傳L1"的步驟
• 該階段用戶依賴Sequencer的Pre-Confirmation
• 大部分L2 Explorer都展示Pre-Confirmation狀態
• 完全確認需等待L2數據上傳L1
• Pre-Confirmation可加入經濟激勵機制提高可靠性

不同階段的交易確認保證及風險:

| 階段 | L1交易 | L2交易 | |------|--------|--------| | 交易發出 | 無保證 | 無保證 | | 進入mempool | 輕微保證 | 輕微保證(如有) | | Pre-Confirmation | - | Sequencer承諾 |
| 進入區塊 | 較強保證 | L2較強保證 | | 上傳L1 | - | L1較強保證 | | 多個確認 | 非常強保證 | 非常強保證 | | Finalized | 最強保證 | 最強保證 |