跨链 AMP 防抢跑：时间锁谜题与乐观队列如何约束目标链排序

摘要：跨链消息的风险，不只在验证，也在目标链排序

任意消息传递（Arbitrary Message Passing, AMP）通常被描述为“链 A 的合约调用链 B 的合约”。这个描述太干净，掩盖了真正危险的部分：源链消息被观察到之后，目标链并不会自动按照源链时间顺序执行。中继器、Builder、私有 RPC、目标链验证者和 MEV 搜索者都可能在消息到达目标链前看到足够多的意图信息，并利用排序权抢跑、夹击或延迟执行。

本文研究第 87 题：基于时间锁谜题（Time-Lock Puzzle）与乐观排队机制（Optimistic Queue）的跨链 AMP 防抢跑设计。核心结论是：跨链安全不能只证明“消息来自源链”，还必须约束“消息何时可见、何时入队、按什么规则执行、失败后如何退款”。时间锁或可验证延迟函数（Verifiable Delay Function, VDF）可以降低提前解密和目标链抢跑空间；乐观队列可以把跨链消息先提交到一个可争议的顺序层，再在超时窗口后执行。

对 [AllSwap 跨链兑换](/exchange-swap) 这类无托管跨链交换而言，用户关心的是目标链资产能否按报价执行，以及失败时是否可退款。只要目标链排序被操纵，滑点、到账时间和退款责任都会偏离报价。相关基础路径包括 [费用说明](/fees)、[USDT TRC20 兑换](/swap/usdt-trc20)、[USDT ERC20 兑换](/swap/usdt-erc20) 和 [TRX 资产页面](/assets/trx)。

1. 系统边界：AMP 的核心不是“能传消息”，而是“消息被如何执行”

在 AMP 系统里，源链合约产生消息 m，消息包含目标链地址、payload、nonce、费用和执行约束。中继层观察源链事件，等待最终性或确认阈值，然后把消息及其证明提交到目标链。目标链合约验证消息来源，再调用目标合约或释放资产。

这个流程至少有五个时钟：

- 源链出块和最终性时钟； - 中继器观察和证明生成时钟； - 目标链 mempool 或私有交易通道时钟； - 目标链出块和排序时钟； - 用户设置的超时和退款时钟。

LayerZero V2 文档在 message execution options 中明确指出，源链发送跨链消息时并不知道目标链状态或执行所需资源，因此需要把目标链执行要求序列化给链下基础设施处理。[1] Chainlink CCIP 把跨链消息、代币转移和可编程转移放在同一互操作层，并强调风险管理网络用于异常监控。[2][3] Axelar 的 General Message Passing 允许跨链函数调用和状态同步。[4] Wormhole 的跨链 messaging 也让合约在多链之间发送和接收消息。[5]

这些协议解决了“消息真实性”和“跨链可达性”的一部分，但它们并不自动解决目标链排序公平性。一个跨链交换意图可能在源链已经锁定资金，但目标链执行仍暴露在目标链 mempool、Builder 排序和中继器选择性提交之下。换句话说，AMP 的安全边界不是消息验证合约结束的地方，而是目标链执行确定、失败可归因、退款可触发之后才结束。

2. 攻击模型：跨链抢跑利用的是时间差，不一定需要伪造证明

跨链抢跑者不需要破解签名，也不需要伪造消息证明。它只需要在源链观察到敏感消息，然后在目标链提前布局。

典型流程如下：

```text T0: 用户在源链提交跨链意图，资金或订单被锁定。 T1: 中继器、搜索者或公开索引器观察到消息内容。 T2: 攻击者在目标链预测执行路径，提交抢跑交易。 T3: 合法消息证明到达目标链，但目标状态已经改变。 T4: 用户收到更差价格、交易失败、或进入退款流程。 ```

Flash Boys 2.0 早就说明，交易排序依赖会产生抢跑、重排和优先 Gas 竞价，并把 MEV 变成共识层安全问题。[6] 跨链 AMP 把这个问题放大了，因为源链和目标链之间存在物理延迟。目标链攻击者不需要比用户更快签名，只要比合法跨链消息更快进入目标链排序。

