Across Prime : 无需信任的快速桥

概要

• 1. 简介
• 2. 机制
  • 1. 受信任的
  • 2. 托管的
  • 3. 抵押的
• 3. 协议
• 4. 扩展
  • 1. 任意抵押品
  • 2. 多个目的地
• 5. 讨论
  • 1. Gas 效率
  • 2. ERC-7683 兼容性
  • 3. Mint-and-Burn 桥兼容性
• 6. 先前工作
  • 1. Across
  • 2. Orbiter 协议
  • 3. UniswapX (跨链)
  • 4. Relay 协议
• 7. 进一步工作

简介

本文介绍了 Across Prime，这是一种为资本高效的无需信任的快速桥梁的设计。

为 Ethereum 和其他区块链解决互操作性问题需要“快速”桥梁——能够以快于最终确认的速度在链之间移动资产和操作的桥梁。基于意图的桥梁设计，例如 Across 协议目前提供的，是解决这个问题的领先设计。

快速桥梁依赖于第三方中继者（又名 solver）来满足用户在目标链上的“意图”，以换取在源链上的付款。大多数这样的桥梁（如 Across）使用“托管”模型，其中付款被托管，直到意图被验证为“已完成”。这种托管设计引入了资本成本，因为中继者必须等待才能获得报酬；中继者实际上充当短期贷款人来满足用户的意图。

Across Prime 引入了一种“抵押”模型，其中中继者放下抵押品以保护从源链到目标链的特定路径。这允许用户直接向源链上的中继者付款。抵押模型比托管模型具有更高的资本效率，同时保持了大部分的安全性和去中心化优势。

机制

Across Prime 是快速桥梁设计的演进。

在快速桥梁中，用户对其希望在目标链上发生的事情有一些加粗意图加粗（例如接收资产、将资产发送给其他人或对某些应用程序执行操作）。用户在源链上向第三方加粗relayer加粗支付加粗payment加粗，以换取他们实现该意图。

在设计基于意图的桥梁时，一个关键问题是如何解决公平交换的问题。是什么阻止了 relayer 在没有实现用户意图的情况下拿走用户的付款？

受信任的

基于意图的桥梁的最简单版本是使用受信任的 relayer 解决公平交换问题。这是像 Relay 这样的应用程序今天实现的版本。

在受信任的桥梁模型中，用户在源链上向 relayer 付款，而 relayer 在目标链上实现意图。

如果 relayer 是诚实的，那么这种模型可能非常有效。但是，它不能保护用户免受恶意 relayer 的侵害。此外，信任 relayer 的需求使得拥有多个独立 relayer 变得困难，这限制了竞争和可扩展性。受信任的模型也可能面临托管或监管风险。

托管的

当有一些方法可以将消息从目标链发送到源链（“结算 oracle”）时，快速桥梁的其他设计就成为可能。一种是“托管”模型。这是 Across 今天使用的模型，以及为 跨链 UniswapX 设想的设计。

在这种设计中，用户不是向 relayer 付款，而是将款项托管在源链智能合约上。relayer 用自己的资金在目标链上实现意图，然后使用 oracle 证明已完成，然后用户资金被释放回 relayer。

这种托管系统在 ERC-7683 标准 中得到了很好的描述，其中托管合约和结算 oracle 被抽象成一个“结算系统”。Open Intents Framework 基于此标准，为 ERC-7683 兼容的 relayer 和模块化结算系统提供了参考实现。

如果 oracle 速度慢或成本高，则此设计有一个简单的“乐观”变体，其中 relayer 存放一笔押金，并且除非有人在某个挑战期内对完成情况提出质疑，否则假定意图已完成。

在所有版本的托管模型中，源链上的付款都会被托管，直到验证了意图的实现，这会给 relayer 带来资本成本。根据 oracle 和挑战期的安全假设，这可能长达几个小时。

抵押模型是一种减少或消除这种资本效率低下的方法。

抵押的

