议程

问题

1. 定义终态：使加密应用程序“可用”的特征

2. 为什么“链抽象”是解决由模块化区块链的基本拓扑结构引起的用户体验问题的解决方案

3. 为什么可用的加密应用程序必须建立在链抽象基础设施之上

解决方案空间

1. 意图驱动的架构如何导致链抽象的出现

2. 了解到意图市场在求解者网络庞大且竞争激烈时表现最佳

3. 引导意图求解者网络的启动需要吸引更多能产生意图的应用程序

提案

1. 为什么我们需要一个优先考虑“求解者用户体验”的跨链意图标准，以便将求解者和意图市场发展到足够大的规模，以实现网络效应

如果没有链抽象，就无法构建可用的加密应用程序

我们最优秀、最聪明的人是否在建造冗余基础设施？

许多人对最优秀的加密工程师和最具思想深度的人过度关注为终端用户提供更多的区块空间表示遗憾。这种批评有一定道理；与对其需求相比，现有的L2层对终端用户来说过多了。

然而，我不认同没有任何有用的加密应用程序存在的观点。

去中心化金融为个人提供了自行托管数字资产的能力，使他们能够绕过严苛的服务提供商，并使用数字资产购买实物世界中的价值物品。自我托管数据的承诺也为越来越不信任FAANG垄断企业来保护其数据安全的个人提供了一种乌托邦式的选择。

在我看来，真正的问题不是缺乏有用的加密应用程序，而是终端用户尝试访问它们时遇到的摩擦。当与加密应用程序交互时，终端用户应该能够体验到以下内容：

速度：应用程序应该感觉像web2应用程序一样快速。

成本：与web2不同，所有web3交互必须产生一定成本，但“每次点击”的成本应该可以忽略不计。

抗审查性（“无需许可性”）：任何拥有钱包的人都应该能够与应用程序交互，如果他们有能力点击的话。

安全性：点击应该按照用户的预期执行，而不应该发生逆转—所有web3更新应该是永久性的。

这些是“可用”的加密应用程序的特性。

我们已经尝试构建可用的加密应用程序很长一段时间了

如今的模块化区块链解决方案向消费者提供了所有这些特性，但它们并不都在同一个地方可用。

在2020年，区块链是单体化的，为终端用户提供了三种特性中的两种：速度、成本或安全性。然后，我们设想了一个以Rollup为中心或模块化的未来，可以同时实现这三个特性。

如今，我们已经建立了这种以Rollup为中心的基础设施的基础。L2提供了廉价且快速的区块空间，其中大多数提供了无需许可的区块空间。相反，L1提供了WW3抵抗、安全的区块空间。（您可以阅读我关于L1和L2提供的安全性与用户体验之间的权衡的短期调查文章了解更多）。这些L2通过规范的消息路径与L1安全连接，为一个模块化但可互操作的网络打下了基础。在过去的四年里，我们建立了连接区块链的光纤，有一天将支持有用的加密应用程序。但为什么模块化区块链如此难以使用呢？

模块化区块链网络的必然性在于，资本资产将会积累在最安全的层上，而用户点击将会积累在更快速和更便宜的层上。

模块化区块链拓扑鼓励安全的区块空间在不同的层上提供，而廉价和快速的区块空间则在另一层上提供。用户自然会更倾向于在最安全的网络上存储他们的价值，但他们会要求更频繁地与廉价和快速的网络进行交互。根据设计，L2与L1之间的规范路径是缓慢和/或昂贵的。这些现象解释了为什么用户必须通过这些规范路径使用L1资产来支付L2交互。这导致了“不可用”的加密用户体验。

维塔利克对不同类型的L2的看法

链抽象的目标是减少将价值发送到协议路径中的摩擦，远离用户。链抽象者假设用户更倾向于将其期望的最终状态指定给dapp为“意图”，而dapp有责任实现他们的意图。用户不应该为了获得低费用和低延迟而牺牲对其资产的安全托管。