跨链场景比单链 DEX 更难处理。单链交易至少共享同一个 mempool 和同一个区块排序；跨链消息的可见性、证明延迟和目标链执行在不同系统里发生。中继器可能出于费用、拥堵或策略原因延迟提交；目标链 Builder 可能优先打包本地套利交易；私有 RPC 可能把消息泄露给特定搜索者。攻击面变成一个跨系统的时序差。

因此，AMP 防抢跑不能只依赖“更快中继”。更快中继会变成速度军备竞赛，最终奖励靠近目标链 Builder 或私有订单流的参与者。协议级设计应该让敏感 payload 在入队前不可利用，或者让任何提前利用都能被检测和惩罚。

3. 时间锁谜题与 VDF：把消息内容延迟到排序之后

时间锁谜题的基本思想来自 Rivest、Shamir 和 Wagner：发送者可以构造一个需要顺序计算才能解开的谜题，让信息在未来某个计算时间后才可读。[7] 这类机制不依赖某个受信任保管人按时发布密钥，而是依赖顺序计算难以并行加速。

VDF 进一步给这个思想加上可公开验证的输出。Boneh、Bonneau、Bünz 和 Fisch 对 VDF 的定义是：评估需要指定数量的顺序步骤，但结果可以高效公开验证。[8] 对跨链 AMP 来说，VDF 的吸引力在于它能把“延迟”从中继器承诺变成可验证对象。

一个简化模型可以这样写：

```text payload = Enc_k(message) puzzle = VDFCommit(k, delay = D) packet = {sourceProof, target, payload, puzzle, deadline}

目标链先接收 packet 并入队； 等待 D 或验证 VDF output； 解出 k 后公开 message； 按队列顺序执行 message。 ```

这里的关键不是隐藏所有跨链信息。金额范围、目标链、费用和收款约束可能仍然需要暴露给系统做风控和报价。真正需要延迟的是会被抢跑利用的细节：目标池、交易方向、最小输出、策略参数、回调路径或清算条件。

时间锁也不是免费午餐。D 设置太短，攻击者仍能提前解密；D 设置太长，用户体验和目标链资金效率会下降。VDF 验证虽然比求值便宜，但在链上直接验证仍有成本；若把求值或验证放到链下，又要解决谁提交结果、谁挑战错误结果、挑战窗口多长的问题。

所以时间锁适合处理“消息在排序前不应被知道”的部分，而不适合替代最终性确认、消息证明或退款状态机。它是时序防护层，不是完整跨链安全层。

4. 乐观排队：先固定顺序，再揭示和执行

乐观排队的目标是把跨链消息从“谁先把交易塞进目标链”改成“谁先在目标链提交可验证队列承诺”。最小状态机如下：

```text Submit(packet): verify sourceProof or committee attestation append hash(packet) to queue set status = Pending

Reveal(packet, key): require hash(packet) in queue require delay elapsed or VDF output valid decode payload set status = Revealed

Execute(packet): require status = Revealed require all earlier executable packets handled or timed out call target with payload set status = Executed or Failed

Timeout(packet): if deadline passed and not Executed mark Refundable or Slashable ```

这个模型有两个约束。第一，入队顺序必须可验证。可以用目标链交易时间、目标链合约 nonce、批次 Merkle root 或跨链消息序号作为排序依据。第二，执行不能无限阻塞。若某个早期消息因 gas 不足、目标合约 revert 或证明缺失而卡住，队列必须能跳过、标记失败或触发退款，否则攻击者可以用一个坏消息阻塞后续全部消息。

Themis 和 Aequitas 这类公平排序协议关注的是拜占庭共识中的消息顺序公平性。Aequitas 试图在共识中同时提供安全性、活性和 order-fairness；Themis 在 n >= 4f + 1 的设置下给出更强的公平排序性质。[9][10] AMP 不一定直接采用这些共识协议，但它们给出了关键启发：排序公平不是“先到先得”这么简单，因为不同节点看到消息的时间不同。跨链系统也不能只看某个中继器提交时间，而应考虑源链顺序、目标链入队顺序和可争议证据。