Across Prime 引入了一种不同类型的无需信任的快速桥梁：“抵押”桥梁。在这种模型中，relayer 立即收到源链上的付款。用户的安全由 relayer 提供的保证金来保证，保证金决定了 relayer 在任何给定时间可以“在途”的最大金额。如果 relayer 未能完成任何他们已获得报酬的操作，则用户可以从该保证金中申请退款。

这比托管模型具有更高的资本效率，尤其是在结算 oracle 速度较慢的情况下。

例如，假设 relayer 有 1,000 美元的保证金，源链和目标链每两条产生一个区块，并且结算 oracle 需要一个小时才能完成：

使用抵押模型，用户每四秒可以进行高达 1,000 美元的付款。（如下所述，用户需要等待两个区块才能确认 relayer 完成了先前付款在目标链上的所需操作。）这导致每小时总带宽高达 900,000 美元。

在托管模型中，每次付款都需要锁定一个小时才能等待结算 oracle 完成，因此进行 900,000 美元的付款将需要锁定总共 900,000 美元的资本一个小时——使其资本效率低于抵押模型高达 900 倍（考虑到此示例的假设）。

抵押模型具有更高的资本效率，因为只要在目标链上完成了意图，即使结算 oracle 需要更长的时间才能完成，抵押品也可以“重复使用”。这种质量使得可以使用慢得多（并且更安全或更去中心化）的结算 oracle（例如从乐观 L2 退出的为期一周的规范桥）成为可能，因为资本成本不再与结算 oracle 的延迟成正比。

乍一看，抵押设计似乎存在一个不幸的权衡：relayer 只有在始终保持大量抵押品锁定的情况下才能支持大额付款。这表明该设计可能与这样一种市场结构不兼容：在这种市场结构中，用户偶尔需要发送超过 relayer 抵押品要求的大额转账。但是，我们可以调整抵押模型来解决此问题——如果抵押品不足以支付用户所需的付款，我们可以立即将用户的资金直接添加到 relayer 的抵押品中，从而“及时”增加抵押品规模。这种调整本质上允许抵押模型在抵押品不够大时“回退”到托管设计，但有一个额外的好处：托管“抵押品”可以立即重复使用以保护其他用户的付款。

协议

这是一个用于跨链桥接 ETH 的抵押协议的简单版本（尽管它可以很容易地推广到满足任意意图）。它包括一些重要的逻辑来处理边缘情况，包括“争用”（多个用户将尝试同时向 relayer 付款的风险，导致在途总金额超过保证金）。

作为第一步，假设 Bob 想要成为特定路线的 relayer，其中路线定义为从特定源链到特定目标链的路径。Bob 在源链（例如 Arbitrum）上存入一定数量的 ETH, securityDeposit，并指定他们将支持哪个目标链（例如 Base）。

源链有一个“闸门合约”，它跟踪一个值 cumulativePayments，用于记录支付给 Bob 的该路线的累计付款金额，以及通过它实现的所有意图的 Merkle 根（其中每个新根是 keccak256(oldRoot, order)）。每次向 Bob 支付该路线的款项时，cumulativePayments 值都会增加，Merkle 根会更新，并且会发出一个 payment 事件，其中包含新的 Merkle 根和 cumulativePayments 的新值。

目标链有一个“履行合约”，它也跟踪通过该路线实现的意图。它有一个与源链上的 Merkle 根相对应的 Merkle 根，因此当该路线上的所有意图都已实现时，Merkle 根将匹配。

用户 Alice 想要将 ETH 从 Arbitrum 发送到 Base。她查阅支持该路径的 relayer 列表或 API，然后选择 Bob。她在目标链上检查 Bob 的 Merkle 根，并查看源链上最近的 payment 事件，直到找到匹配的根，并将该事件中的 cumulativePayments 值记为 confirmedCumulativePayments。

