Opside 的 NCRC 无信任原生协议成为焦点

Opside已在测试网上成功实施 NCRC。现在任何人都可以在官方网站https://pre-alpha-assetshub.opside.network/ 上体验它。

为什么我们需要无需信任的交叉汇总通信？

Rollup 因其增强区块链可扩展性、降低交易成本和提高整体效率的能力而受到广泛关注和采用。 Opside 为 Web3 应用程序提供 ZK-RaaS 服务，使开发人员能够通过 Opside Rollup Launchbase 创建自己的 Rollup。在这个多个 Rollup 的时代，我们预计各种 Rollup 会越来越共存，这使得不同第 2 层解决方案之间的无缝互操作性变得至关重要。

目前，Rollups 之间的交互仍然相对孤立，缺乏实时的跨链通信和资产互操作性。这种隔离导致了碎片化的格局，资产被限制在特定的 Rollups 内，限制了它们在不同网络之间的自由流动和利用。

缺乏有效的跨 Rollup 通信不仅限制了单个 Rollup 的潜力，而且还会影响整体用户体验。尝试在 Rollup 之间转移资产或执行跨链交易的用户面临着繁琐且耗时的过程。这种次优的体验削弱了 Rollups 的吸引力，并在一定程度上阻碍了 Layer 2 扩展解决方案的广泛采用。

现有的跨 Rollup 桥接解决方案通常涉及在 Rollup 链上部署新的链间合约集，并利用多链流动性激励来实现资产跨链功能。然而，这些解决方案并不普遍适用于基于消息的跨链交互，并且存在中心化和信任的风险。

为了充分释放多Rollup时代的潜力，迫切需要一种去信任的、通用的跨Rollup通信协议。

Opside的解决方案：Native Cross Rollup Communication

事实上，每个 ZK-Rollup 本质上都带有一个 L1<>L2 桥，我们将其称为 Native 桥。与利用基于流动性的方案的第三方桥不同，本机桥以独特的“薄荷燃烧”跨链机制运行。它通过零知识证明确保安全，同时保持去信任性。 Rollup 上的所有资产都源自通过本机桥的存款交易，并从中获得最终的安全背书。

我们坚信奥卡姆剃刀原则——“如无必要，勿增实体”。第三方桥可能提供更便宜、更快的跨链体验，但它们会带来额外的信任成本和安全风险。最近发生的多链事件就是一个很好的例子。因此，从一开始，Opside 对于跨 Rollup 通信的灵感就很简单：直接利用原生 Bridge 来实现多 Rollup 互操作，而不是引入额外的第三方 Bridge。这个概念催生了 NCRC（Native Cross Rollup Communication）协议。

NCRC 的先决条件

要在多个 Rollup 之间启用 NCRC，需要满足以下两个先决条件：

• 这些Rollup必须属于ZK-Rollup类型。

• 这些 Rollup 必须驻留在同一 L1 上。

  
  

满足这两个条件的 Rollup 理论上具有与底层 L1 相同级别的安全性。同样，这些 Rollup 之间的本机桥的安全级别是相同的，并且不需要它们之间的信任。所有 NCRC 交易均经过有效性证明验证，是 NCRC 安全保证的根本来源。

Rollup认可合约（RRC）

截至 2023 年 8 月，多个 ZK-Rollups 已在主网上上线，包括 Polygon zkEVM、zkSyncera、Linea 等。然而，这些ZK-Rollups都是独立且互不相关的，导致用户资产碎片化。造成这个问题的根本原因在于他们在L1（以太坊主网）上的合约是不相关的。他们仍然不知道彼此的存在，并且无法通过本机 Rollup 桥直接进行通信。

因此，我们需要采取的第一步是在L1上部署专门的合约，以使Rollups能够发现并识别彼此。这称为 RRC（Rollup Recognition Contract）。 RRC 负责管理 NCRC 中所有参与的 ZK-Rollups，包括 Rollups 的添加、暂停和退出。 RRC 内的每个 Rollup 都分配有一个专用的 Rollup ID，而 L1 的 ID 保持固定为 0。

当通过 Rollup 上的本机桥发起跨 Rollup 交易时，地址可以指定目标 Rollup ID：

• 如果Rollup ID为0，则表示消息穿越到L1，例如提现。
• 如果Rollup ID不为0，则表示将消息发送到另一个Rollup。

