嵌套 ZK 證明下的 L3 結算：跨 L2/L3 互操作為何仍有退款風險

L3 的快，不等於結算風險消失

模組化 Layer 3（應用級 Rollup）的吸引力很明確：它可以把執行環境、費用模型、資料可用性和應用狀態做得更專用，甚至在某個 L2 之上繼續擴充套件。問題也同樣直接：L3 的狀態最終要透過 L2 再進入 L1，結算鏈路比普通 L2 更長。若沒有巢狀 ZK 證明（Nested ZK Proof）或遞迴證明聚合，L3 的互操作就會在“使用者看到已完成”和“結算層真正可驗證”之間留下很大的時間差。

對 [AllSwap 跨鏈交換](/exchange-swap) 來說，L3 不是“更便宜的另一條鏈”這麼簡單。跨 L2/L3 交換需要回答：目標 L3 的預確認是否可被撤銷？L3 proof 什麼時候被 L2 接受？L2 proof 什麼時候被 L1 接受？如果中間某層卡住，使用者退款、Solver 墊付和資產退出應依賴哪個狀態根？這些問題決定大額交易能否走快軌，還是必須等待完整證明鏈。

本文討論模組化 L3 的證明結算模型，不把所有應用鏈、側鏈和中心化執行環境混在一起。核心結論是：巢狀證明可以壓縮驗證成本和縮短最終可驗證路徑，但它不會消除資料可用性、欄位轉換、排序器預確認、跨層訊息時鐘和退款歸因問題。

系統模型：三層狀態根和兩級證明

一個典型 L3 結算鏈路可以抽象為：

- L3 應用 Rollup `R3`：執行使用者交易，生成狀態根 `root3_t`； - L2 結算層 `R2`：接收 L3 批次、驗證或聚合 L3 proof； - L1 終局層 `R1`：驗證 L2 proof，提供最終經濟安全； - 證明者 `P3/P2`：分別生成 L3 proof 和 L2 聚合 proof； - 使用者、Solver、路由器：依賴不同層的狀態完成交換、退款或再平衡。

普通鏈路可寫成：

`tx -> root3_t -> proof3 -> root2_t -> proof2 -> root1_t`

若每個 L3 proof 都單獨提交給 L2，L2 再把自己的批次提交到 L1，結算延遲和驗證開銷會疊加。巢狀證明的目標，是讓外層證明驗證內層 proof 的正確性，把許多 L3 狀態轉移壓縮排一個 L2 可接受的證明，再由 L2 的證明進入 L1。

形式化地說，L2 不需要重新執行 L3，只需要驗證一個宣告：

`Verify3(proof3, vk3, oldRoot3, newRoot3, publicInputs3) = true`

然後 L2 把這個驗證過程作為自己證明電路的一部分：

`Verify2(proof2, vk2, oldRoot2, newRoot2, commitment(proof3_result)) = true`

難點在於，`Verify3` 本身可能很貴。外層電路若要驗證內層 verifier，必須處理驗證金鑰、public inputs、雜湊、承諾開啟和欄位運算。遞迴證明的價值，是讓“驗證一個證明”的成本足夠小，才有可能把多層狀態壓進一個終局證明裡。

巢狀證明的核心成本：驗證器也要被算術化

在普通 ZK 系統裡，鏈上 verifier 是一段合約或虛擬機器程式；在遞迴場景裡，這段 verifier 要變成另一個證明系統裡的電路。也就是說，外層證明不只是驗證交易執行，還要證明“我正確驗證了內層證明”。

這會帶來三類成本。

第一，欄位不匹配。若內層 proof 使用某個曲線或有限域，外層 proof 的基礎域不同，外層電路就要模擬非原生欄位運算。每一次標量乘法、配對檢查、雜湊置換或多項式承諾開啟，都可能膨脹成 limb、range check、carry 和約束集合。

第二，驗證金鑰體積。`vk3` 不能隨意變動，否則外層電路要支援多種 verifier。固定應用 L3 可以把驗證金鑰硬編碼進聚合電路，降低靈活性換取成本；通用 L3 平臺若允許每條應用鏈不同電路，就需要驗證金鑰註冊、版本管理和電路升級規則。

第三，public inputs 繫結。內層 proof 必須繫結 chainId、L3 id、批次編號、old root、new root、訊息根、withdrawal root 和 DA commitment。若繫結不完整，攻擊者可能把一個上下文中有效的 proof 複用到另一個 L3 或另一個批次。

遞迴證明不是“多套 proof 套娃”這麼簡單，它更像一個嚴格的狀態壓縮協議。每一層都要明確哪些變數進入 public inputs，哪些狀態根被上層接受，哪些訊息可以跨層消費，哪些失敗可以回滾。