她确认 Bob 的 relayer 保证金足以退还所有当前未实现的意图的付款，以及她自己的付款。她签署一个 ERC-7683 GaslessCrossChainOrder，其中 orderData 字段包含以下信息：

• payment：Alice 愿意在 Arbitrum 上支付给 Bob（relayer）的 ETH 金额
• confirmedCumulativePayments：Alice 计算得出的已实现的总累计付款金额的值。如下文所述，此数字有助于闸门合约强制执行 Bob 的保证金足以偿还 Alice。
• destinationAmount, destinationAddress：Alice 希望在目标链上收到的 ETH 金额，以及她希望收到它的地址。只要履行合约可以强制执行，这就可以很容易地替换为任意意图。

Alice 将此意图交给 Bob（relayer），Bob 将其提交给源链上的闸门合约。闸门合约检查该意图是否由 Bob 提交，以及 securityDeposit 是否大于 cumulativePayments + payment - confirmedCumulativePayments。然后，它将 payment 金额添加到 cumulativePayments，将订单哈希到 Merkle 链中，并将 payment 直接从 Alice 转移到 Bob。

Bob 还可以指定他希望将部分付款存入他的保证金中，而不是立即收到。如果 Bob 目前的保证金不足以支付 Alice 的付款，这可能会有所帮助。

闸门合约触发一个事件，其中包含订单的哈希值，新的 cumulativePayments，目标链 ID 和新的 Merkle 根。

Bob 现在在目标链上满足用户，并通过履行合约传递他们的订单。履行合约验证订单是否已履行，对其进行哈希处理，并将其添加到 Merkle 链中。它还触发一个事件，记录新的 Merkle 根。

如果 Bob 没有实现某些意图，那么在挑战期之后，任何人都可以挑战源链上的 Bob。待处理的挑战会阻止 Bob 提取他的保证金，直到他证明订单已在目标链上履行（通过使用慢速消息桥来证明 Merkle 根匹配）。如果有多个待处理的挑战，则 Merkle 链中首先包含的订单优先。

扩展

任意抵押品

在上面给出的示例中，付款货币与保证金货币相同。对于每个 relayer 来说，以每种货币进行抵押是不高效的。只要用户 (Alice) 签署了她在订单持续时间内接受的最低汇率，该模型就可以扩展为支持任意保证金抵押品。Alice 的 payment 金额（锁定 Bob 的保证金）将用她保守的汇率“填充”，以保护 Alice 在订单期间免受她的付款货币相对于 Bob 的保证金货币的相对价值变化。

由于 Alice 的订单应该很快（在几秒钟内）完成，因此实际需要的填充可能非常适度，同时仍然可以完全保护 Alice。

多个目的地

在上面描述的抵押模型的简化版本中，每个 relayer 的每条路线都需要保证金。在上面的示例中，Bob（relayer）在 Arbitrum 上存入专门分配给 Arbitrum→Base 路线的保证金。如果 Bob 需要为每条路线都存入保证金，则所需的保证金将降低系统的资本效率。

为了缓解这种情况，每个源链保证金都可以用于覆盖多个目标链。这给用户增加了一些负担，用户现在必须检查集合中的每个目标链，以验证哪些未完成的意图。用户还必须信任每个目标链的排序器或预确认。如果用户喜欢隔离的信任假设，他们可以要求 relayer 拥有专用于每条路径的单独保证金。

讨论

Gas 效率

如上所述，抵押模型可以比托管模型具有更高的资本效率。它还可以显着提高 gas 效率，因为在正常情况下，它只需要两个交易（源链上一个，目标链上一个），而托管模型需要在源链上进行第三个交易以进行结算。

ERC-7683 兼容性

Across 和 Uniswap 提出了 ERC-7683，这是一个广泛支持的跨链意图标准。该标准在编写时考虑了托管意图模型，但它通常与 Across Prime 的抵押设计兼容。按照 ERC-7683 规范，originSettler 可以设置为 Across Prime 的闸门合约，而 destinationSettler 只是目标链上的 Across Prime 履行合约。该标准提出的 orderData 和事件结构保持不变。