因此，链抽象在很大程度上取决于用户能够安全、廉价、快速地在网络之间传输价值。如今的一个常见用户流程是，一个在“安全”链上（如以太坊）拥有USDC余额的用户希望在像Blast或Base这样的新链上铸造NFT或交换新代币。在尽可能少的步骤中执行此操作的方法是依次执行一系列桥接→交换→铸造交易（或交换→桥接→铸造）。

在这个例子中，用户的意图是使用他们在安全链上的USDC来在另一个链上铸造NFT。只要他们收到了NFT，并且选择了托管的地方扣除了他们的USDC余额，用户就会感到满意。

意图驱动的架构是构建链抽象的唯一方式

链抽象依赖于跨链价值转移，但通过规范消息路径发送价值要么昂贵要么缓慢。 “快速桥梁” 为用户提供了在网络之间发送价值的廉价且快速的替代方案，但它们引入了新的信任假设。消息传递是构建快速桥梁的最直观方式，因为它是基于TCP/IP架构建模的；它依赖于一个桥协议充当TCP路由器来连接两个链。

来自 ResearchGate 的 TCP/IP 图表

通过消息传递进行价值转移涉及桥协议在源链和目标链上的合约之间发送消息。此消息由用户交易在源端触发，并在消息的“有效性”验证后中继到目标端。

只有在发起消息的源链交易已经完成，也就是说，该交易已经永久地包含在源链的规范区块链中，消息才能被验证。此验证可以完成为有效性证明，证明了交易在源链上的共识包含，作为一个乐观的提案，或者在源端已经累积了一定数量的证人签名来证明其被包含。一旦消息被中继到目标链上的桥合约，代币就会释放给用户。

这种架构存在几个根本性问题：

验证机制必须等待完全的最终性才能将消息发送到目标链的协议合约。对于具有乐观最终性周期的L2，这可能需要长达七天的时间。

每个桥交易只发送一个跨链消息，或者消息被批量发送，但是批量只能在批次中的最后一个消息被最终化后发送。

桥仅能有限地获取外部流动性以提供用户价格改进，因为它必须对用户意图的实现路径进行声明。

基于上述见解，消息传递快速桥梁将会根据验证机制的不同而存在不安全、缓慢或昂贵的问题。意图市场是一种快速桥梁的替代架构，它来源于一个关键的洞见：

价值是可替代的，对于接收者来说，价值是如何转移的并不重要，只要他们收到了资金

一个桥梁可以将价值转移外包给一个复杂的代理来获得速度和降低成本吗？流动性在链上和链下是动态变化的，如果桥梁机制有灵活性在桥梁转移时选择最优执行路径，那么价格改进是可以实现的。

意图机制允许用户指定在其价值转移交易执行时的精确条件或契约。

一个最小可行的意图是从链A支付X令牌以在链B上接收Y令牌的订单。

桥梁协议不需要在每次桥交易中在域之间发送消息来执行用户的跨域意图。相反，该协议将价值转移外包给一个从无需许可的求解者网络中选取的代理，并且个别求解者将在稍后向桥梁协议寻求偿还。相比之下，消息传递机制明确指定了它们的交易应该如何执行，而不需要依赖于代理的可用性。

意图结算协议

意图结算协议可以更准确地标记为意图结算协议，其负责确保求解者不违反用户指定的条件。意图结算协议为求解者提供了保障，确保他们在履行用户意图时能够获得偿还和奖励。为此，意图结算协议需要向oracle申请验证意图履行的真实性。Oracle的安全性可以基于乐观的挑战期、见证阈值或者基于零知识有效性证明等方式。

意图结算协议提供了快速和廉价的价值转移，因为个别求解者可以承担最终性风险并确定最佳执行路径

消息传递桥梁只能在起始链达到最终性时进行通信。乐观Rollups的最终性时间为七天，ZK Rollups为一小时。尽管随着更广泛地采用ZK轻客户端技术和共享排序预确认技术的推进，