Opside 将在每个 L1 层部署一个 RRC 合约，并允许相应的 ZK-Rollups 未经许可加入或退出。该 RRC 合约将用于维护每个 Rollup ID 的信息，包括 L1 上的桥接合约地址。需要注意的是，RRC合约仅提供数据检索服务，并不直接与跨链资产交互。

与 Native Bridge 智能合约和服务的兼容性

一般来说，Rollup 的原生桥接分为三个组件：L1 上的桥接合约、L2 上的桥接合约以及负责消息中继的桥接服务。 NCRC 协议在底层利用这些组件并添加更高级别的封装。主要修改如下：

• L2上的桥接合约：在保留原有方法的同时，添加了一个名为bridgeAsset的新方法。该方法允许用户在destinationNetwork参数中指定目标Rollup的ID。

• L1上的桥合约：封装了一个新方法来处理新的bridgeAsset方法的跨链消息。桥接合约根据RRC合约中找到的Rollup ID，定位到目标Rollup的信息，并将跨链资产转移到目标Rollup的桥接合约上。跨链资产存入目标Rollup中。

• Bridge服务：负责消息中继，并向用户收取跨Rollup交易的费用。

  
  

一旦Rollup完成了上述NCRC相关的兼容性适配，它就可以向RRC注册加入本机跨Rollup通信网络。

原生交叉Rollup交易流程

对于用户来说，NCRC的操作与Rollup原生的bridge完全一致。发起从Rollup1到Rollup2的跨Rollup交易是一个自动化的过程，包括以下步骤：

1. Rollup1上的发起者User1调用本机bridge的bridgeAsset方法来发起跨链交易。该事务中的destinationNetwork参数设置为Rollup2的Rollup ID。该 Rollup ID 将用于检索相应的 L1 桥接合约地址。如果 Rollup ID 为 0，则表示目标网络为 L1。

   
   

2. 随后，这笔交易被Rollup1的Sequencer1打包。发起者 User1 承担跨 Rollup 交易的费用，将其支付给 Rollup1 上的 Sequencer1。 Rollup1 的 Bridge 服务随后将跨链资产转移到 L1 上的 Rollup1 桥接合约上。至此，Rollup1和L1都完成了资产的刻录和释放操作。

   
   

3. 为了完成跨Rollup资产转移，Rollup1的Bridge服务会查询RRC合约，获取destinationNetwork参数对应的目标Rollup2的信息。该信息提供了 Rollup2 的 L1 桥接合约地址。然后，Rollup2 的桥接合约控制这些资产，并通过bridgeAsset 方法将它们映射到Rollup2。

   
   

4. 最后，一旦交易成功打包并生成证明，Rollup2的Bridge服务就会执行claimAsset操作。由此，Rollup1发起的跨链资产安全到达Rollup2上的指定地址。

值得一提的是，在整个跨链过程中，用户的资产流转路径为：Rollup1 -> Rollup1 的 L1 桥接合约 -> Rollup2 的 L1 桥接合约 -> Rollup2。也就是说，用户的资产不经过任何第三方协议；他们利用 Rollup 的原生桥。整个过程是安全且无需信任的。

当用户在Rollup1上执行跨链操作，选择Rollup2作为目的地时，技术流程实际上涉及三个实体：Rollup1、L1和Rollup2。但在此过程中用户不需要意识到L1的存在；他们的经验只是从 Rollup1 到 Rollup2 的直接交叉。底层的现实是，跨链资产在L1上经过两次桥接操作，在用户的感知中形成了从Rollup1到Rollup2的无缝连接。在此过程中，L1上的操作是自动处理的，用户不需要执行任何额外的操作。从用户的角度来看，他们当前的 Rollup 可以对 L1 和任何其他 Rollup 执行跨链操作。这种设计增强了用户体验的流畅性，同时隐藏了潜在的复杂性。

NCRC 现已在 Opside 测试网上上线！

Opside 已在测试网上成功实现了本机交叉汇总通信。任何人现在都可以在官方网站上体验它

https://pre-alpha-assetshub.opside.network/我们也欢迎用户和开发者帮助我们识别潜在的错误和安全风险，并提供任何宝贵的建议。

我们相信，无需信任的原生跨 Rollup 通信不仅可以安全地共享所有 Rollup 之间的流动性，而且还可以提供强大的多 Rollup 互操作性，为去中心化应用程序和DeFi 协议开辟新的可能性。