温馨提示：这篇文章已超过640天没有更新，请注意相关的内容是否还可用！
作者：Opside
TL; DR
Opside的NCRC（Native Cross Rollup Communication） 协议提供了一种无需信任的Rollup互操作性解决方案。NCRC协议并不是在各个Rollup上额外添加一个第三方桥，而是在系统层面改造了ZK-Rollup自带的bridge（native bridge），从而直接使用各个ZK-Rollup的native bridge来实现跨Rollup通信。这样的做法更加简洁和彻底，既继承了native bridge绝对的安全性，也避免了第三方桥所带来的系统复杂度和信任成本。
为什么我们需要无需信任的跨 Rollup 通信？
Rollup 能够显著提高区块链网络的可扩展性、降低交易成本并提高整体效率，它们受到越来越多的关注和使用。Opside为Web3应用提供ZK-RaaS服务，任何开发者都可以通过Opside Rollup Launchbase创建自己的Rollup。在这个多 Rollup 的时代里，我们预计会有越来越多的 Rollup 共存，因此不同的 Layer 2 之间的无缝互操作性变得至关重要。目前，Rollup 之间运作相对孤立，缺乏实时的跨链通信和资产互通。这种隔离导致了碎片化的格局，其中资产在特定的 Rollup 内被隔离，限制了它们在不同网络之间的自由流动和利用。
缺乏高效的跨 Rollup 通信不仅限制了各个 Rollup 的潜力，还影响了整体用户体验。用户在尝试在 Rollup 之间转移资产或执行跨链交易时面临繁琐而耗时的流程。这种次优的体验削弱了 Rollup 的吸引力，并在一定程度上阻碍了二层扩展方案的广泛采用。
目前的跨Rollup桥接方案大部分是在Rollup链上部署新的一套跨链合约，然后通过多链流动性激励机制来提供资产的跨链。这些方案并不是通用的消息跨链，同时带来了中心化和信任的风险。
为了释放多 Rollup 时代的全部潜力，迫切需要一种无需信任的通用的跨 Rollup 通信协议。
Opside的解决方案: Native Cross Rollup Communication
实际上，每一个ZK-Rollup都自带一个L1<>L2的bridge，我们称之为Native bridge。与第三方bridge采用流动性方案不同，Native bridge是唯一的“mint-burn”跨链机制。它由零知识证明来保证安全性，同时也是无需信任的。一个Rollup上所有的资产，都来自native bridge的deposit交易，同时也都由native bridge来提供最终的安全性背书。
我们坚信奥卡姆剃刀原理，“如无必要，勿增实体（Entities are not to be multiplied beyond necessity.）”。第三方桥拥有更加便宜和快捷的跨链体验，但也带来了更多的信任成本和安全风险。前不久的Multichain事件，就是一个案例。因此，在一开始，Opside的跨rollup通信的灵感就简单得出奇：直接使用native bridge来实现多rollup互操作性，而不是新增一个第三方的桥。这就有了现在的NCRC（Native Cross Rollup Communication） 协议。
NCRC的前提条件
多个Rollup之间实现NCRC需要满足以下2个前提条件：
这些Rollup属于ZK-Rollup类型
这些Rollup在相同的L1上
满足以上2个条件的ZK-Rollups，在理论上，拥有和L1一样的安全性。同样地，这些Rollup之间的native bridge的安全等级是一样的，且无需信任对方。所有的NCRC交易都是被validity proof所验证的，这也是NCRC的安全性保证的根本来源。
Rollup Recognition Contract（RRC）
截至2023年8月，已经有多个ZK-Rollups主网上线了，包括Polygon zkEVM、zkSync Era、Linea等。然而，这些ZK-Rollups之间是独立不相关的，用户的资产也因此碎片化。造成这种问题的根本原因在于，它们在L1（以太坊主网）上的合约是不相关的。它们感受不到对方的存在，更无法实现原生Rollup bridge的直接通信。
因此，我们要做的第一步，是在L1上部署一个特殊的合约，来让Rollup互相发现和识别。我们称之为RRC（Rollup Recognition Contract）。RRC负责管理所有参与NCRC的ZK-Rollups，包括Rollup的新增、暂停、退出等。RRC中的每个Rollup，都会有一个专属的Rollup ID，L1的ID则固定为0。
Rollup上的地址在native bridge发起跨Rollup交易时，可以指定目标的Rollup ID：
如果Rollup ID为0，则表示把消息跨到L1，例如withdrawal
如果Rollup ID不为0，则表示要把消息跨到其他Rollup
Opside将在每一个L1 层都部署了一个RRC合约，并允许对应的ZK-Rollup无需许可地加入或者退出。这个RRC合约将用于维护各个 Rollup ID 对应的Rollup信息，包括L1上的bridge合约地址等。值得一提的是，RRC合约只是负责提供数据检索服务，不会跟跨链资产产生直接联系。
兼容native bridge的smart contract与service
一般来说，一个Rollup的native bridge分成3个模块：L1上的bridge合约、L2上的bridge合约，以及一个bridge service负责传递信息。NCRC协议在底层复用了这些模块，并在其基础上做了更高级的封装。主要的改动如下：
L2上的bridge合约：在保留原有方法的基础上，添加了新的bridgeAsset方法，允许用户在destinationNetwork 参数中指定目标Rollup的ID
L1上的bridge合约：封装一个新方法来处理新bridgeAsset方法的跨链消息。bridge合约会在RRC合约中根据Rollup ID寻找到目标Rollup的信息，并将跨链资产转移到目标Rollup的bridge合约中。跨链资产在那里被deposit到目标Rollup
bridge service：负责传递信息，并向用户收取跨Rollup交易的手续费
当一个Rollup完成以上NCRC相关的兼容适配之后，就可以将该Rollup注册到RRC，从而加入原生跨Rollup通信网络。
原生跨Rollup交易的流程
对于用户来说，NCRC的操作方式和rollup的native bridge是完全一致的。用户在 Rollup1 上发起到 Rollup2 的跨链交易，整个流程将自动完成，包括以下步骤：
首先，跨Rollup交易发起者User1在 Rollup1 上调用native bridge的bridgeAsset方法，发起跨链交易。该交易中的 destinationNetwork 参数被设置为Rollup2的Rollup ID。这个 Rollup ID将被用于检索对应的 L1 层桥合约地址。若 Rollup ID为0，则代表目标网络为L1。
接着，这笔交易被 Rollup1的sequencer1打包。跨rollup交易的费用，由交易发起者User1承担，并支付给所在的Rollup1的sequencer1。Rollup1 的 Bridge service将跨链资产先转移到在 L1中的Rollup1桥合约。此时Rollup1和L1分别完成了资产的burn操作与release操作。
为了完成资产的跨 Rollup 转移，Rollup1 的 Bridge 服务调用RRC合约来查询参数 destinationNetwork 对应的目标 Rollup2信息，从而获取到Rollup2在 L1 层的桥合约地址。然后，Rollup2的桥合约将直接接管这些资产，并通过bridgeAsset方法将资产映射到Rollup2中。
最终，这笔交易在成功打包并生成证明后，会被Rollup2 的 Bridge 服务执行 claimAsset 操作。最终，Rollup1 发出的跨链资产安全地到达Rollup2指定的地址。
值得一提的是，在整个跨链过程中，用户的资产流经：Rollup1 -> Rollup1在L1的桥合约-> Rollup2在L1的桥合约-> Rollup2。也就是说，用户的资产没有经过任何第三方协议，而是复用了Rollup自带的native bridge，整个流程都是安全且无需信任的。
当用户在 Rollup1 上执行跨链操作，选择Rollup2作为目标，技术流程实际上涉及 Rollup1、L1 以及 Rollup2 这三者。然而，用户在此过程中并不需要感知 L1 的存在，他们的体验只是从 Rollup1 直接跨到了 Rollup2。背后的实际情况是 跨链资产在 L1 中进行了2次桥接操作，使得用户感受到的是 Rollup1到 Rollup2 的无缝连接。在这个过程中，L1 上的操作将自动处理，用户不需要有其他的操作。对用户而言，他们所在的当前 Rollup 可以实现向 L1 和任意其他 Rollup进行跨链操作。这种设计使得用户体验更加流畅，同时隐藏了底层复杂性。