些最终性时间应该会趋向下降，但所有区块链的最终性时间都不太可能对用户来说感觉“即时”，这表明了对快速桥接解决方案的持续需求。除非桥梁愿意在中继路径中添加一个额外的可信代理来弥补由于链重组而造成的损失，否则在不承担最终性风险的前提下，消息传递桥梁无法比最终性期限更快地中继消息。

意图驱动架构提供的加速是因为异构求解者网络中的个别求解者可以承担比消息传递协议更多的最终性风险，并在链重组风险完全消失之前完成用户的意图。求解者随后会向用户收取他们为加速交易时间而承担的最终性风险。

将跨链意图履行外包给代理也平均会为用户带来价格改进。在意图驱动的桥梁中，前置用户订单到期望的目标链上的求解者将在其履行验证后由系统返还。这些意图结算可以批量处理以分摊成本。与用户不同，填充者不会要求即时偿还，而会根据前置资本向用户收取相应的费用。批量结算并不是意图驱动架构的独有特性，但是该架构与批量结算更加协同，因为它将偿还步骤与意图履行步骤分开。

价格改进的更大来源来自于价值可替代的直觉，及时找到最佳路径通常会优于价值转移。（然而，有些路径在即时情况下不可能击败成本，比如在跨越CCTP时转移USDC。）

消息传递桥梁必须编码如何将价值转移给用户。一些选择以预定的汇率从流动性池中发送代币，而其他人则为需要随后交换为期望的规范代币资产的接收方铸造代表性代币。

在履行用户意图时，代理可以从链上和链下的流动性场所组合提供流动性。竞争激烈的求解者网络理论上为用户提供了无限的流动性来源（但是即使这些流动性来源也可能在高波动性的链上事件中快速耗尽，比如热门NFT铸造、空投和拉盘）。

将跨链订单提交为意图使求解者可以内部化订单产生的MEV作为价格改进。

意图驱动架构基本上是设计为安全的。

基于意图的桥梁可以建立安全，因为它们将用户的紧急需求与结算网络的复杂需求分开。求解者可以等待偿还，而不像用户那样急切，他们将根据结算协议让他们等待偿还的时间向用户收费。因此，意图结算可以使用非常健壮的机制进行验证，而无需严格的时间限制。从安全性的角度来看，这是可取的，因为验证意图履行在直观上是复杂的。

作为生产中意图验证的一个例子，Across 在一个90分钟的乐观挑战期后批量验证和偿还填充者。当然，结算网络应该努力尽快偿还填充者，以减少最终用户的费用。对乐观挑战机制的改进将是ZK有效性证明机制，它将需要将意图验证逻辑编码到一个ZK电路中。在我看来，必然会发生的是，有效性证明机制将取代乐观挑战机制，并使意图结算网络能够更快地偿还用户。

所以，链抽象是如何从基于意图的架构中产生的呢？

回顾一下，链抽象需要快速且廉价的跨链价值转移。同时，它也不应要求用户在存储其资产的网络上提交链上交易。

如果用户的意图包含 Permit2 或 EIP3074 签名，用户就不需要在链上提交意图。这对于消息传递和基于意图的桥梁都是适用的。这两种架构都可以利用 Permit2 模式，允许用户在链下签署他们愿意从原始链钱包支付的代币数量。

意图市场最能支持链抽象，因为它们提供了廉价且快速的跨链价值转移。想象一下，一个用户可以请求求解者给他们一个报价，以使用其在 Optimism 上的 USDC 进入 Arbitrum 上的 WETH 抵押头寸，作为支付。用户可以将这个意图发送到一个 RFQ 拍卖，在那里求解者可以对其进行竞标。拍卖的获胜求解者随后可以收到用户的签署意图，其中包含了允许在 Optimism 上花费他们的 USDC、在 Arbitrum 上收到的 WETH 的数量以及用于将此 WETH 存入 Arbitrum 抵押头寸所需的 calldata。求解者随后可以在 Optimism 上提交此交易（代表用户）来启动跨链意图并从用户的 Optimism 钱包中提取 USDC。最后，求解者可以通过向用户发送 WETH 并将 calldata 转发到用户的链上抵押头寸，来填充用户在 Arbitrum 上的意图。

