共享測序器下的跨 Rollup 原子性：狀態鎖與 2PC 如何避免狀態割裂

共享排序不等於跨鏈原子性

共享測序器（Shared Sequencer）的核心價值，是讓多個 Rollup 或應用鏈在同一個排序層裡獲得一致的輸入順序。這個能力能降低跨鏈搶跑、縮短預確認延遲，併為跨 Rollup 組合交易提供更好的時間基礎。但它不能自動保證“Rollup A 成功執行，Rollup B 也一定成功執行”。排序層只決定交易進入各執行層的相對順序；狀態轉換仍由每個 Rollup 的 VM、賬戶模型、gas 規則、合約邏輯和結算機制分別決定。

對 [AllSwap 跨鏈交換](/exchange-swap) 這類路由入口，這個差異很關鍵。使用者提交的不是“在兩個 Rollup 上各執行一筆交易”，而是一個整體目標：資產從 A 鏈釦除、B 鏈到帳、失敗時可退款。如果共享測序器只能給出一個統一排序，但不能處理其中一條鏈執行失敗後的補償，使用者仍會遇到狀態割裂：A 鏈已鎖定或扣款，B 鏈因為 gas、狀態衝突、合約暫停或證明延遲沒有完成到帳。第五篇聚焦的就是這個底層問題：共享測序器網絡怎樣與跨 Rollup 狀態鎖、條件收據和兩階段提交（2PC）組合，才能把“同一批交易被排序”推進到“同一組狀態要麼全部提交，要麼全部回滾”。

系統邊界：排序層、執行層和結算層不是同一個東西

本文討論跨 Rollup 原子互操作，不討論中心化交易所內部記賬，也不假設 AllSwap 已實現共享測序器。系統包含五個角色：

- 使用者或路由器 `U`：提交跨 Rollup 意圖，例如 A 鏈釦款、B 鏈兌換、C 鏈收款； - 共享測序器 `Q`：對多條 Rollup 的交易輸入給出統一順序或預確認； - Rollup 執行層 `E_i`：獨立執行本鏈交易，生成本地狀態根和收據； - 結算層 `L1`：接收 Rollup batch、證明或欺詐挑戰； - 協調合約 `C`：記錄條件鎖、收據證明、超時和補償狀態。

最小原子性目標可以寫成：

`commit(T) = all(success_i) OR rollback(all prepared_i)`

其中 `T` 是一個跨 Rollup 事務，`success_i` 表示第 `i` 條 Rollup 的本地執行已提交，`prepared_i` 表示該鏈已經進入可回滾的準備狀態。共享測序器只能幫助所有 `E_i` 看到同一個 `T` 的順序關係；它不能單獨證明 `success_i`，也不能替每條鏈回滾狀態。真正的協議設計必須把排序、執行收據和回滾權利拆開建模。

條件狀態鎖：跨 Rollup 2PC 的最小原語

傳統分佈式系統裡的兩階段提交有兩個階段：prepare 和 commit。把它遷移到 Rollup，需要把“數據庫行鎖”替換成“鏈上條件狀態鎖”。在 A 鏈上，使用者資產不是立即轉出，而是進入 `locked(intentId, amount, timeout)`；在 B 鏈上，目標操作不是立即視為最終，而是生成一個 `prepared(intentId, receiptRoot)`；當所有參與鏈都給出有效 prepare 收據後，協調合約或應用邏輯再觸發 commit。若超時，所有已 prepare 的鏈走 rollback。

這個模型可以表示為：

1. `order(intentId)`：共享測序器把跨 Rollup 意圖放入統一順序。 2. `prepare_i(intentId)`：每條 Rollup 在本地執行預檢查和條件鎖。 3. `receipt_i = prove(prepared_i)`：生成可驗證準備收據。 4. `commit(intentId)`：收據集合滿足閾值，所有鏈進入最終提交。 5. `abort(intentId)`：任一鏈失敗或超時，已鎖狀態釋放或補償。

關鍵是 prepare 必須是可撤銷狀態，而不是不可逆資產轉移。若 A 鏈在 prepare 階段已經把資產完全轉給做市商，B 鏈失敗後就只能依賴外部信用補償；這不是原子性，而是賒賬。條件鎖的作用是把資產、權限或狀態變更掛起在一個明確的 `intentId` 下，直到足夠收據證明所有參與方都準備好。

在鏈上實現時，prepare 還必須限制可見副作用。一個合約不能在 prepare 階段先調用外部未知合約，再把自己標成可回滾；否則外部副作用已經擴散，rollback 只回滾本合約狀態，沒有回滾組合交易的真實經濟影響。更穩健的做法是把 prepare 限制為資產鎖定、額度預留、對象版本凍結和最小狀態承諾，等 commit 階段再執行不可逆轉賬。這個約束會犧牲一部分資本效率，但能把失敗邊界壓在可驗證狀態內。