Mint-and-Burn 桥兼容性

在抵押模型中，relayer 在必须在目标链上满足用户之前，会在源链上收到用户的付款。这意味着，如果付款货币是一种 mint-and-burn 代币（例如 Circle 的 USDC，Hyperlane 的 Warp Tokens，LayerZero 的 OFT，Wormhole 的 NTT 等），则 relayer 不需要任何目标链上的库存来支持该流程，尽管填充时间会较慢。

在这种情况下，用户可以用稍微慢一些的填充时间来换取更便宜的填充。一个示例流程：（i）用户发布他们的意图，并设置更长的填充时间（例如 3 分钟），并将 mint-and-burn 代币发送给 relayer；（ii）relayer 使用 mint-and-burn 桥将这些代币移动到目标链；（iii）在 mint-and-burn 桥完成后，relayer 填充用户。

在这种结构中，Across Prime 充当所有可用桥接方法的超集：如果可以立即填充（因为 relayer 在目标链上持有库存），则用户将收到立即填充；如果库存不可用，则用户将收到近似于底层 mint-and-burn 桥的速度和成本的填充。

先前工作

在基于意图的跨链协议方面已经有很多先前的研究，包括许多基于托管的设计，以及一些与 Across Prime 的抵押模型更相似的架构。

Across

Across 首创了托管意图设计，并将其与“批量结算”的优化相结合。在 Across 中，用户将资金存入源链的托管账户中，然后 relayer 竞相在目标链上满足用户。每个周期（大约 1 小时），所有已完成的填充都会汇总成一个 Merklized 包，该包“批量偿还”每个 relayer 在每条链上欠下的所有退款。此包在以太坊主网上经过乐观验证，然后资金才会释放。这种设计通过批量偿还智能地最大程度地减少了 gas 成本，但需要 relayer 资金锁定约 1 小时，从而产生了巨大的资本成本。

Orbiter 协议

Orbiter 的设计目标具有一些与 Across Prime 相似的质量。与 Across Prime 类似，Orbiter 要求 relayer（称为 maker）在要求用户直接向 relayer（又名 maker）发送资金之前发布保证金。此保证金必须大于发送给 relayer 的资金。但是，Orbiter 的设计不处理争用；该协议无法阻止两个或多个用户错误地向 relayer 发送超过保证金可以覆盖的资金。Across Prime 通过闸门合约防止争用并强制执行适当的保证金。

UniswapX（跨链）

跨链 UniswapX 尚未实施。它遵循类似于 Across 的设计，但没有批量结算。对于每笔桥接交易，用户资金都托管在源链上；然后，relayer 在目标链上满足用户。只有在乐观的挑战期过去后，资金才会从托管账户中释放。Across Prime 绕过了与每笔桥接交易的单独托管和验证相关的成本。

Relay 协议

Relay 协议当前以中心化、受信任的 relayer 的形式实施。Relay 具有 共享设计，可以使用单独的“结算链”来分散其实现，relayer 必须在收到用户直接的存款之前将资金托管在该结算链上。此结算链需要对每笔交易进行单独托管和结算，然后 relayer 才能收到其托管的资金。Across Prime 通过避免每笔交易的托管或结算的全部需求来节省不确定性、gas 成本和复杂性。用户只需验证 relayer 是否已正确抵押。

进一步工作

当前的快速桥梁通常依赖于托管模型，这会因结算延迟而阻碍资本效率，从而锁定 relayer 资金。本文介绍了 Across Prime，这是一种采用“抵押”模型的快速桥梁设计。这种抵押品几乎可以立即重复使用，从而将资本速度与结算延迟分离，并大大提高了 gas 和资本效率。

如果你有兴趣开发 Across Prime 或从事相关的基于意图的桥梁设计，请与本文的作者或 Across 团队联系。

• 原文链接： paradigm.xyz/2025/05/acr...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～