Lagrange Labs：模块化区块链的互操作性

2023-06-28 15:26:20 佚名

简介这篇文章主要介绍了Lagrange Labs：模块化区块链的互操作性的相关资料,需要的朋友可以参考下本文详细内容介绍

自从像Celestia和EigenLayer这样的协议引发了关于区块链执行、结算、排序和数据可用性层解耦的争论以来，“模块化区块链”已经成为每个加密爱好者最喜欢的话题。虽然模块化理论的支持者支持未来会有许多(专业)区块链共存，但一个价值数十亿美元的问题是：“我们究竟计划如何连接这些链？”

这不是一个小问题，特别是因为区块链之间的互操作性提供了许多好处。现有的互操作性解决方案，例如消息传递协议和桥接，但是它们当前的实现存在缺陷，限制了它们连接越来越分散的专门执行和结算层组的能力。

Lagrange协议是一种新的互操作性解决方案，它可以帮助协议绕过许多这些限制，并为去中心化应用程序释放跨链交互的全部好处。在本文中，我们将探讨ZK MapReduce(我们之前介绍过)如何为Lagrange模块化区块链的去信任、安全、可扩展和高效互操作性愿景做出贡献，并为开发人员和用户解锁新颖、令人兴奋的用例。

模块化区块链：简短入门

模块化区块链将执行、共识、结算和数据可用性的功能分开。单块区块链在同一层上协调这些活动，模块化区块链处理其中的一些任务，并将其余部分外包给其他区块链。这种架构受到模块化设计思想的启发，使模块化区块链比单片区块链更灵活、更可扩展。

模块化区块链也更容易部署/引导，因此对希望扩展应用程序吞吐量(每秒交易量)但缺乏资源从头开始构建特定于应用程序的区块链的开发人员具有吸引力。有了模块化的区块链平台，开发人员可以专注于为dApp构建高度可扩展的执行层，同时依靠更安全的区块链来保证安全性（这种方法越来越多地被描述为“rollup -as-a-service”）。

模块化区块链通过创建专用的区块空间来帮助横向扩展TPS，并支持高频交易、游戏和社交等需要高通量、低成本计算的应用程序(单块区块链很少提供)。但是，向模块化区块链架构的转变也会产生新的问题，如果处理不当，这些问题可能会完全消弱“构建模块化”的好处。

了解模块化区块链的缺点

自LazyLedger白皮书首次概述模块化论文以来，许多团队一直在构建核心基础设施，以简化模块化区块链的创建。著名的例子包括rollup-a-service平台(Sovereign Labs、Caldera、Eclipse、Rollkit、dimension)和数据可用性层(EigenLayer、Celestia、Avail)。因此，部署新的特定于应用程序的区块链来扩展web3 dApp的障碍已经大大减少。

诚然，“一键部署rollup”的能力很棒，但是，成百上千个区块链共存的世界也有一些缺点。其中一个缺点是互操作性(我们将在本节中详细描述)。

假设 Bob（一个开发人员）想要创建一个特定于应用程序的rollup来扩展新 DeFi 应用程序的交易，我们将其称为 BobDEX。Bob开始使用Celestia进行数据可用性/共识，使用以太坊进行规范桥接(结算)，但转向“多链”策略，并最终在十几个其他特定应用程序的rollup上启动了DEX实例。

现在，区块链在其他地方被描述为“岛屿”，因为它们缺乏共享价值(资产)和信息(状态)的原生基础设施。采用模块化的区块链架构——就像BobDEX一样——通过在多个执行和结算层之间碎片化状态和流动性，进一步加剧了互操作性问题。

让我们简单地解决这两个问题：

1. 状态碎片化：在模块化区块链架构中，应用程序的状态存储在不同的执行层，检索和验证数据更加困难。运行在单块区块链上的应用程序没有这个问题，因为所有的合约状态(当前和历史)都存储在同一个网络上。

随着我们进入跨链的未来(单个应用程序可以存在于多个第1层(L1)、第2层(L2)和第3层(L3)区块链上)，状态碎片化可能会产生更广泛的影响。例如，如果每个合约部署到不同的链上，那么基于不同智能合约状态之间的复杂关系来构建应用程序就会变得困难。

一个简单的例子是跨链借贷协议，该协议允许用户在源区块链上锁定抵押品，并在目标区块链上借入代币。在这里，运行在两个不同链上的智能合约必须就某些信息达成共识，例如用户是否锁定了代币。这很难做到，因为正如我们之前解释的那样，区块链是独立的“孤岛”，无法交换数据。