為什麼共享測序器仍然需要收據證明

Espresso、Astria 這類共享排序或確認層的共同方向，是把多個 Rollup 的交易輸入放在同一排序網絡中，減少每條鏈獨立中心化 sequencer 帶來的審查和排序割裂。Astria 文檔強調共享測序層允許多個 Rollup 共享一個去中心化 sequencer 網絡；Espresso 的全局確認層強調為一組可組合鏈提供快速、可驗證的輸入確認。這些能力改善的是輸入一致性。

但執行一致性仍然缺口很大。Rollup A 可能是 EVM，Rollup B 可能是 SVM 或 Move 風格對象模型；A 鏈某個合約 `prepare()` 成功，不代表 B 鏈的賬戶鎖、對象版本、gas 上限或 oracle 狀態也滿足條件。共享測序器看到的是交易包，不是每條鏈執行後的真實狀態根。

因此跨 Rollup 2PC 至少需要三類收據：

- 排序收據：證明該跨鏈事務在共享測序器中處於某個全局位置； - 執行收據：證明某條 Rollup 已經進入 prepared 或 committed 狀態； - 結算收據：證明該執行結果最終能被 L1 或對應結算層接受。

缺少執行收據，排序只是意圖；缺少結算收據，執行只是本地樂觀狀態；缺少超時規則，失敗路徑會永久掛起。

收據還要綁定排序上下文。一個 Rollup 本地的 `prepared(intentId)` 只有在它引用了共享測序器給出的全局 slot、批次 hash 或確認證書時，才具有跨 Rollup 語義。否則攻擊者或故障協調者可以把某條鏈上獨立產生的準備狀態拼接進另一個跨鏈事務，形成收據重放。最低限度，收據應包含 `intentId, rollupId, globalOrderRoot, localStateRoot, phase, deadline`，並通過本鏈證明系統或結算層可驗證。

狀態鎖的數據結構

一個跨 Rollup 狀態鎖不應只是布爾值。它至少要包含：

- `intentId`：跨 Rollup 事務唯一 ID； - `participants`：參與 Rollup 和合約列表； - `phase`：`ordered | prepared | committed | aborted | expired`； - `deadline`：最晚提交或回滾時間； - `assetLocks`：每條鏈鎖定的資產或權限； - `receiptRoots`：各鏈 prepare/commit 收據根； - `refundTo`：失敗退款地址或補償賬戶； - `slashableBond`：Solver、relayer 或 coordinator 的保證金。

這種結構使失敗可歸因。若 B 鏈未在 deadline 前提交 prepare receipt，A 鏈鎖定資產可以按 `refundTo` 釋放；若協調者已收齊收據卻不提交 commit，可以罰沒其保證金；若某條鏈提交偽造收據，則由該鏈的證明系統或結算層承擔安全責任。對跨鏈交換而言，狀態鎖不是 UX 細節，而是退款能否自動化的前提。

狀態鎖還需要垃圾回收。跨鏈系統最容易被忽視的問題是“失敗交易留下多少鏈上殘留”。如果每個 expired intent 都永久佔用存儲槽，攻擊者可以用低成本小額意圖製造狀態膨脹。合理設計應把 lock record 拆成熱狀態和可歸檔事件：活躍鎖保留在合約狀態中，過期或完成後只保留最小 replay protection 和可索引事件。這樣既能防止同一 `intentId` 重放，又不會讓協調合約變成長期垃圾桶。

共享測序器、加密 mempool 和 MEV

共享測序器還會改變 MEV 分配。若多條 Rollup 的交易在同一排序層中可見，跨 Rollup 套利、清算和路由都可能被更早觀察。Radius 提出的加密 mempool、PVDE/SKDE 等方向，是讓 sequencer 先承諾順序，再在延遲後看到交易內容，降低排序層自身夾擊使用者的能力。Optimism Superchain interop 也把跨鏈消息傳遞作為統一使用者體驗的核心，但其文檔仍明確相關 interop 特性處於開發和實驗語境。

這說明跨 Rollup 原子性有兩條線同時推進：一條是排序公平性，另一條是執行原子性。加密 mempool 可以降低“先看內容再排序”的 MEV；2PC 和狀態鎖解決“已經排序但某條鏈執行失敗”的一致性。把二者混為一談會導致錯誤安全感：盲排序不等於可回滾，統一排序不等於全局提交。

