规范跨链交换：利用规范/原生L1->L2消息传递实现跨链交换的快速和去中心化结算 - Layer 2

规范的跨链互换：使用规范/原生 L1->L2 消息传递实现快速且去中心化的跨链互换结算

作者：Suah Kim & George ( Tokamak Network)

TLDR:

规范的跨链互换使用规范/原生 L1→L2 消息传递来提高去中心化程度，并加快流动性提供商的结算速度。这提高了资本效率，并增加了可用流动性，从而有助于解决 L2 的碎片化问题。

介绍

诸如 Across, 1inch, UniswapX, 和 0x 等流行的跨链互换平台通过更快、更便宜和更易于访问的互换改善了用户体验，从而有助于减少 L2 流动性碎片化。

但是，这些改进是以中心化程度提高为代价的，因为这些平台依赖于许可的或/和第三方的共识算法进行跨链消息传递。这为流动性提供商带来了更高的风险，例如资金损失和更长的结算时间，从而降低了资本效率。

使用规范的 L1→L2 消息传递（例如：Optimism 的 Portal，Arbitrum 的 Inbox）进行跨链通信，可以提供更简单且更去中心化的跨链互换。这种方法使流动性提供商能够进行自己的尽职调查，而无需依赖第三方。虽然流动性提供商仍然需要信任 L1 和 L2 网络，但此方法通过降低流动性提供商的准入门槛来提高资本效率并增加可用流动性。

流动性提供商现有的风险

为了清楚起见，我们定义以下术语：

• 请求者 (Requester)：请求跨链互换的用户
• 提供者 (Provider)：促进跨链互换请求的流动性提供者

尽管现有的跨链互换服务为请求者提供了无缝体验，但提供者和请求者都面临着来自系统性依赖的风险：

• 依赖中心化的跨链消息传递： 依赖中心化的跨链消息传递（例如许可的或第三方共识协议）会带来风险，例如由于服务中断、错误和故障导致的资金损失和结算延迟。如果服务提供商决定停止服务，也可能会影响请求者的用户体验。
• 依赖 L2： 提供者必须信任 L2 网络，以诚信运营并防止服务中断、审查或过高的 Gas 价格等问题。

提议的协议

我们的协议，规范的跨链互换，利用“规范的 L1→L2 消息传递”来实现无缝的跨链通信，从而消除了对许可的或第三方协议的依赖。重要的是要注意，当前版本专门设计用于支持 L2 到 L1 的跨链互换，并且尚未适应有效的 L2 到 L2 的跨链互换（稍后更新）。

“规范的 L1→L2 消息传递”是指 L2 使用的本机消息传递系统，例如，OP Stack 使用 Portal 合约从 L1 向 L2 发送消息。这通过减少受信任方的数量来增强提供者的安全性和用户体验。

主要特点

• 减少对许可的或第三方跨链消息传递的依赖
• 更快的提供商结算时间
• 最大程度地降低请求更改或取消期间的提供商风险
• 在服务中断或 L2 审查的情况下，防止时间锁漏洞
• 通过减少交易和存储更新的数量同时保持安全性来最大程度地减少交易费用。（请查看我们的 MVP )
• 当前版本仅支持 L2 → L1 作为概念验证，但可以扩展到 L2 → L2。

在提议的协议中，请求者仍将首先收到他们的资金，从而保持现有协议的出色用户体验，而提供者则以较低的风险运营。这为所有参与者创建了一个公平且安全的系统，简化了操作并大大改善了提供者的体验。

\ 图 1 L2→L1 规范的跨链互换流程。1478×974 150 KB

以下是提议协议的工作方式，一步一步：

1. 请求者在 L2 上发出跨链互换请求

请求者通过指定所需的 L1 代币信息并将代币锁定到托管合约，在源链上启动跨链互换。

2. 提供者在 L1 上满足请求

任何人都可以观察 L2 上的请求并满足该请求。提供者网络观察在托管合约中注册的请求：

(a) 提供者调用跨链消息合约以提供请求数量的代币

(b) （在同一交易中）请求者将从跨链消息服务收到资金（代表提供者转移）

(c) （在同一交易中）L1→L2 结算请求消息被发送到托管合约，指示其将锁定的代币释放给提供者。

3. 跨链消息传递到 L2

收到 L1→L2 结算请求消息后，L2 排序器将消息中继到托管合约。这确保了该过程保持无需信任，并且完全依赖于 L1→L2 规范消息传递的安全性。

4. 资金在 L2 上释放给提供者

收到消息后，托管合约会验证交易。它将锁定的代币释放给提供者，从而完成结算交易（提供者现在在 L2 上拥有他们的资金）

总而言之，在规范的跨链互换中：

• 请求者执行单个交易来托管用于互换的代币，可以使用“许可”机制使其无 Gas。
• 提供者在 L1 上执行单个交易，以将代币转账给请求者并发送结算消息。此交易包括 L1→L2 规范消息传递，由 L2 排序器无缝中继，而无需提供者执行任何其他操作。

编辑和取消请求：使用 L1 作为信任锚

为了确保协议的完整性，诸如“编辑”和“取消”请求之类的关键操作必须源自 L1（跨链消息合约），即使该请求本身是在 L2（托管合约）上发起的。这确保了系统的信任和安全性保持不变，并且请求者和提供者的资金都得到保护。