构建链抽象基础设施意味着使这个用户流程感觉即时且廉价，而无需他们提交链上交易。让我们通过讨论更广泛采用意图的障碍来结束这篇文章。

Across 的意图架构

要实现基于意图的链抽象的最佳用户体验，我们需要一个竞争激烈的求解者网络

使用意图进行桥接取决于求解者网络效应，以表现出比消息传递变体更好的性能。这是意图与消息传递架构之间的核心权衡。现实情况是，并非所有产生意图的应用都需要访问一个完全竞争的求解者集合，有些可能更倾向于将他们的意图路由到寡头求解者网络。然而，当前的求解者网络状态尚不成熟，远未达到意图市场所依赖的求解者网络活跃性的假设。

我们不希望看到每个 DApp 都将意图路由到孤立的求解者网络的世界。最理想的用户体验情况是，许多 DApp 与同一求解者池进行通信，并且所有 DApp 都有自由更改它们发送意图的求解者池。

我们如何引导求解者网络的启动？

我们必须优先考虑求解者用户体验。

运行意图求解器是复杂的，需要在构建高性能软件和管理跨链库存风险方面具有专业知识。自然而然地，只有少数利益相关方愿意支付运行此代码的启动成本。在最理想的情况下，为一个DApp编写的求解器，比如UniswapX求解器，可以被重新利用来解决其他产生意图的DApp，如Across和CowSwap。

我们真的需要增加所有基于意图的DApp的求解者网络的总体资本效率。这将需要解决运行求解器的障碍。

为此，我们需要确保产生意图的DApp对任何求解者可见，并确保所有求解者都能够访问多样化和竞争激烈的意图结算网络。这将使求解者有信心选择将他们的意图履行路由到他们信任的结算网络。结算网络之间的竞争也会降低求解者的成本。

意图结算网络的价值主张是为求解者提供安全性以及影响求解者履行意图能力的其他功能。

求解者选择的意图结算网络将影响他们向用户提供费用和执行时间保证的能力。一些结算网络可能会提供求解者独占期，这将支持在链下拍卖中进行开发，求解者和用户可以在其中进行协商并承诺中继费用。（这些意图拍卖可能还提供经济保证的预确认，进一步增强用户体验。要了解更多关于通过拍卖和预确认发现意图的用户流程，我推荐观看 Sorella 的 Karthik 的这个演讲。）

一些结算网络可能会提供意图到期（即，在达到某个履行截止日期后将价值发送回用户）、意图担保（即，如果没有求解者履行意图，结算网络将使用自己的资产表来履行用户的意图）或灵活的偿还链（即，允许求解者选择他们想要偿还的链）。

最终，结算网络将竞相快速、廉价地偿还求解者，而不会影响安全性。作为回报，求解者将把他们的订单流发送到那些允许他们向用户提供最便宜费用的结算网络，以便赢得DApp的订单流。结算和求解者网络的竞争取决于意图供应链中的所有各方协调一致，竞争将为跨链价值转移带来最佳用户体验。

很明显，我们需要一个跨链意图的标准

如果求解者可以假设意图具有共同的要素，那么他们就可以重用他们的代码来解决由不同DApp发起的意图，并随后降低他们的设置成本。如果不同的DApp创建的意图符合同一标准，那么它们都可以将意图路由到同一求解者池。这将通过为它们提供将其跨链意图直接插入现有成熟的求解者池的能力，帮助引入下一代DApp。新的DApp不需要单独引入求解者，而是可以获得廉价、快速、安全和无权限的价值转移。

如果它们符合标准，第三方跟踪软件也更容易跟踪任何新DApp的意图状态。

这个意图标准应该允许意图的委托方或求解者指定他们希望在哪个结算网络上结算他们的意图