2. 流动性碎片化：流动性是指在不显著影响其价格的情况下，将一种资产转换为法定资产或另一种资产的便利性和效率。流动性对DeFi应用程序很重要，因为它会影响用户体验的滑点程度，尤其是在大额交易中。

部署到单个单链的DeFi协议在流动性方面几乎没有问题，因为所有用户都在同一网络上进行交易。相比之下，跨越多个链的DeFi应用程序在某些链上的流动性较低。由于资产不能在区块链之间流动(根由于互操作性问题)，DeFi用户仅限于特定链上可用的流动性。

除了降低整体用户体验外，流动性差也会阻碍DeFi项目的多链增长。具体来说，一些用户可能会避免在低流动性区块链上使用DeFi应用程序，因为担心交易出现高滑点或无法退出大量头寸。举一个早期的例子：Alice可能更喜欢在以太坊上使用BobDEX(因为它的TVL高)，而不是在NEAR上使用BobDEX(因为它的TVL低)。

解决模块化区块链的互操作性问题

“你所在领域最重要的问题是什么？你为什么不去解决它们？”——Richard Hamming

到目前为止，许多人都认为模块化区块链的扩散是不可避免的。但是，如果模块化的未来不能保证web3区别于web2的品质：去中心化、可组合性和互操作性，那么它就不是理想的。

从前面的示例中，我们看到了应用程序如何通过离开共享状态层而失去可组合性和互操作性。我们还看到，扩展到新的结算层(或规范桥接层)如何破坏应用程序的流动性和网络效应，从而导致糟糕的用户体验。

所有这些都是采用模块化区块链的绊脚石，并引发了人们对多链未来可行性的担忧。认识到这个问题，许多项目正在研究解决方案，以提高模块化区块链之间的互操作性，并缓解状态和流动性碎片化问题。

其中包括：

共享排序网络

Espresso和Astria正在建立一个去中心化的排序器网络，可以由多个模块化rollup共享。有时被描述为“惰性排序器”，一个共享的排序器集合将来自不同rollup的交易排序到单个“mega块”中，并提交给像Celestia这样的数据可用性层，而不执行rollup交易。各个rollup节点从数据可用性层(或排序网络)检索块，并执行相关交易来更新rollup的状态。

共享排序器使新的执行层能够从一开始就实现去中心化、审查阻力和快速最终确定(无需运行内部排序器基础设施或花费精力引导去中心化的排序器集)。共享的排序器网络还通过支持跨链交易的原子包含来提高rollup之间的可组合性和互操作性。

如前所述，共享排序器生成的块包含要在不同rollup上执行的交易。因此，它可以保证Rollup #1上的交易包含在一个块中，条件是该块包含Rollup #2上的另一个交易。这为跨链通信解锁了新的用例，例如跨链套利交易和资产桥接。

共享排序器为有条件的跨链交易提供了机会(来源)

然而，这是一种过于简单化的说法。为了深入了解共享排序的机制，我们建议读者参考Maven11的共享排序的知识系统(SoK)，其中涵盖了共享排序器的各种好处和属性，包括互操作性。Succinct Labs还有一个有趣的提议，用于在共享排序器的rollup之间同步执行原子交易包。

“共享排序是模块化堆栈的重要组成部分，减少了启动rollup的工作量，同时允许它们在默认情况下去中心化。——Josh Bowen ，Astria创始人

消息传递协议

通用消息传递协议支持在不同链之间传输任意消息。在高层次上，消息传递协议通过在链之间验证和中继数据包来解决状态碎片问题。这使得原本孤立的链能够了解彼此的状态，从而支持比资产桥接或跨链原子交易更丰富的数据用例。

跨链借贷(我们之前描述过)就是一个例子。为了实现这个用例，开发人员可以集成像LayerZero、Axelar、Hyperlane或Wormhole这样的消息传递框架，以在源链和目标链上运行的应用程序实例之间中继有关链上操作（打开或关闭抵押头寸）的信息。

对于状态分布在不同层的模块化区块链，消息传递协议提高了连接性和可组合性。例如，Hyperlane已经推出了集成，允许用户从Celestia和FuelVM的主权rollup上发送消息。

标准化跨链消息传递的一种流行方法是区块链间通信协议(IBC)。虽然IBC因在Cosmos生态系统中的采用而变得流行，但它的设计也可以扩展到其他链。