還有一個更現實的約束：共享測序器本身也可能是軟確認層。它給出的確認可能先於 Rollup batch 被 DA 層發佈，也先於 L1 結算層最終接受。對低價值應用，軟確認足以改善體驗；對跨鏈資產釋放，軟確認只能作為 prepare 信號，不能直接作為最終 commit 依據。否則一旦排序層確認與後續 DA/結算結果不一致，應用已經釋放資產，卻無法在結算層證明對應狀態。

失敗模式：狀態割裂從哪裡發生

第一類失敗是單鏈執行失敗。共享測序器已排序，但某條 Rollup 因 gas 不足、合約暫停、賬戶鎖衝突、對象版本過期或 oracle 狀態變化導致 prepare 失敗。防禦方式是 prepare 前做靜態模擬，prepare 後要求可驗證執行收據，並在 deadline 後自動 abort。

第二類失敗是收據延遲。某鏈已經 prepared，但收據證明沒有及時送到協調合約。若 deadline 過短，正常交易被誤回滾；若 deadline 過長，使用者資金被鎖太久。合理設計要把每條鏈的出塊、證明、DA 和結算延遲納入超時參數。

第三類失敗是協調者作惡。Solver 或 relayer 可能選擇性提交對自己有利的收據，或在市場變化後故意拖延 commit。保證金、可罰沒行為和任何人可提交收據的 permissionless relay，是降低這一風險的基本手段。

第四類失敗是結算層分叉或挑戰成功。某條 Rollup 的 prepared 收據先被本地接受，後續在 L1 上被挑戰或重組推翻。跨 Rollup commit 如果過早執行，就會讓另一條鏈進入不可逆狀態。因此，高價值路徑不能只依賴軟確認；需要等待足夠結算安全或引入經濟保證金覆蓋回滾風險。

第五類失敗是死鎖。多個跨 Rollup 事務相互佔用同一資產池、賬戶或對象，形成鎖等待環。數據庫用 wait-for graph 檢測死鎖；鏈上系統可以用 `intentId`、資源 ID 和 deadline 構建鎖依賴圖。最保守策略是按全局順序只允許低序號意圖佔用衝突資源，犧牲併發換確定性。

第六類失敗是部分 commit。協調者收齊了 A、B 兩鏈 prepare receipt，但 commit 消息只在 A 鏈成功，在 B 鏈因為 gas 或擁堵失敗。解決辦法不是假設 commit 一定成功，而是把 commit 本身也設計成冪等狀態機：重複提交同一個 `commit(intentId)` 不改變結果，任何人都可以補交缺失 commit，且 commit 失敗不會銷燬 rollback 證據。否則系統會從 prepare 階段的狀態割裂，轉移到 commit 階段的狀態割裂。

第七類失敗是流動性鎖倉攻擊。攻擊者可以提交大量接近真實報價的小額跨 Rollup 意圖，讓多個鏈上池子進入 prepared 狀態，再故意不完成某條鏈的收據，消耗做市商庫存和使用者可用額度。防禦不只是收取手續費，還需要按鎖定名義金額、鎖定時間和資源衝突度動態計算保證金。

對 AllSwap 路由的工程含義

AllSwap 路由不需要向使用者展示完整 2PC 協議，但需要把原子性等級納入報價。一個跨 Rollup 路徑可以被標成四類：

- `best-effort`：各鏈獨立執行，失敗靠人工或外部補償； - `sequenced`：共享測序器保證輸入順序，但不保證執行回滾； - `prepared`：目標鏈能提供條件鎖和 prepare receipt； - `atomic-settlement`：所有參與鏈有統一 commit/abort 規則和可驗證退款。

這會影響 [AllSwap 費用](/fees) 和路由選擇。最低費用路徑不一定是最安全路徑；對大額訂單，prepared 或 atomic-settlement 級別的路徑可能值得更高費用和更長等待。對小額、低風險資產，使用者可以接受 best-effort 或 sequenced 路徑換取速度。路由器應把原子性等級、預計鎖定時間、失敗退款依據和保證金覆蓋範圍作為內部評分，而不是隻展示一個預估到帳時間。

一個可執行的路由評分模型

可以用簡化模型表達：

`routeScore = priceScore + latencyScore - atomicityPenalty - refundPenalty - liquidityLockPenalty`

其中 `atomicityPenalty` 來自路徑是否支持 prepare/commit/abort；`refundPenalty` 來自失敗後是否有鏈上退款證明；`liquidityLockPenalty` 來自資產被條件鎖佔用的時間和機會成本。若某條路徑只提供共享排序但沒有執行收據，它的 `atomicityPenalty` 不能為零。若某條路徑有強原子性但需要等待 L1 結算，`latencyScore` 會下降。