乐观排队的“乐观”在于默认消息按承诺执行，不为每个消息都做昂贵争议；但系统保留挑战窗口。如果有人证明 packet 内容、sourceProof、队列位置或 VDF 输出无效，该消息被标记失败，中继器或提交者被惩罚。这样可以把大部分消息保持低延迟，同时给异常路径留出可归因机制。

工程上还需要把“队列证明”和“退款证明”分开。队列证明回答的是：某条消息是否在目标链某个批次中占据确定位置；退款证明回答的是：该消息是否在 deadline 前未进入 `Executed` 状态，或进入 `Failed` 状态且失败原因符合退款规则。两者不能混在一个布尔值里。否则用户只能看到“失败”，却无法判断是中继器未提交、目标链执行失败、VDF 揭示超时，还是目标合约状态不满足约束。对跨链交换来说，这个差别直接决定是退还源链资金、重新报价，还是惩罚提交者。

5. 防目标链夹击：排序约束必须覆盖 Builder 和中继器

跨链夹击不是简单的“中继慢”。攻击者可以在目标链上围绕合法消息构造前后交易：先改变池子价格，再让跨链消息以较差状态执行，最后反向套利。若消息 payload 在源链公开，攻击者甚至不需要等待中继器提交。

防御可以拆成三层。

第一层是 payload 可见性控制。敏感字段在入队前以承诺或加密形式存在，只有队列位置固定后才揭示。时间锁谜题、VDF、阈值加密或延迟揭示都属于这一层。

第二层是执行窗口约束。目标链合约可以要求消息在揭示后只在固定窗口内执行，或者要求执行价格、状态根、池子版本和 slippage 与入队时的承诺一致。这样即使攻击者能观察揭示，也很难在无限时间里等待最佳夹击点。

第三层是失败归因和退款。若目标链状态因排序操纵而不再满足用户约束，系统不应强行执行，而应进入退款或重新报价路径。对用户来说，“消息最终执行了”不等于“按原意图执行了”。

PBS 和 MEV-Boost 的存在说明，现代区块构建已经把交易排序从单一验证者行为扩展成 Builder 市场。[11][12] AMP 设计必须承认这一点。只要目标链执行进入 Builder 选择范围，跨链消息就会面对本地 MEV 生态。协议不能假设目标链排序天然中立。

6. 失败模式：公平排序层本身也会成为攻击面

第一个失败模式是延迟参数错误。时间锁延迟 D 太短，攻击者仍能在消息执行前恢复 payload；D 太长，正常用户承担不必要等待和价格风险。D 不应是全局常数，而应按链对、资产、订单类型、目标链出块时间和历史 MEV 风险动态配置。

第二个失败模式是队列阻塞。攻击者提交一个合法入队但必然执行失败的消息，占据队头。如果系统要求严格顺序执行，后续消息被拖住。防御是把状态拆成 `Pending`、`Revealed`、`Executable`、`Failed`、`Refundable`，并允许超时跳过，同时记录失败原因。

第三个失败模式是中继器选择性提交。中继器看到某些消息对自己不利，就延迟提交或提交到私有通道。防御需要多中继器竞争、提交者保证金、延迟证明和“任何人可提交”的 fallback 路径。

第四个失败模式是 VDF 外包中心化。如果只有少数高性能节点能按时求解 VDF，延迟层会变成新的中心化入口。VDF 适合验证时间约束，但不应让求解者拥有排他执行权。结果提交和执行权应分离。

第五个失败模式是退款窗口错配。源链认为消息超时可退款，目标链却已执行；或目标链执行失败，源链资金仍被锁定。跨链退款必须绑定消息状态证明，而不能只看单链时钟。

7. AllSwap 相关性：用户看到的是报价，系统必须处理全域时序

AllSwap 的用户不关心 AMP 的内部消息格式，但会直接承受目标链排序风险。比如用户从一条链换到另一条链上的稳定币，报价时目标池状态是 A；消息到目标链执行时，池子状态可能已经变成 B。若这个变化来自正常市场波动，系统需要 slippage 控制；若来自观察跨链消息后的抢跑，系统需要时序防护和失败归因。

一个更稳健的 AllSwap 跨链执行层可以分四步演进。

