仅供教育参考，不构成财务、投资、互操作性、交易最终性或安全建议。共享排序器的保证、备用路径和结算假设因实现而异，并可能在升级后改变。
直接答案
共享排序器是一种服务或网络，它接收多个 Rollup 的交易数据，并为这些数据生成共同认可的顺序。参与的 Rollup 从有序日志中读取分配给自己的部分，再按照各自的状态转换规则执行。排序层还可能在数据到达 Rollup 的数据可用性层和结算层之前提供快速预确认。
“共享”描述的是多个 Rollup 复用同一服务，而不是某种特定的信任模型。共享排序器可以是中心化的、由许可委员会运行的，也可以由去中心化共识保护。它本身并不能证明执行正确、保证交易数据永久可用、在父链上完成 Rollup 结算，或保证跨 Rollup 操作具有原子性。
这种设计可以分散排序基础设施，让多个 Rollup 对相对顺序形成一致视图，并减少重复运营。但在评估这些好处时，也必须考虑新增的依赖，因为它可能同时影响所有接入的 Rollup。
工作机制
- 提交。 用户、钱包或 Rollup 专用网关向共享排序层发送已签名交易或不透明交易包，通常会附带 Rollup 标识符或命名空间。
- 排序。 运营者或共识网络选择交易、决定是否纳入，并就共同的有序区块或日志达成一致。其规则决定了直接的审查、费用和 MEV 暴露面。
- 预确认。 服务可以对顺序承诺进行签名或敲定。其保证来自该实现的签名者、委员会、质押或共识假设，并不会自动成为父链最终性。
- 分发。 中继器和 Rollup 节点获取有序数据、验证承诺，并筛选属于各 Rollup 的条目。
- 执行与发布。 每个 Rollup 执行自己的交易，并按照自身协议发布数据和状态承诺。惰性共享排序器可以排列不透明字节，而不验证 Rollup 的状态转换。
- 结算。 Rollup 的证明或挑战系统、数据可用性规则、桥接合约以及父链共识共同决定执行正确性、提款和最终结算。
共同顺序让应用可以引用同一个排序事件，因此有助于跨 Rollup 协调。原子互操作仍需要额外协议逻辑来定义交易两端、验证结果，并防止或处理部分执行。仅有共享排序既不提供消息交付，也不提供回滚语义。
示例
假设某应用希望用 Rollup A 上的资产交换 Rollup B 上的资产。它把两端交易作为一个包提交给两个 Rollup 共用的排序层。排序器承诺它们的相对顺序，各 Rollup 再从同一份有序日志中派生自己的条目。
如果两个 Rollup 和互操作协议都能识别该交易包、验证共享承诺，并执行全成或全败规则，共同顺序就能帮助协调执行。如果 Rollup A 执行了自己的一端，而 Rollup B 拒绝、延迟或无法取得另一端，共享排序器并没有让这次交换具备原子性。必须由桥、证明系统、托管或其他恢复规则解决这种状态。
进行运营审查时，应把预确认、可用性发布、执行结果和父链结算作为不同状态分别跟踪。只显示“已确认”的用户界面可能掩盖实际达到的是哪一种保证。
风险
- 共因停机。 共识故障、软件缺陷、中继器问题或网络中断可能让多个 Rollup 同时停顿。每个 Rollup 都需要有成文的备用路径，以及恢复后协调顺序的规则。
- 审查与治理。 验证者、运营者、准入政策或升级权限方可能排除交易或 Rollup。如果实际参与或交易提交仍需许可，去中心化共识也无济于事。
- 排序与 MEV。 共享视图可以协调跨 Rollup 活动，但也可能集中有价值的订单流，并促成跨域抢跑、优先纳入或复杂的 MEV 提取。
- 确认错配。 排序器承诺、数据可用性确认、Rollup 执行结果与父链结算是不同的保证。如果桥和应用把最早的信号当成最强保证，资金可能遭受损失。
- 数据与集成故障。 错误命名空间、有缺陷的派生、数据不可用、不兼容升级或遭入侵的适配器，可能让 Rollup 执行错误输入或停止派生区块。
- 经济与控制集中。 共用的验证者集合、代币、客户端、RPC 服务或治理流程可能具有系统重要性。共享基础设施可以分散单个 Rollup 的运营者风险，却把生态集中到另一个层级。
常见误区
- 共享就等于去中心化。 共享只说明有多少 Rollup 使用该服务；去中心化取决于谁能验证、提议、提交、升级和恢复网络。
- 一个顺序就意味着一个状态机。 每个 Rollup 通常保留独立的执行和状态。排序器可以排列自己无法理解或不会执行的数据。
- 预确认就是父链最终性。 在所需的可用性、证明和结算步骤完成前，其强度和可逆条件来自排序协议。
- 共享排序让桥不再必要。 资产和消息在 Rollup 之间传递，仍需要经过认证的状态转换、结算逻辑和故障处理。
- 这种设计消除了 MEV 和审查。 它改变了排序权的控制者，并可能改善问责或竞争，但排序权及其相关激励依然存在。