编辑请求

“编辑”功能允许请求者根据动态市场情况（如代币和 Gas 价格）修改提供者应提供给请求者的代币数量。

与其他依赖链下预言机或基于时间的荷兰式拍卖模型的服务不同，此功能直接通过 L1（跨链消息合约）处理编辑。由于这些更改会立即影响提供者的经济激励，因此当提供者满足请求时，编辑会立即生效。

\ 图 2 编辑请求流程。有助于根据市场情况更改激励措施。1478×672 94.5 KB

以下是“编辑”的工作方式：

• 请求者向跨链消息服务发送编辑交易以更新请求的数量。
  • 例如：请求者最初希望在 Optimism 上将 10 个 USDC 兑换为在 Ethereum 上的 8 个 USDT。当 Ethereum Gas 价格下降时，请求者可以编辑他们的请求以在 Ethereum 上接收 9 个 USDT。
• 仅当没有提供者满足请求时，才应用“编辑”。
  • 确保提供者始终拥有有关请求的最新信息，并且在提供流动性后无法编辑或取消请求。

通过在 L1 上强制执行编辑和取消，提议的协议在灵活性和系统完整性之间取得了平衡，从而确保请求者和提供者都可以在整个交易生命周期中受益于 L1 安全性。

取消请求

“取消”功能允许请求者取消他们的请求，从而从托管合约中收回他们的代币。

此过程必须源自跨链消息合约，并且仅在尚未满足请求时才生效。这确保了避免了提供者已经满足请求的情况，从而防止请求者恶意取消请求并窃取提供者的资金而不释放托管合约上的锁定代币。

\ 图 3 取消请求流程。1486×974 143 KB

以下是“取消”的工作方式：

• 请求者在跨链消息合约 (L1) 上执行“取消”功能。
  • 例如，请求者决定不进行互换，因为 L2 上有更好的机会。
• 如果未满足请求，则跨链消息服务会将跨链消息发送到规范的 L1→L2 消息服务，指示其将托管的代币释放回请求者。
• 在 L2 上对请求进行排序后，托管的代币将返回给请求者。

拟议协议的缺点

• 协议的交易成本增加： 跨链消息服务使用规范的 L1→L2 消息传递，因此通常比其他使用链下或第三方协议从 L1→L2 进行通信的现有服务成本更高。这是增强安全性和去中心化的一种权衡。
• 编辑或取消请求必须在 L1 上完成： 所有编辑和取消操作都必须在 L1 上进行，以维护协议的去中心化和无需信任的性质。虽然这确保了安全性，但它要求用户与 L1 交互，从而增加了交易成本和延迟。
• 请求不支持时间锁： 由于 L2 排序器中断或审查的可能性，该协议无法保证请求的严格截止日期，这可能导致提供商的资金损失；该提案协议没有提供不完整的产品，而是没有提供时间锁功能。
• L2 排序器中断或审查风险： 如果 L2 运营商审查跨链消息，则结算可能会面临延迟，但提供者永远不会损失任何资金。
• L2 → L2 跨链互换的资本效率低： 虽然当前版本专门为 L2 → L1 交易而设计，但我们计划将来扩展对 L2 → L2 互换的支持。可以直接扩展，但这会降低 L2 → L2 互换的资本效率，因为流动性需要来自 L1，而不能使用 L2 流动性。

其中一些权衡是有意的，优先考虑去中心化、安全性和无需信任的交易，而不是优化为最小的 Gas 成本。

虽然它们可能会带来某些不便，但这些决定与协议的目标一致，即构建一个仅依赖于 L1 和 L2 的安全信任假设的跨链互换系统。

ERC 7683 兼容性

我们的协议可以集成 ERC 7683，在增强去中心化的同时提供对基于意图的系统的支持（必须将“fillDeadline”参数设置为最大值，以避免时间锁漏洞）。这确保了提供者和用户在使用可互操作标准方面的灵活性，同时确保了更加安全和高效的交易流程。

虽然像 ERC 和 RIP 这样的标准的引入使这些系统成为可能，但它们也带来了额外的安全假设。令人鼓舞的是，看到这些努力推动了跨链功能的发展，但仍然需要一种仅依赖于 L1 和 L2 网络的固有安全性的协议。

结论

规范的跨链互换协议通过利用原生 L1→L2 消息传递来增强跨链流动性的去中心化和效率，从而减少了对中心化中介机构的依赖。这种方法可以降低风险，提高资本效率，并解决 L2 碎片化问题。

MVP

• GitHub:
  • link
• 描述:
  • 由 Tokamak Network 的 George 和 Harvey 提供
  • 用 Solidity 编写，支持从 Optimism 或 Arbitrum L2 到 Ethereum 的跨链互换。
  • 尚未经过正式审核，尚未准备好投入生产。
• 应用了哪些关键的合约设计考虑因素？
  • 安全假设：L1 中的合约不知道 L2 上发生了什么，并且无法验证 L2 上的任何活动。流动性提供者必须验证跨链互换请求实际上是否存在于 L2 上。
  • 交易费用最小化：提供者必须提供有关请求的所有相关信息，而不是从 L2 中继不可靠的请求信息到 L1，并且在结算步骤中验证请求。

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