第一，明确跨链消息状态机。每笔订单至少应有 `SourceLocked`、`QueuedOnTarget`、`Revealed`、`Executed`、`Refundable`、`Refunded` 等状态，让用户和系统都能定位失败发生在哪里。

第二，对敏感路径使用延迟揭示。并非所有跨链兑换都需要 VDF 或时间锁；小额、低 MEV 风险路径可以走普通中继。但大额、低流动性、目标链容易被夹击的订单，应考虑隐藏目标执行细节直到排序固定。

第三，把 [费用说明](/fees) 和时间风险拆开。用户支付的不是单一跨链费用，而是源链 gas、目标链执行 gas、中继服务费、可能的延迟保护成本和退款处理成本。系统越早把这些拆清楚，越容易解释为什么某些路径更贵。

第四，把无托管安全边界写进产品规则。AllSwap 不需要接管用户资产，也不需要承诺目标链绝对无 MEV；但必须让用户知道何时会执行、何时会退款、哪种失败归谁负责。对 [USDT TRC20](/swap/usdt-trc20) 和 [USDT ERC20](/swap/usdt-erc20) 这类高频路径，状态机透明度比宣传“秒级到账”更重要。

报价层也应读取这些状态，而不是只读取最终结果。若某条路径经常停在 `QueuedOnTarget`，问题可能是目标链排序或中继拥堵；若经常停在 `Revealed` 后失败，问题更可能是目标合约状态、滑点或执行窗口。只有把这些状态回灌到路由评分，后续报价才会逐渐反映真实风险。

8. 开放问题：跨链公平排序还远没有收敛

第一，时间锁参数如何定价。D 是安全性、延迟和资金效率的共同变量。不同链对、资产和订单大小需要不同 D，但动态 D 又可能被攻击者作为风险信号利用。

第二，VDF 验证应放在哪里。链上验证可审计但有 gas 成本；链下验证便宜但需要挑战机制。不同目标链的预编译、gas 模型和证明成本差异会直接影响设计。

第三，公平排序与最终性如何组合。源链顺序、目标链入队顺序和目标链执行顺序可能冲突。系统需要定义哪个顺序优先，以及发生重组时如何回滚或退款。

第四，隐私和可恢复性的冲突。payload 加密能降低抢跑，但也让风控、模拟和失败诊断更难。系统可能需要分层披露：公开约束摘要，延迟揭示敏感路径。

第五，谁来惩罚跨链排序作恶。若作恶者是中继器，链上保证金可以处理；若作恶者是目标链 Builder 或私有 RPC，协议只能通过替代执行通道、价格保护和退款规则间接防御。这个边界必须写清楚。

References

[1] LayerZero V2 Message Execution Options, LayerZero Docs, https://docs.layerzero.network/v2/tools/sdks/options

[2] Chainlink CCIP Documentation, Chainlink Docs, https://docs.chain.link/ccip

[3] Chainlink CCIP Risk Management Network, Chainlink Blog, https://blog.chain.link/ccip-risk-management-network/

[4] General Message Passing and How Can It Change Web3, Axelar, https://www.axelar.network/blog/general-message-passing-and-how-can-it-change-web3

[5] Wormhole Cross-Chain Messaging Contracts, Wormhole Docs, https://wormhole.com/docs/products/messaging/tutorials/cross-chain-contracts/

[6] Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges, arXiv, https://arxiv.org/abs/1904.05234

[7] Time-lock puzzles and timed-release Crypto, Rivest, Shamir, Wagner, 1996, https://people.csail.mit.edu/rivest/pubs/RSW96.pdf

[8] Verifiable Delay Functions, Boneh, Bonneau, Bünz, Fisch, IACR ePrint 2018/601, https://eprint.iacr.org/2018/601

[9] Order-Fairness for Byzantine Consensus, Kelkar et al., IACR ePrint 2020/269, https://eprint.iacr.org/2020/269

[10] Themis: Fast, Strong Order-Fairness in Byzantine Consensus, IACR ePrint 2021/1465, https://eprint.iacr.org/2021/1465

[11] Proposer-builder separation, ethereum.org, https://ethereum.org/roadmap/pbs/

[12] MEV-Boost Overview, Flashbots Docs, https://docs.flashbots.net/flashbots-mev-boost/introduction