我设想竞争的结算协议，如SUAVE、Across、Anoma和Khalani，为意图求解者提供差异化的功能。根据哪个结算网络向求解者偿还，求解者可以向意图所有者提供不同的价格和时间保证。DApp和求解者可以同意将用户的意图路由到他们信任的结算网络，以避免审查、保持数据隐私，并且足够安全，可以信任偿还求解者。

通过将结算网络的选择写入意图订单本身，求解者可以将这种确定性融入他们向用户展示的报价中。求解者和用户可以在提交意图链上之前消除有关桥梁定价的前期不确定性，从而降低成本。

在与Uniswap合作，并根据CAKE工作组的反馈，Across和我提议以下跨链意图标准，重点是求解者用户体验：

/// @title CrossChainOrder type

/// @notice Standard order struct to be signed by swappers, disseminated to fillers, and submitted to settlement contracts

struct CrossChainOrder {

/// @dev The contract address that the order is meant to be settled by.

/// Fillers send this order to this contract address on the origin chain

address settlementContract;

/// @dev The address of the user who is initiating the swap,

/// whose input tokens will be taken and escrowed

address swapper;

/// @dev Nonce to be used as replay protection for the order

uint256 nonce;

/// @dev The chainId of the origin chain

uint32 originChainId;

/// @dev The timestamp by which the order must be initiated

uint32 initiateDeadline;

/// @dev The timestamp by which the order must be filled on the destination chain

uint32 fillDeadline;

/// @dev Arbitrary implementation-specific data

/// Can be used to define tokens, amounts, destination chains, fees, settlement parameters,

/// or any other order-type specific information

bytes orderData;

}

该标准旨在使求解者的工作更加简单。它做出的一个有主观色彩的选择是，使用 Permit2/EIP3074 本地支持 nonce 和 initiateDeadline，并为填充器提供一些保证，比如他们将从结算网络获得的退款金额以及他们可以追踪的用户意图的格式。此外，标准中定义了一个关键的 initiate 函数，允许填充器（即将订单上链的人）在链上指定额外的“fillerData”，这是用户在签署 CrossChainOrder 时不会知道的信息。这使得填充器可以确保他们会因提交用户的元交易而获得结算合同的奖励，并设置还款特定信息，如还款链。

该标准还旨在使 DApp 更容易跟踪意图履行状态的整个生命周期。任何实现此标准的结算合约都应创建一个自定义子类型 ResolvedCrossChainOrder，可以从任意的 orderData 字段中解析出来。这可能包括涉及交换的代币、目标链以及其他履行约束的信息。标准中还包含了一个 resolve 函数，使 DApp 能够了解如何向用户显示意图状态，并让求解者知道他们正在处理的确切意图订单结构。

/// @title ResolvedCrossChainOrder type

/// @notice An implementation-generic representation of an order

/// @dev Defines all requirements for filling an order by unbundling the implementation-specific orderData.

/// @dev Intended to improve integration generalization by allowing fillers to compute the exact input and output information of any order

struct ResolvedCrossChainOrder {

/// @dev The contract address that the order is meant to be settled by.

address settlementContract;

/// @dev The address of the user who is initiating the swap

address swapper;

/// @dev Nonce to be used as replay protection for the order

uint256 nonce;

/// @dev The chainId of the origin chain

uint32 originChainId;

/// @dev The timestamp by which the order must be initiated

uint32 initiateDeadline;

/// @dev The timestamp by which the order must be filled on the destination chain(s)

uint32 fillDeadline;

/// @dev The inputs to be taken from the swapper as part of order initiation

Input[] swapperInputs;

/// @dev The outputs to be given to the swapper as part of order fulfillment

Output[] swapperOutputs;

/// @dev The outputs to be given to the filler as part of order settlement

Output[] fillerOutputs;

}

/// @notice Tokens sent by the swapper as inputs to the order

struct Input {

/// @dev The address of the ERC20 token on the origin chain

address token;

/// @dev The amount of the token to be sent

uint256 amount;

}

/// @notice Tokens that must be receive for a valid order fulfillment

