如何弥补链上与链下之间用户体验的差距？ ZK Rollup 方案处理时间短，可节约运营商的资金成本。

原文标题：《以太坊第 1 层和第 2 层之间的可组合性》
撰文：Loopring

第 2 层解决方案的链上可组合性带来了一些挑战。链下操作确实对于可扩展性很有用，但是我们如何将链上交互与链下逻辑联系起来呢？我们希望构建的 ZK Rollup 交易所成为可组合以太坊生态系统的一部分。我们期待其他 DApp/ 协议集成我们提供的功能，并且用户能够使用其他 DApp/ 协议的相关功能。下文是我们解决问题的方案。

用户可能存在这两种情况：

1. 用户将资产保存在以太坊钱包或链上其他地方，并希望与路印协议构建的交易所进行交互。
2. 用户将资产保存在路印协议构建的交易所中，并希望在其他地方使用链上功能。

我们的目标之一是以最小的摩擦来弥补链上与链下之间的差距，以实现最佳的用户体验。

我们最近开始着手讨论并致力于集成几种链上协议和 DApp。与现有的 DeFi 技术如何集成 ZKP 交易协议相比，这是一个相对较新的领域。

尽管我们将处理上面描述的 2 种简单情况，但值得注意的是，大多数案例都是在用户本身不了解或者不了解幕后的情况下发生的。协议和产品将促进层与层之间的可组合性，最终目标是吸引更多的用户，并且这些用户可以获取更多的功能和流动性。有关示例，请参见下文第四部分。

如果您不了解路印协议 3.0 或 ZK Rollup，请阅读文章。在基于路印协议的交易所上进行交易需要将资产充值到该交易所的智能合约，该交易所在其链下默克尔树（Merkle tree）中为该用户创建一个账户。

1. 链上 ? 链下

这里最明显的解决方案是遵循在路印协议构建的交易所进行交易的标准步骤 :

• 从链上钱包充值资产到交易所
• 创建一个订单，然后等待运营商将其与另一个订单进行匹配，并添加到区块中
• 从交易所提取资产到链上钱包

如果用户希望拥有传统的交易体验，这将非常有用。但是，如果是进行一次简单的交换，速度会很慢，并且会给用户带来非常糟糕的体验。

幸运的是，这可以通过中间人（mediator）来解决。中间人通过在链上和链下扮演相反的角色来促进交互。例如，如果链上用户小红希望出售 1 个 ETH 来换取链下用户小明的 100 个 LRC，那么：

• 中间人收到小红链上钱包的 1 个 ETH，并立即从其链上钱包发送 100 个 LRC 给小红。
• 中间人创建一个 1ETH=100LRC 的订单，因此它可以匹配小明的订单。然后，中间人用其链下钱包支付 1 个 ETH，并在其链下钱包中获得 100 个 LRC。

对于中间人而言，这是一个零和游戏（不考虑交易费的话），他的资产在链上钱包和链下钱包之间进行转移：

• 中间人链上收到 1 个 ETH，并在链下花费 1 个 ETH。
• 中间人链下收到 100 个 LRC，并在链上花费 100 个 LRC。

理论上，交易所上的所有用户都可以通过这种方式进行交互。但是，运营商（relayer）执行这个操作会有很多好处：

• 运营商可以确保交易按预期进行，因为他是创建带有交易的区块的交易者。另一个用户可能会承担无法及时匹配，甚至根本无法匹配订单的风险。
• 运营商可以直接从增加的交易中受益，因为他可以从交易中收取交易费用。
• 运营商可以提供类似的功能，带来极好的用户体验。

2. 链下 ? 链上

如上所述，显而易见的解决方案是再次遵循标准步骤，但现在的顺序有所变化：

• 从交易所提现到链上钱包
• 与链上 DApp 进行交互
• 充值回交易所（如果适用的话）

同样，运营商最好扮演中间人的角色。如果用户想通过从其链下钱包发送 1 个 ETH 与 DApp 进行交互，则运营商将提前使用运营商链上钱包的 1 个 ETH，并在链上存储此证明（以确保该过程可以无需信任地发生）。然后，运营商可以使用此证明，将 1 个 ETH 从用户的链下钱包转移到运营商的链下钱包（这称为有条件转账，我们将在协议的更高版本中实现）。对运营商而言，这也是一个零和游戏。

3. 结论

通过依靠运营商，我们无需信任就可以缩小链上和链下之间的距离，以实现任何类型的交互。该解决方案的唯一缺点是，运营商必须在其链上钱包中存储足够资产，以便可以在链上进行管理。这不是资本使用高效的方法，除非这些服务允许增加的交易量超过其机会成本。此外，资产可以相当快速（5 至 10 分钟）在运营商的链上和链下钱包之间转移，因此运营商的资产总额可以相对较低来支持这些操作。请注意，此类解决方案已经由 Gnosis 和 Starkware 提出，这里只是举几个例子说明。

这些解决方案的设计受到所有第 2 层解决方案中严格限制的约束。对于这样的方案， ZK Rollup 实际上是最好的第 2 层解决方案，因为所需时间很短（一旦在链上提交了证明，我们就可以确保完成工作）。例如，在 Optimistic Rollup, 最终时间要长得多，这极大地增加了运营商提供此类功能所需的资产。

ZKP 以更快的时间进行验证，但出于实际原因，仍然存在间接状态更新的主要问题。这个问题的另一种解决方案是每个人都建立在单个第 2 层解决方案上。随着递归 SNARK 的发展进步，这应该是可能的。如果 DApp，协议和其他版本都进入了第 2 层，在孤立的解决方案中，情况不会变得容易，将会更加困难。

4. 示例

除了普通用户以外，还可以在路印协议生态中找到其他例子，例如 DEX 聚合器和保证金 / 借贷协议。这两种情况可以提供两种方式：从路印协议构建的交易所获取或者提供流动性。

DEX 聚合器在过去的 6 个月里很受欢迎，比如 1inch, DEX.AG, Paraswap, 和 Totle 这样的去中心化应用程序，他们通过聚合流动性给交易者提供最优惠的价格。目前，他们聚集了链上应用（Uniswap，Kyber），也希望能够从第 2 层（如路印协议构建的 DEX）获得流动性。[特别是如果第二层性能支持价差，将获取最有竞争力的价格]。路印协议构建的 DEX 也希望聚集链上应用的流动性，以增强其订单簿的流动性。

保证金 / 借贷协议是开放式金融的重要组成部分，它允许贷款人赚取利息，而借款人获得信贷（尤其是保证金交易）。与使用 DEX 聚合器的情况类似，协议（例如 bZx）希望用户在开仓时，从路印协议流动性中找到匹配的订单。同样地，路印协议也希望其用户可以无需信任地访问其中一些协议。对于后者，一个很好的解决方案是，协议的输出是 token 本身，例如“position token”，由于它只是 ERC20 token，因此可以在路印协议构建的交易所上线。

另外，我们还可以特定为路印协议构建的交易所的用户批量实现可组合性。例如，用户锁仓在交易协议中的资产可以寻找 DeFi 获利机会；可以设置 DAO 来管理存储的资产，并投票决定将这些资产部署在借贷协议中，或者用于其他网络的质押等。确实，我们会实现路印协议 DAO，除了 DeFi 决策外，还将管理某些协议参数。

非常感谢我们的首席架构师 Brecht 撰写了本文的大部分内容。