Polymer Labs正在构建一个“模块化IBC传输中心”，将IBC与零知识加密技术和基于Tendermint的共识引擎相结合，以促进模块化链之间无缝、信任最小化的通信。他们的ZK-IBC设计旨在创建一个模块化标准，允许不同的区块链协议通过共识验证来支持消息传递，而不依赖于受信任的第三方。

“ZK-IBC，或IBC传输层的电路实现，将使ZK-rollup中的原生IBC以及模块化生态系统中区块链的信任最小化通信成为可能。”——杜波，Polymer联合创始人

跨链流动性路由器

流动性路由器使用户能够在一对区块链之间转移资产，例如，用户可以通过使用流动性桥将资产从Eclipse rollup移动到Caldera rollup上，从而与BobDEX进行交互。流动性路由基础设施解决了模块化生态系统的一个紧迫问题：在尝试与新链上的应用程序交互时，用户体验差。

强大的跨链流动性层提供了一种从其他生态系统获取流动性的简单方法，从而降低了在新链上启动经济活动的难度(缓解了流动性碎片化的问题)。这就是Catalyst（用于跨链资产交换和资产池的自动做市商（AMM））等解决方案的用武之地。

“未来将有数百万条链，而该领域很少有人积极尝试以未来所需的规模进行建设……在未来，流动性将日益分散——这就是为什么我们正在构建 Catalyst 来统一流动性进入共享层。”——Jim Chang, Catalyst联合创始人

分析现有的互操作性解决方案

共享排序器、消息传递协议和流动性路由器对于支持模块化区块链之间的基本互操作性至关重要，例如资产转移和简单消息传递。但它们的设计主要是为了实现高性能的一对一互操作性——也就是说，在相同或不同的生态系统中运行的协议对之间的跨链交互。

这是什么意思呢？在目前的形式中，上述解决方案并未针对支持其业务逻辑需要访问跨越日益分散的执行层和结算层组的多个并发合约状态的应用程序进行优化。我们将这种形式的互操作性描述为n对1互操作性，因为它需要在无限数量的链之间创建关系。

为了说明这个想法，考虑这样一个情况：Bob想要创建一个“跨链DEX”，在部署的每个链上强制执行资产交换的全球价格。基于 AMM 的 DEX 价格掉期使用所谓的“守恒函数”，该函数考虑了交易中涉及的代币对的流动性。因此，跨链DEX需要跟踪所有部署的流动性状态，并使用这些信息来计算代币互换的价格。

人们可能很自然地希望与消息传递协议集成，以便在每次交换、存款或取款发生时，将一条链上DEX流动性的变化中继到其他链上的DEX。但是这种方法会产生巨大的成本和延迟，并且在生产环境中很难实现。

例如，如果BobDEX在五条链上运行，并且在一条链上发生了交换，那么我们将需要四个单独的交易来将此事件传递给其他部署，然后才能调整价格。正式地说：随着应用程序部署在链的数量n的增长，所有实例之间通信的消息传递复杂性也随着n2的增长而增长。

这种机制(使用预言机和消息传递协议)也会受到隐藏故障模式的影响。例如：中继器/预言机可以检查跨链消息或中继不正确的数据，在这种情况下，剩余的BobDEX应用程序将使用过时/不正确的价格运行。

正如你所看到的，消息传递或资产桥接框架是必不可少的，但并不能单独解决像BobDEX这样的多链应用程序的互操作性。Bob和他的团队需要的是一个具有以下特性的互操作性解决方案：

• 能够在不引入任何信任假设的情况下，将一条或多条链上的智能合约状态证明给其他n条链上的智能合约

• 能够大规模地证明跨链合约状态，而不会增加延迟或成本或降低整体用户体验

• 以最小化信任、安全和高效的方式对跨链状态数据执行计算的能力

最后一点(对链上数据的计算)在构建具有多链关系的应用程序的背景下很重要。例如，消息中继器可以向不同rollup上的特定 BobDEX 证明给定 BobDEX 实例上的流动性数量，但缺乏获得除当前状态之外的有关链的任何属性的能力。例如，DEX不能使用这些信息来运行复杂的定价算法，例如根据不同链的历史流动性计算资产的时间加权平均价格(TWAP)。

ZK MapReduce和模块化区块链互操作性堆栈

