ZK-RaaS network Opside launches NCRC protocol, allowing native cross-rollup communication without trust
TL; DR
Opsides NCRC (Native Cross Rollup Communication) protocol provides a trustless rollup interoperability solution. The NCRC protocol does not add an additional third-party bridge to each Rollup, but transforms the ZK-Rollups own bridge (native bridge) at the system level, thereby directly using the native bridge of each ZK-Rollup to achieve cross-Rollup communication. This approach is more concise and thorough. It not only inherits the absolute security of the native bridge, but also avoids the system complexity and trust costs brought by the third-party bridge.
NCRC has been launched on the test network, and users can experience it directlyhttps://pre-alpha-assetshub.opside.network/。
Why do we need trustless cross-rollup communication?
Rollups can significantly improve the scalability of blockchain networks, reduce transaction costs, and improve overall efficiency, and they are receiving increasing attention and use. Opside provides ZK-RaaS service for Web3 applications, and any developer can create their own Rollup through Opside Rollup Launchbase. In this era of multiple Rollups, we expect more and more Rollups to coexist, so seamless interoperability between different Layers 2 becomes crucial. Currently, Rollups are relatively isolated and lack real-time cross-chain communication and asset interoperability. This isolation leads to a fragmented landscape where assets are segregated within specific rollups, limiting their free flow and utilization across different networks.
The lack of efficient cross-rollup communication not only limits the potential of individual rollups, but also affects the overall user experience. Users face cumbersome and time-consuming processes when trying to transfer assets between Rollups or perform cross-chain transactions. This sub-optimal experience weakens Rollups appeal and to some extent hinders the widespread adoption of Layer 2 scaling solutions.
Most of the current cross-Rollup bridging solutions deploy a new set of cross-chain contracts on the Rollup chain, and then provide cross-chain assets through a multi-chain liquidity incentive mechanism. These solutions are not universal cross-chain messages, and they also bring risks of centralization and trust.
In order to unleash the full potential of the multi-Rollup era, there is an urgent need for a general cross-Rollup communication protocol without trust.
Opsides Solution: Native Cross Rollup Communication
In fact, each ZK-Rollup comes with an L1<>The L2 bridge is called Native bridge. Unlike third-party bridges that use liquidity solutions, Native bridge is the only mint-burn cross-chain mechanism. It is secured by zero-knowledge proofs and is also trustless. All assets on a Rollup come from the deposit transactions of the native bridge, and the native bridge also provides the final security endorsement.
We firmly believe in Occams razor principle, Entities are not to be multiplied beyond necessity. Third-party bridges have a cheaper and faster cross-chain experience, but they also bring more trust costs and security risks. The recent Multichain incident is a case in point. Therefore, at the beginning,Opsides inspiration for cross-rollup communication is surprisingly simple: directly use the native bridge to achieve multi-rollup interoperability instead of adding a third-party bridge.This has the current NCRC (Native Cross Rollup Communication) protocol.
Prerequisites for NCRC
The implementation of NCRC between multiple Rollups needs to meet the following two prerequisites:
These Rollups are of type ZK-Rollup
These Rollups are on the same L1
ZK-Rollups that meet the above two conditions have the same security as L1 in theory. Similarly, the security level of the native bridges between these Rollups is the same, and there is no need to trust each other. All NCRC transactions are verified by validity proof, which is also the fundamental source of NCRC’s security guarantee.
Rollup Recognition Contract（RRC）
As of August 2023, multiple ZK-Rollups mainnets have been launched, including Polygon zkEVM, zkSync Era, Linea, etc. However, these ZK-Rollups are independent and unrelated to each other, and the users assets are therefore fragmented. The root cause of this problem is that their contracts on L1 (Ethereum mainnet) are not related. They cannot feel each others existence, let alone achieve direct communication with the native Rollup bridge.
Therefore, the first step we need to do is to deploy a special contract on L1 to allow Rollup to discover and identify each other. We call it RRC (Rollup Recognition Contract). RRC is responsible for managing all ZK-Rollups participating in NCRC, including the addition, suspension, withdrawal, etc. of Rollups. Each Rollup in RRC will have an exclusive Rollup ID, and the ID of L1 is fixed to 0.
The address on the Rollup can specify the target Rollup ID when the native bridge initiates a cross-Rollup transaction:
If Rollup ID is 0, it means crossing the message to L1, such as withdrawal
If the Rollup ID is not 0, it means that the message should be spanned to other Rollup
Opside will deploy an RRC contract at each L1 layer and allow the corresponding ZK-Rollup to join or exit without permission. This RRC contract will be used to maintain the Rollup information corresponding to each Rollup ID, including the bridge contract address on L1, etc. It is worth mentioning that the RRC contract is only responsible for providing data retrieval services and will not have direct contact with cross-chain assets.
Compatible with native bridge smart contracts and services
Generally speaking, a Rollup native bridge is divided into three modules: the bridge contract on L1, the bridge contract on L2, and a bridge service responsible for transmitting information. The NCRC protocol reuses these modules at the bottom layer and makes higher-level encapsulation based on them. The main changes are as follows:
Bridge contract on L2: On the basis of retaining the original method, a new bridgeAsset method is added, allowing users to specify the ID of the target Rollup in the destinationNetwork parameter.
The bridge contract on L1: encapsulates a new method to handle cross-chain messages of the new bridgeAsset method. The bridge contract will find the information of the target Rollup based on the Rollup ID in the RRC contract, and transfer the cross-chain assets to the bridge contract of the target Rollup. There the cross-chain assets are deposited to the target Rollup
Bridge service: Responsible for transmitting information and charging users for cross-Rollup transaction fees
After a Rollup completes the above NCRC-related compatible adaptation, the Rollup can be registered with RRC to join the native cross-Rollup communication network.
Native cross-rollup transaction process
For users, the operation mode of NCRC is exactly the same as that of rollups native bridge. When a user initiates a cross-chain transaction on Rollup 1 to Rollup 2, the entire process will be completed automatically, including the following steps:
First, the cross-Rollup transaction initiator User 1 calls the bridgeAsset method of the native bridge on Rollup 1 to initiate a cross-chain transaction. The destinationNetwork parameter in this transaction is set to the Rollup ID of Rollup 2. This Rollup ID will be used to retrieve the corresponding L1 bridge contract address. If the Rollup ID is 0, it means that the target network is L1.
Then, the transaction is packaged by sequencer 1 of Rollup 1. The cost of cross-rollup transactions is borne by the transaction initiator User 1 and paid to the sequencer 1 of Rollup 1. The Bridge service of Rollup 1 first transfers cross-chain assets to the Rollup 1 bridge contract in L1. At this time, Rollup 1 and L1 have completed the burn operation and release operation of the assets respectively.
In order to complete the cross-Rollup transfer of assets, the Bridge service of Rollup 1 calls the RRC contract to query the target Rollup 2 information corresponding to the parameter destinationNetwork, thereby obtaining the bridge contract address of Rollup 2 at the L1 layer. Rollup 2s bridge contract will then take over these assets directly and map the assets into Rollup 2 through the bridgeAsset method.
Finally, after the transaction is successfully packaged and the certificate is generated, the claimAsset operation will be performed by the Bridge service of Rollup 2. Finally, the cross-chain assets issued by Rollup 1 safely arrive at the address specified by Rollup 2.
It is worth mentioning that,During the entire cross-chain process, the users assets flow through: Rollup 1 -> Rollup 1 bridge contract in L1 -> Rollup 2 bridge contract in L1 -> Rollup 2. In other words, the users assets do not go through any third-party agreement, but reuse the native bridge that comes with Rollup. The entire process is safe and trustless.
When a user performs a cross-chain operation on Rollup 1 and selects Rollup 2 as the target, the technical process actually involves Rollup 1, L1 and Rollup 2. However, users do not need to perceive the existence of L1 during this process, and their experience just crosses directly from Rollup 1 to Rollup 2. The actual situation behind the scenes is that cross-chain assets have been bridged twice in L1, so that users can feel the seamless connection from Rollup 1 to Rollup 2. During this process, operations on L1 will be automatically processed, and no other operations are required by the user. For users, the current Rollup they are in can perform cross-chain operations to L1 and any other Rollup. This design makes the user experience smoother while hiding underlying complexity.
NCRC is now online on the Opside testnet!
Opside has currently implemented native cross-Rollup communication on the test network. Now anyone can experience it on the official websitehttps://pre-alpha-assetshub.opside.network/. We also welcome users and developers to help us discover possible bugs and security risks, and welcome any valuable suggestions.
We believe that a trustless native cross-Rollup communication will not only securely share the liquidity of all Rollups, but will also provide more powerful multi-Rollup interoperability, thereby opening up new possibilities for decentralized applications and DeFi protocols.