對使用者來說，最終表達可以很簡單：到帳更快但失敗補償較弱，或到帳稍慢但退款依據更強。對工程系統來說，這背後需要完整狀態機。每筆跨 Rollup swap 都應該能查詢：

- 當前 phase； - 哪些鏈已 prepared； - 哪些收據已提交； - deadline 還剩多久； - 失敗時 refundTo 是誰； - 是否有可罰沒保證金。

如果這些字段不存在，產品就無法在異常時給出確定答案。

這也影響 Solver 競爭。若 Solver A 給出更低報價但只使用 best-effort 路徑，Solver B 報價稍高但提供 prepared receipt、保證金和鏈上 refund path，路由器不應簡單選擇 A。跨鏈路由的真實目標函數應包含“失敗後的可驗證性”。否則價格競爭會把市場推向低成本、低保障路徑，直到一次異常狀態割裂把使用者體驗徹底暴露。

對 [AllSwap 資產頁](/assets/usdc) 這類入口，原子性等級還會影響資產語義。使用者收到的可能不是最終到帳資產，而是某個 pending claim、prepared receipt 或 solver IOU。若產品把這些狀態都顯示成“到帳中”，就會掩蓋真實風險。更好的做法是把狀態拆成 ordered、prepared、settling、refundable、completed，讓使用者和客服都能基於同一狀態機溝通。

retry 機制也要被顯式設計。跨 Rollup commit 失敗後，系統不應重新生成一個新意圖來“再試一次”，因為新意圖會繞開舊鎖和舊收據，製造重複釋放風險。正確做法是允許任何 relayer 對同一個 `intentId` 重放冪等 commit 或 abort，直到狀態進入終態。這樣即使原協調者離線，使用者或第三方也能用已有收據推動流程結束。

同時，checkpoint 選擇必須和金額相關。小額路徑可以接受共享測序器軟確認加保證金覆蓋；大額路徑應等待 DA 發佈、Rollup 狀態根或 L1 結算證明。把所有訂單放進同一個等待窗口，會同時傷害安全和體驗，也會誤導使用者判斷真實風險，尤其是在高波動行情中。

開放問題

第一，跨 Rollup 收據標準尚未統一。EVM event、OP Stack interop message、Cosmos IBC packet、Move object event 和 Solana account proof 都有不同語義。沒有統一收據格式，2PC 協調合約很難跨生態複用。

第二，軟確認和硬結算之間的風險定價仍不成熟。共享測序器給出的快速確認對 UX 很有價值，但高價值資產釋放可能仍要等待 L1 結算或欺詐窗口。如何按金額、資產、鏈風險動態選擇等待窗口，是路由器必須解決的問題。

第三，狀態鎖會消耗流動性。大量 prepared 但未 committed 的交易會佔用池子、做市商庫存和使用者資金。原子性越強，資金佔用越重；系統需要在安全和資本效率之間定價。

第四，去中心化協調者市場還沒有成型。誰負責提交收據、誰支付 gas、誰提供保證金、誰在失敗時被罰，都會影響 Solver 和 relayer 的經濟激勵。

第五，跨 VM 回滾語義不一致。EVM 可以鎖 ERC-20，Move 可能鎖對象能力，SVM 依賴賬戶寫鎖。把這些抽象成統一 `prepare/commit/abort` 接口，需要比普通跨鏈消息更嚴格的應用層規範。

References

[1] Astria Documentation, Astria, 2026, https://docs.astria.org/

[2] Astria GitHub Repository, Astria, 2026, https://github.com/astriaorg/astria

[3] Espresso Network Repository, Espresso Systems, 2026, https://github.com/EspressoSystems/espresso-network

[4] Espresso FAQ, Espresso Systems, 2026, https://www.espressosys.com/faq

[5] The Espresso Sequencer, Espresso Systems, 2025, https://hackmd.io/@EspressoSystems/EspressoSequencer

[6] OP Stack Interop Message Passing Overview, Optimism Docs, 2026, https://docs.optimism.io/app-developers/guides/interoperability/message-passing

[7] Radius SKDE: Enhancing Rollup Composability with Trustless Sequencing, Radius, 2024, https://ethresear.ch/t/radius-skde-enhancing-rollup-composability-with-trustless-sequencing/19185

[8] Based Espresso: ad-hoc shared sequencing for all L2s, Espresso Systems, 2024, https://hackmd.io/@EspressoSystems/BasedEspresso

[9] Astria: The Shared Sequencer Network, Astria, 2024, https://hackmd.io/@astriaorg/HJ6cCpp9T

[10] Bernstein, Hadzilacos, Goodman, Concurrency Control and Recovery in Database Systems, 1987, https://www.microsoft.com/en-us/research/publication/concurrency-control-and-recovery-in-database-systems/