既然我们已经煞费苦心地强调了扩展互操作性基础设施范围的机会，那么我们一定有办法改进它们吗？是的，我们有！

Lagrange Lab构建了基础设施，通过提高链之间状态证明方式的安全性并扩展可在跨链状态上运行的计算类型来扩展无需信任的互操作性。更具体地说，拉格朗日实验室的解决方案套件提供了一种方法，可以有效增强现有消息传递协议和桥的安全性，并扩展跨链数据在应用程序中的使用方式。

更好的是，Lagrange Lab在完成这一切时不会给用户和开发人员带来额外的信任假设负担。Lagrange Lab跨链计算的旗舰产品是ZK Big Data：一种新颖的证明结构，用于生成大型（批量）存储证明并执行由零知识密码学保护的分布式计算。

ZK MapReduce是Lagrange ZK Big Data堆栈中的第一个产品，是一个分布式计算引擎(基于著名的MapReduce编程模型)，用于证明涉及大量多链数据集的计算结果。例如，单个ZKMR证明可用于证明在指定时间窗口内部署在4-5条链上的DEX的流动性变化。

ZK MapReduce 证明旨在使多链状态数据帧组合到单个证明中变得容易。该属性允许任何人在不与目标链以外的任何其他链交互的情况下，将n个源链上的智能合约状态证明给目标链(n+1)上的智能合约。通过调用Lagrange的链上公共验证器合约，合约可以很容易地验证在跨链状态上运行的计算。工作流程如下所示：

• 客户端合约将公开声明(被证明的数据)和随附的有效性证明传递给验证者合约

• 验证者合约返回true或false值，以确认存储数据和计算相对于证明是否有效（或无效）。

在目前的架构下，Lagrange ZK Big Data堆栈可以支持生成同时证明合约存储和计算的证明：

1. 合约存储：Lagrange状态证明可以引用给定链上一个或多个合约的存储内容。这需要将状态根(来自块头)、存储槽值和Merkle Patricia Trie (MPT)包含证明传递到证明电路中，并生成有效性证明。(需要MPT证明来确认这些值是链状态树的一部分)

2. 计算：Lagrange状态证明可以参考使用从特定链上的合约派生的存储槽值执行的计算结果。这就是ZK MapReduce发挥作用的地方——在证明某些合约值存在于特定块头之后，我们可以对这些值执行任意的MapReduce计算。

在这种情况下，状态证明验证(a)一组历史区块头与输入区块头相比是有效的，并且包含某些合约值，(b)对这些合约值的计算提供了特定的结果。Lagrange的互操作性基础设施的这一方面有独特的好处（并且很大程度上被低估的）：能够证明涉及当前和历史数据的复杂多链(n对1链)关系。

考虑前面的跨链DEX示例，该示例旨在基于来自不同链的流动性数据对掉期进行定价。我们已经讨论过，现有的跨链通信机制很难在不产生大量开销和继承弱安全属性的情况下实现此用例。

相比之下，Lagrange——通过ZK MapReduce——可以在不影响成本、安全性和效率的情况下支持这个用例。这里有一个假设的两步工作流程来说明这是如何实现的：

1. 证明生成：通过在ZKMR证明中验证跨链合约状态和该状态的计算结果来证明每个DEX的流动性数据。

2. 证明验证：在生成证明后，可以将其提交到目标链，以显示产生请求值的计算的正确性(所有部署的DEX流动性总和)。证明的提交可以由任何传输层处理，从预言机到消息传递协议再到自动保存器。

在实践中，可以使用Lagrange SDK 请求Lagrange状态证明（包括 ZK MapReduce 计算的证明）。这使得应用程序可以轻松地生成证明并将其集成到任何现有的基础设施中，而不需要专门的证明系统或硬件。

“随着区块链世界变得越来越模块化，越来越多的区块链将加入竞争。跨链互操作性是模块化理论的核心，虽然共享数据处理层有助于缓解其中的一些问题，但它并不能完全解决问题。在我看来，用于维护跨链连接的跨链互操作性协议应该首先关注安全性。最有可能的前进方向是零知识轻客户端验证(或通过委员会进行的跨链状态/存储证明)，以及强大的经济安全保证。大量质押抵押品的经济债券可以用来实现对最终性的有力证明。仍有待解决的两个主要问题是通过ZK MapReduce和递归等改进来提高ZK的可扩展性，以及降低社交削减带来的信任。”- Rain&Coffee, Maven11研究员和投资者