共享测序器下的跨 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/