链抽象服务提供商以及为什么大家对链抽象的理解都是错的

链抽象（Chain abstraction） 在过去的几年里一直是加密领域的热门话题。然而，今年，由于链的快速增加以及账户碎片化导致的加密 UX（用户体验）下降，它成为了焦点。在本文中，我们将探讨三个想法；每一个都旨在规划一条通往链抽象最终目标的道路。

第一个探讨了链抽象的本质，以及为什么当前对该问题的尝试无法满足用户需求。第二个讨论了链抽象作为一个编排和协调问题，而不是一个账户、互操作性或标准问题。最后一个侧重于链抽象提供商和链抽象的最终目标。

链抽象的本质以及为什么当前对链抽象的尝试无法满足用户需求

当用户和构建者提到链抽象时，他们所指的内容之间存在巨大的脱节。对于用户来说，这是从访问其账户的角度来看的。加密账户就像马赛克。每条链都有用户账户的一部分，但没有一个链拥有完整的画面。目前，用户正在使用其账户的碎片与应用交互。当用户说链抽象时，他们实际上是在说，他们希望能够使用其完整的账户在任何链上进行交互，而不仅仅是碎片。对于用户来说，链抽象的本质是将这些账户碎片整合在一起，并允许用户在与任何链上的任何应用交互时利用其完整的账户。

大多数致力于解决该问题的团队不一定对链抽象持有相同的看法。你可以通过检查他们解决该问题的方法来确定这一点。目前，至少有三种关于链抽象的观点。

1. 第一种观点是，链抽象是一个账户可扩展性问题。 构建新账户系统的项目通常持有这种观点。对于构建此类别的开发者来说，链抽象缺失的部分是一个由单个密钥链接在一起的可扩展账户系统。因此，Near 正在构建一个可扩展的 MPC 账户系统。

这种观点的问题在于，可扩展账户不会自动为你提供链抽象。我们知道这一点，因为我们已经有由单个密钥链接在一起的可扩展账户系统，即 EOA。EOA 在使用相同 VM 的所有链上都有相同的地址，并且相同的密钥控制这些账户。然而，EOA 在 EVM 中没有链抽象，这表明链抽象不仅仅是账户可扩展性的副产品。此外，可扩展账户没有任何内在特性能够让用户在每条链上的每个应用上使用其完整账户。

2. 第二种观点是，链抽象主要是一个互操作性问题。 这种观点通常由互操作项目持有，例如，消息传递协议、共享排序器、聚合层、可组合桥 等。对于构建此类别的开发者来说，链抽象缺失的部分是从一条链调用另一条链上的应用的能力。

现在，这种观点有两个问题。首先，我们至少在 2-3 年前就具备了跨链调用应用的能力，但大多数用户会认为我们离链抽象还很远。其次，能够从另一条链调用应用并不意味着你作为用户正在利用你的整个账户，即你的所有账户碎片，与该应用进行交互。

3. 第三种观点是，链抽象是一个标准或框架问题。 这种观点通常由希望创建标准或框架的团队持有，即 CAKE 框架。对于构建此类别的开发者来说，链抽象缺失的部分是一个统一现有层和产品以实现链抽象的标准或框架。例如，CAKE 框架将这些层列为应用层、权限层、求解器层和结算层。该标准的主要目的是定义这些层交互的机制。重要的是要注意，它不是链抽象的完善解决方案。在许多方面，它只是一个旨在引发对话的占位符，并且随着链抽象的解决方案变得更加明显，它肯定会演变成其他东西。也就是说，标准是链抽象缺失部分的观点存在两个问题。

首先，没有已知的上述层的配置能够实现链抽象。这强烈暗示着一个对于启用链抽象至关重要的缺失层。对于该层的需求不会仅仅通过标准化其他层如何交互或通信而消失。其次，在我们了解该缺失部分的完整性质之前，对标准的呼吁还为时过早。存在一种情况——正如我们稍后将展示的——该缺失部分是链抽象最关键的部分，并且它的存在大大减少了对标准的需求。这或许是对像 CAKE 这样的框架最明显的批评：一个突出链抽象关键要素的框架错过了链抽象最关键的要素。可以公平地说，该框架作为对话的开端是有帮助的，但肯定不是启用链抽象的指南。

就用户需求而言，这三种观点均未抓住链抽象的本质。几乎所有上述问题的解决方案都已存在，但我们仍然没有链抽象。一个更准确的链抽象视角是将其视为一个编排和协调问题。

链抽象作为一个编排和协调问题

要理解为什么链抽象是一个编排和协调问题，我们必须回顾 (1) 用户如何在链上进行交互，以及 (2) 我们首先需要链抽象的原因。大多数加密交互都是通过应用前端进行的。典型的交互如下：