批次聚合還會引入順序問題。假設一個 L2 聚合批次同時包含 20 條 L3 的 proof，其中某一條 L3 的 proof 生成延遲或驗證失敗。聚合器可以跳過該 L3，也可以等待它補齊。跳過能減少整體延遲，但該 L3 上的使用者會落後一個結算週期；等待能保持跨 L3 批次整齊，卻會讓一個應用鏈拖慢全部聚合。對路由器而言，`proofLag` 不只是某條鏈的平均證明時間，還包含聚合器的批次排程策略。

更麻煩的是驗證金鑰升級。應用 L3 往往希望快速升級 VM、費用模型或業務電路，但遞迴聚合電路依賴內層驗證金鑰。如果 `vk3` 發生變化，外層電路必須知道新版本，並防止舊訂單在新規則下被解釋。穩健設計應讓每筆跨層訊息繫結 `vkVersion`、`l3ChainId`、`batchId` 和 `stateTransitionType`。否則舊 proof 和新 proof 可能在同一訊息通道中出現語義衝突。

資源瓶頸也會從鏈上 gas 轉移到鏈下證明網路。L3 proof 生成、遞迴聚合、外層 proof 最終壓縮，可能分別由不同證明者完成。若某個應用 L3 的證明任務過大，聚合器需要決定是等待、跳過、還是把它拆成更小批次。等待增加全域性延遲；跳過影響該 L3 使用者；拆批次增加 proof 數量和訊息管理複雜度。證明聚合降低鏈上驗證成本，但不會讓 CPU、GPU、記憶體和證明者排程成本消失。

快軌互操作依賴預確認，但預確認不是最終性

L3 互操作通常會引入快軌。目標鏈或 Solver 可以基於 L3 排序器預確認（pre-confirmation）先給使用者到帳，隨後等待證明鏈補齊。這樣使用者體驗接近秒級，但安全性取決於預確認的可撤銷邊界。

可以把交易狀態分成四層：

- `preconfirmedOnL3`：L3 排序器承諾會包含交易； - `provedToL2`：L3 proof 被 L2 接受； - `includedInL2Proof`：L2 聚合 proof 包含該 L3 狀態； - `finalizedOnL1`：L1 接受最終證明或達到終局條件。

對小額交換，路由器可以讓 Solver 承擔預確認風險；對大額交換，必須等待 `provedToL2` 或更高層級。把四個狀態都展示成“已完成”，會把結算風險隱藏給使用者和 Solver。

預確認風險可以寫成：

`expectedLoss = amount * P(reorg_or_noninclusion) * recoveryDelayCost`

這裡的 `P` 不是固定常數，它取決於 L3 排序器去中心化程度、L2 接受視窗、DA 模式、證明者延遲和是否有強制入隊/逃生路徑。快軌越激進，使用者體驗越好，Solver 承擔的庫存和退款風險越高。

預確認還會產生排序器合謀問題。若 L3 排序器給 Solver 一個私下預確認，Solver 在目標鏈付款，但排序器隨後沒有把交易納入可證明批次，Solver 只能依賴法律協議或聲譽追償。若預確認是公開承諾並寫入 L2 可見佇列，Solver 至少可以證明排序器違約。兩種預確認在 UI 上都可能顯示“秒級到帳”，但風險完全不同。

因此，快軌不應只有一個布林開關。路由器需要記錄預確認的來源、是否公開、是否可懲罰、是否繫結批次、是否有強制包含路徑。小額交易可以接受弱預確認，因為恢復成本低；大額交易應要求可公開驗證的預確認，或者直接等待 L2 proof。把這些差異折算成報價，比在事故後解釋“為什麼這筆到帳被撤銷”更可控。

跨層訊息和退款狀態機

L3 到 L2/L1 的跨層訊息至少要繫結四個物件：源狀態根、訊息根、消費標記和超時視窗。一個跨 L3 交換失敗時，退款不能只看目標鏈是否到帳，還要看訊息是否被上層接受。

最小狀態機可以寫成：

`LockedOnSource`

`PreconfirmedOnTargetL3`

`ProvedToSettlementL2`

`FinalizedOrRefundable`

`Refunded`

關鍵轉移是：

`refund(orderId) allowed iff now > deadline && !consumed[messageId] && proofOfNonFinalization(orderId)`

如果沒有 `proofOfNonFinalization`，使用者可能在目標 L3 已經收到資產後，又在來源鏈拿退款；如果沒有 `consumed[messageId]`，同一條跨層訊息可能被重複消費；如果 deadline 沒有繫結來源鏈和目標鏈時鐘，網路擁堵或證明延遲會製造爭議。

對 AllSwap，這意味著跨 L3 路由的狀態不能只記錄一筆交易雜湊。它至少應記錄 `l3BatchId`、`proof3Status`、`l2AggregationStatus`、`finalityLevel`、`refundDeadline` 和 `messageConsumed`。這些欄位決定使用者應等待、退款、補交證明，還是讓 Solver 繼續承擔風險。