struct Output {

/// @dev The address of the ERC20 token on the destination chain

/// @dev address(0) used as a sentinel for the native token

address token;

/// @dev The amount of the token to be sent

uint256 amount;

/// @dev The address to receive the output tokens

address recipient;

/// @dev The destination chain for this output

uint32 chainId;

}

A compliant settlement contract implementation MUST implement the ISettlementContract interface:

/// @title ISettlementContract

/// @notice Standard interface for settlement contracts

interface ISettlementContract {

/// @notice Initiates the settlement of a cross-chain order

/// @dev To be called by the filler

/// @param order The CrossChainOrder definition

/// @param signature The swapper's signature over the order

/// @param fillerData Any filler-defined data required by the settler

function initiate(CrossChainOrder order, bytes signature, bytes fillerData) external;

/// @notice Resolves a specific CrossChainOrder into a generic ResolvedCrossChainOrder

/// @dev Intended to improve standardized integration of various order types and settlement contracts

/// @param order The CrossChainOrder definition

/// @param fillerData Any filler-defined data required by the settler

/// @returns ResolvedCrossChainOrder hydrated order data including the inputs and outputs of the order

function resolve(CrossChainOrder order, bytes fillerData) external view returns (ResolvedCrossChainOrder);

}

该标准的设计目标是增强求解者的用户体验，使他们更容易支持多个结算网络，并确定性地计算他们的奖励。我相信这将使他们能够向用户提供更准确、更紧密的报价。您可以在这篇 X/Twitter 帖子以及以太坊 Magicians 论坛上关于它的讨论中阅读有关该标准（代号 ERC7683）的更多详细信息。

结束语

“意图”这个概念令人困惑，因为它们没有明确定义，而这种缺乏定义正在导致真正的用户体验缺陷。

每个人都希望其他人使用他们对意图的标准定义，因此我完全承认制定标准实际上是不可能的。我认为首先定义意图结算系统，然后尝试吸引订单流是建立行业标准的正确方法。

在我看来，更可行的方法是，已经拥有大量用户流量并产生许多用户意图的 DApp 将同意遵循一些最低标准，他们现有的求解者将采用这些标准。这将形成一个新的、更大的求解者池。通过获得来自已经知名的场所的合并订单流，这个新的求解者池将获得更多的利润，并能向最终用户提供更好的价格。最终，新的 DApp 也将要求将它们的意图路由到这个求解者池，并支持其意图标准。

为了让我们开始行动，Across 和 Uniswap 共同提出了一个标准，供所有意图供应链参与方在处理用户订单时使用，以便将 X 代币从链 A 发送并在链 B 上接收 Y 代币。通过 UniswapX（在拍卖设计方面具有比较优势并产生意图）和 Across（在解决意图履行方面具有比较优势）流动的订单流可以合并，并启动培育一个更大、更有竞争力的求解者网络的过程。

本文受到与意图供应链内积极构建的以下人士的现实生活和在线讨论的启发：

来自 frontier.tech 的 Ankit Chiplunkar、Uniswap 的 Mark Toda、Alice Henshaw 和 Emily Williams、Li.Fi 的 Arjun Chand、Sorella 的 Karthik Srinivasan、Khalani 的 Kevin Wang、The Spartan Group 的 tumilet、Across 的 Matt Rice、Ryan Carmen 和 Hart Lambur、Archetype 的 Benjamin Funk 和 Dmitriy Berenzon、Decent 的 Will Kantaros ，以及 Flood 的 Francesco。

最后，我和 Hart Lambur 在 ETH Denver 的演讲中总结了本文的观点：

在哪里可以了解有关意图和链抽象的更多信息

1. UniswapX
2. Frontier.tech 的 CAKE 框架
3. 关于 Intents 的 Anoma 博客
4. Intents、Suave、AA、XChain 桥接都是同一件事 - Uma Roy
5. 基于意图的架构及其风险

声明：

1. 本文转载自[ Mirror ]，著作权归属原作者[Nick Pai]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. 文章其他语言版本由Gate Learn团队翻译， 在未提及Gate.io的情况下不得复制、传播或抄袭经翻译文章。