1. 用户访问应用的网站或页面并连接其钱包。
2. 应用向用户的钱包发送查询，以确定用户账户的状态。状态可以是 gas 代币、代币余额、代币所有权，任何东西。
3. 用户钱包将这些查询转发给其节点提供商，并将响应返回给应用。
4. 根据响应，应用限制用户能够采取的操作类型。例如，如果你在账户中拥有超过 100 USDC，Uniswap 将允许你尝试需要 100 USDC 的交易。否则，它不会。
5. 一旦用户选择了他们想要采取的操作，应用就会创建一个相应的交易，然后将其转发到用户的钱包进行签名。
6. 交易签名后，钱包会将其发送到其节点提供商，以便将该交易发送到区块链。
7. 当交易被挖掘时，应用的合约的链上状态会发生改变。合约状态的改变会被应用界面拾取并呈现给用户。

详细的步骤概述的目的是表明，用户可以在应用上执行的操作/交易受到用户账户状态的限制，该状态是应用从用户钱包/节点接收到的。现在，要启用链抽象，你需要一个新的层，它需要做三件事：

每个步骤都解决了启用链抽象的一个关键摩擦点。

步骤 1 解决了我们之前强调的关于应用前端使用用户账户状态限制用户操作的问题。此步骤确保用户可以在应用前端采取的操作由其整个账户状态而不是其一部分状态决定。

现在，即使一个用户设法说服一个应用前端使用他们的整个账户状态来创建交易，链上的状态可能与交易成功执行所需的状态不一致。步骤 2 通过识别用户所有账户碎片中需要发生的所有状态转换来解决此问题，以使呈现的交易成功。

最后，知道是不够的。即使我们知道交易成功所需的所有必要状态转换，因为有了步骤 2，系统也必须编排和促进这些状态转换，否则交易将失败。这是步骤 3 的目的。

所有这些都是编排和协调问题！

一个新的类别出现：链抽象提供商

有了处理上述三个编排和协调问题的系统，无论你在账户、互操作或标准层面做什么，你都可以提供链抽象。任何想要为用户提供链抽象的团队都需要访问一个处理这种编排和协调的系统，而构建这个系统是一项繁重的任务。

步骤 1 和步骤 2 需要开发一个专用的账户统一节点。我们称之为账户统一（AU）节点，它必须始终与所有链同步，才能为数百万使用加密货币的人创建一个完整的账户状态配置文件。它必须确定所有这些链中必须发生的状态转换，以使任何随机交易成功。最后，它必须能够在任何时候支持对此信息的查询。

步骤 3 是状态转换的编排和促进，需要创建一个用于指定任意链状态的市场。这个市场可以是中心化的，但为了与加密货币的精神保持一致，最好将其变成一个协议。一个用于指定任意链状态的链上市场是一个通用的意图协议，它有自己的 DSL 和链上解释器。 此外，还需要做大量工作才能将市场扩展到每条链，包括那些不支持智能合约的链。 注意：重要的是不要将其与声称使用意图的桥或 RFQ 交易所混淆。

构建该系统所需的技术开销将需要创建一个专门用于链抽象的新类别中间层。我们称这些中间层为链抽象提供商。我们知道这一点，因为我们已经有节点服务提供商方面的出色例子。很少有加密货币项目运行自己的节点。大多数项目都避免这样做，因为运行和维护一个节点很繁琐。构建、运行和维护一个链抽象提供商将同样繁琐，甚至可能更繁琐。

链抽象提供商是链抽象的最终目标

链抽象提供商是链抽象的最终目标。它们的易于集成和非侵入性，加上它们对 web3 UX 的促进，将使它们成为加密堆栈的关键部分，就像节点服务提供商一样。

想象一下一个简单的集成，类似于 RPC 端点，它可以为使用任何账户系统的任何钱包提供一个链上加密体验，类似于中心化交易所的体验 —— 能够使用你的整个账户和所有资产与任何链上的任何应用进行交互。

想象一下这样一个世界：以太坊上有 10 USDC、Polygon 上有 5 USDC 以及 Arbitrum 上有 5 USDC 的用户可以将他们的钱包连接到 Base 上的一个应用，并执行一笔 20 USDC 的交易，同时在 Solana 上以 $WIF 支付 gas 费用。

想象一下这样一个世界：你可以使用你在中心化交易所账户中的资产与任何链上的应用进行交互，有效地模糊了链上和链下体验之间的界限。

这就是链抽象提供商所实现的世界。

下周，我们将推出 Orby，这是第一个链抽象提供商。我们在 Orb Labs 过去一年里一直在研究它，它将让你一窥加密货币 UX 的未来。

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