`proofOfNonFinalization` 本身也不容易。鏈上合約擅長驗證“某事件存在”，不擅長驗證“某事件在某時間前沒有最終完成”。實現上通常要藉助超時、可挑戰視窗或上層狀態根：如果 deadline 之後仍沒有可驗證的 `messageConsumed`，來源鏈允許退款；如果之後目標證明到達，必須被拒絕或轉入仲裁。這個規則必須在訂單建立時確定，不能在失敗後臨時判斷。

訊息消費順序同樣重要。若 L3 到 L2 的訊息已被 L2 消費，但 L2 到 L1 的證明尚未終局，來源鏈是否允許退款？保守模式等待 L1 終局，速度慢；激進模式在 L2 消費後承認完成，速度快但承擔 L2 結算風險；折中模式讓 Solver 先付款，使用者狀態顯示為“已墊付，待終局”。這三個模式對應不同費用，不應混在同一個“完成”狀態裡。

資料可用性和 L3 專用化的取捨

L3 的一個賣點是應用專用。遊戲、交易、支付、隱私應用可以選擇不同 VM、不同 DA、不同費用模型。專用化會提高效率，也會讓路由器更難統一評估風險。

如果 L3 使用 Rollup 模式，外部可以從上層恢復狀態資料，退出和退款路徑更清晰，但成本更高。若 L3 使用 Validium 或外部 DA，交易更便宜，狀態恢復則依賴 DA 服務或委員會。若 L3 把資料放在 L2 之外，L2 接受 L3 proof 並不代表使用者一定能拿到 witness。

這和第 48 篇討論的 DAC 風險相同，只是多了一層證明巢狀。一個 L3 proof 可以證明某個 `newRoot3` 有效，但如果資料不可用，使用者依舊可能無法構造退出 proof。遞迴不會修復資料可用性；它只壓縮驗證路徑。

因此，L3 路由需要同時看兩個維度：

- 證明最終性：proof3 是否被 L2 接受，proof2 是否進入 L1； - 資料恢復性：使用者、錢包、索引器或路由器能否恢復狀態 witness。

低費用路徑如果只有前者沒有後者，適合小額高頻交易，不適合大額跨鏈結算。

還有一個儲存層問題。應用 L3 可能只儲存業務相關狀態，例如訂單簿、遊戲資產或支付餘額；跨鏈退款需要的卻是跨層訊息 root、使用者餘額 leaf、消費標記和歷史批次索引。如果 L3 為了效能裁剪歷史資料，使用者可能在證明鏈最終完成前就失去構造退款 witness 的材料。L3 的歸檔策略因此也是路由風險的一部分。

對使用外部 DA 的 L3，資料可恢復性應像費用一樣進入報價模型。一個路徑可能在執行上極快，但 witness 下載需要依賴第三方 DA、DAC 或少數索引器。遞迴 proof 只證明狀態有效，不證明這些 witness 在使用者需要時可下載。對 AllSwap，最小要求是能在訂單級別儲存足夠的恢復材料：來源鏈鎖定 proof、目標 L3 填單 proof、訊息消費狀態和退款 deadline。

對 AllSwap 路由的影響

AllSwap 可以把 L3 路由拆成三種風險級別。

- `fast-l3-fill`：基於 L3 預確認或 Solver 信用先到帳； - `l2-proved-fill`：等待 L3 proof 被 L2 接受後再視為較安全； - `l1-finalized-fill`：等待完整證明鏈進入 L1 後再承認終局。

報價公式可以寫成：

`routeScore = priceScore + speedScore - proofLagPenalty - daPenalty - refundAmbiguity`

`proofLagPenalty` 來自巢狀證明生成和聚合延遲，`daPenalty` 來自 L3 資料可用性模式，`refundAmbiguity` 來自失敗後能否證明未最終完成。對 [/fees](/fees) 來說，L3 費用不只是 gas，還包括證明延遲、Solver 預墊庫存成本和失敗恢復成本。對 [/swap/usdt-erc20](/swap/usdt-erc20) 與 [/assets/usdc](/assets/usdc) 這類穩定幣路徑，大額交易應避免只看快軌報價。

UI 不必展示所有證明細節，但應區分“目標 L3 已預確認”“已被 L2 證明”“已在 L1 終局”。這三個狀態對使用者資產安全不是同一件事。若路徑只達到預確認，使用者看到的到帳更像 Solver 信用；若已經 `provedToL2`，風險轉移到 L2/L1 結算；若已 `finalizedOnL1`，退款爭議才真正收斂。

後臺風控可以進一步拆成限額規則。`fast-l3-fill` 適合低額、高頻、可由 Solver 承擔短期信用風險的交易；`l2-proved-fill` 適合中等金額，需要證明已進入 L2 結算軌道；`l1-finalized-fill` 適合高價值資產、機構級再平衡或對退款確定性要求極高的路徑。這樣使用者不必學習遞迴證明，系統也不會把同一條 L3 路徑當成所有金額都適用。

監控指標也應具體：`proof3Lag`、`aggregationQueueDepth`、`vkVersionMismatch`、`daRecoveryErrorRate`、`preconfirmReorgRate`、`refundDisputeCount`。如果 proof3 延遲上升，路由器應降低快軌額度；如果驗證金鑰版本不匹配，應暫停新訂單；如果 DA 恢復失敗率上升，應停止承諾即時退款。這些規則越自動化，異常時越少依賴人工客服解釋複雜狀態。

失敗模式至少有四類。第一，L3 執行成功但 proof3 遲遲不生成，使用者看到目標鏈狀態變化，來源鏈卻不能確認最終完成。第二，proof3 已生成但 L2 聚合佇列擁堵，Solver 庫存被佔用，報價會變差。第三，L2 聚合 proof 被 L1 延遲接受，退款和最終性之間出現長視窗。第四，L3 資料不可用，遞迴證明鏈可能仍能驗證某些狀態根，但使用者無法構造訂單級 witness。每一類失敗都需要不同恢復動作，不能只用一個 `pending` 狀態覆蓋。

對產品而言，最重要的是把這些失敗分解成可執行動作：等待證明、切換慢軌、降低額度、發起退款、提交 witness、或轉入人工審計。若路由層缺少這些狀態，巢狀證明越複雜，使用者越難理解自己是否安全。AllSwap 的角色不是承諾所有 L3 都同樣可靠，而是把證明鏈長度、DA 模式、預確認強度和退款可驗證性轉換成可比較的路由結果。

金額分層應成為預設策略。低額交易可以優先速度，把預確認風險交給報價和限額吸收；中額交易應等待 L2 接受 L3 proof；高額交易需要 L1 終局或等價的保險/保證金覆蓋。這樣快軌不是被禁用，而是被放在它適合的風險區間內。 否則，低費用會掩蓋結算層級差異，最終把複雜性留給退款流程。 這也是跨 L3 路由必須保留完整結算狀態的原因。 沒有這些狀態，使用者無法判斷資金處於執行、證明還是退款階段。 也無法正確評估等待成本。

仍未解決的問題

第一，遞迴證明的最終壓縮成本仍是瓶頸。L3 越多、驗證金鑰越多、public inputs 越複雜，聚合電路越難保持低延遲。

第二，跨層訊息標準不統一。L3 到 L2、L2 到 L1 的訊息根、消費標記和超時語義各不相同，聚合器難以用同一套狀態機解釋。

第三，預確認缺少機器可讀風險描述。排序器承諾、證明者 SLA、DA 模式和強制入隊能力應形成 `settlementProfile`，否則路由器只能用粗糙標籤判斷。

第四，L3 失敗後的退款歸因複雜。失敗可能發生在 L3 執行、proof3 生成、L2 聚合、L1 最終驗證、DA 恢復或 Solver 履約任一環節。沒有細粒度狀態，使用者只能看到“處理中”。

第五，應用專用 L3 的升級治理會影響 proof 安全。若驗證金鑰、VM 版本或 DA 模式可以快速升級，舊訂單和未結算訊息必須繫結升級前後的規則，否則跨鏈退款會出現語義漂移。

References

[1] ZK-Rollups, Ethereum.org, 2026, https://ethereum.org/en/developers/docs/scaling/zk-rollups/

[2] What kinds of layer 3s make sense?, Vitalik Buterin, 2022, https://vitalik.eth.limo/general/2022/09/17/layer_3.html

[3] Blockchain Layer 3, StarkWare, 2022, https://starkware.co/blog/blockchain-layer-3/

[4] Recursive Circuit Proving Efficiency, StarkWare, 2026, https://starkware.co/blog/minutes-to-seconds-efficiency-gains-with-recursive-circuit-proving/

[5] ZKsync ZK Stack, ZKsync Docs, 2026, https://docs.zksync.io/zk-stack

[6] ZKsync Chains, ZKsync Docs, 2026, https://docs.zksync.io/zk-stack/zk-chains

[7] Arbitrum Chains Introduction, Arbitrum Docs, 2026, https://docs.arbitrum.io/launch-arbitrum-chain/overview/introduction

[8] Polygon Agglayer Overview, Polygon Docs, 2026, https://docs.polygon.technology/agglayer/

[9] Celestia Data Availability, Celestia Docs, 2026, https://docs.celestia.org/learn/celestia-101/data-availability/

[10] L2BEAT Scaling Summary and Risk Framework, L2BEAT, 2026, https://l2beat.com/scaling/summary