Partnered With:

Opside has launched the NCRC protocol, which enables trustless native cross-rollup communication.

Read this article in 15 Minutes

This solution inherits the absolute security of native bridge while avoiding the system complexity and trust cost brought by third-party bridges.

The content you provided is:

Source: Opside

TL; DR

Opside's NCRC (Native Cross Rollup Communication) protocol provides a trustless Rollup interoperability solution. The NCRC protocol does not add a third-party bridge to each Rollup, but instead transforms the ZK-Rollup's native bridge at the system level to directly achieve cross-Rollup communication using each ZK-Rollup's native bridge. This approach is more concise and thorough, inheriting the absolute security of the native bridge while avoiding the system complexity and trust costs brought by third-party bridges.

Why do we need trustless cross-rollup communication?

Rollup can significantly improve the scalability of blockchain networks, reduce transaction costs, and improve overall efficiency. They are receiving more and more attention and usage. Opside provides ZK-RaaS services for Web3 applications, and any developer can create their own Rollup through Opside Rollup Launchbase. In this era of multiple Rollups, seamless interoperability between different Layer 2s becomes crucial. Currently, Rollups operate relatively independently of each other, lacking real-time cross-chain communication and asset interoperability. This isolation has led to a fragmented pattern, where assets are isolated 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 each Rollup, but also affects the overall user experience. Users face cumbersome and time-consuming processes when trying to transfer assets or execute cross-chain transactions between Rollups. This suboptimal experience weakens the appeal of Rollups and to some extent hinders the widespread adoption of layer 2 scaling solutions.

Currently, most of the cross-Rollup bridging solutions involve deploying a new set of cross-chain contracts on the Rollup chain, and then providing cross-chain asset transfer through a multi-chain liquidity incentive mechanism. These solutions are not universal message cross-chain solutions and come with centralization and trust risks.

In order to unleash the full potential of the multi-Rollup era, there is an urgent need for a universal cross-Rollup communication protocol that does not require trust.

Opside's Solution: Native Cross Rollup Communication

In fact, every ZK-Rollup comes with an L1<>L2 bridge, which we call the Native bridge. Unlike third-party bridges that use liquidity solutions, the 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 deposit transactions on the native bridge and are also endorsed for security by the native bridge.

We firmly believe in the principle of Occam's Razor, "Entities are not to be multiplied beyond necessity." Third-party bridges offer cheaper and faster cross-chain experiences, but they also bring more trust costs and security risks. The recent Multichain incident is a case in point. Therefore, from the beginning, Opside's inspiration for cross-rollup communication was simple: use a native bridge to achieve multi-rollup interoperability, rather than adding a third-party bridge. This is the basis for the NCRC (Native Cross Rollup Communication) protocol.

NCRC prerequisites

Two prerequisites must be met to achieve NCRC between multiple Rollups:

· These Rollups belong to the ZK-Rollup type.

· These Rollups are on the same L1

ZK-Rollups that meet the above two conditions theoretically have the same level of security as L1. Similarly, the security level of the native bridge 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 the fundamental source of security guarantee for NCRC.

Rollup Recognition Contract（RRC）

As of August 2023, multiple ZK-Rollups mainnets have been launched, including Polygon zkEVM, zkSync Era, and Linea. However, these ZK-Rollups are independent and unrelated to each other, resulting in fragmented user assets. The root cause of this problem is that their contracts on L1 (Ethereum mainnet) are unrelated. They cannot sense each other's existence and cannot achieve direct communication through native Rollup bridge.

Therefore, the first step we need to take is to deploy a special contract on L1, called the Rollup Recognition Contract (RRC), to enable Rollups to discover and identify each other. RRC is responsible for managing all ZK-Rollups participating in NCRC, including adding, pausing, and exiting Rollups. Each Rollup in RRC has a unique Rollup ID, while the ID on L1 is fixed at 0.

When initiating cross-Rollup transactions on native bridges on Rollup, the address on Rollup can specify the target Rollup ID:

· If the Rollup ID is 0, it means that the message is bridged to L1, for example, withdrawal.

· If the Rollup ID is not 0, it means that the message needs to be crossed to other Rollups.

Opside will deploy an RRC contract on each L1 layer and allow the corresponding ZK-Rollup to join or exit without permission. This RRC contract will be used to maintain Rollup information for each Rollup ID, including the bridge contract address on L1. It is worth mentioning that the RRC contract only provides data retrieval services and does not have direct contact with cross-chain assets.

Compatible native bridge smart contracts and services

Generally speaking, a Rollup's native bridge is divided into three modules: the bridge contract on L1, the bridge contract on L2, and a bridge service responsible for message transmission. The NCRC protocol reuses these modules at the bottom layer and makes more advanced encapsulation based on them. The main changes are as follows:

· Bridge contract on L2: On the basis of retaining the original methods, a new bridgeAsset method has been added, allowing users to specify the ID of the target Rollup in the destinationNetwork parameter.

· Bridge contract on L1: Encapsulate a new method to handle cross-chain messages for the new bridgeAsset method. The bridge contract will find information about 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. The cross-chain assets are deposited into the target Rollup there.

· Bridge service: responsible for transmitting information and charging users for cross-Rollup transaction fees.

When a Rollup completes the compatibility adaptation related to NCRC, it can be registered to RRC and join the native cross-Rollup communication network.

原生跨 Rollup 交易的流程

The process of native cross-Rollup transactions.

For users, the operation of NCRC is completely consistent with the native bridge of Rollup. When users initiate cross-chain transactions from Rollup1 to Rollup2, the entire process will be automatically completed, including the following steps:

First, the initiator of the cross-Rollup transaction, User1, calls the bridgeAsset method of the native bridge on Rollup1 to initiate the cross-chain transaction. The destinationNetwork parameter in this transaction is set to the Rollup ID of Rollup2. This Rollup ID will be used to retrieve the corresponding L1 layer bridge contract address. If the Rollup ID is 0, it represents the target network is L1.

Next, this transaction was packaged by sequencer1 of Rollup1. The cost of cross-rollup transactions is borne by the transaction initiator User1 and paid to sequencer1 of Rollup1. The Bridge service of Rollup1 transfers the cross-chain assets to the Rollup1 bridge contract in L1. At this point, Rollup1 and L1 have completed the burn and release operations of the assets respectively.

In order to complete the cross-Rollup transfer of assets, the Bridge service of Rollup1 calls the RRC contract to query the information of the target Rollup2 corresponding to the parameter destinationNetwork, so as to obtain the address of the bridge contract of Rollup2 at the L1 layer. Then, the bridge contract of Rollup2 will directly take over these assets and map them to Rollup2 through the bridgeAsset method.

Finally, after being successfully packaged and verified, this transaction will be executed with the claimAsset operation by Rollup2's Bridge service. Ultimately, the cross-chain assets issued by Rollup1 will securely arrive at the designated address of Rollup2.

It is worth mentioning that, throughout the entire cross-chain process, the user's assets flow through: Rollup1 -> Bridge contract on L1 of Rollup1 -> Bridge contract on L1 of Rollup2 -> Rollup2. In other words, the user's assets did not go through any third-party protocols, but instead reused the native bridge provided by Rollup. The entire process is secure and trustless.

When a user performs a cross-chain operation on Rollup1 and selects Rollup2 as the target, the technical process actually involves Rollup1, L1, and Rollup2. However, users do not need to be aware of the existence of L1 during this process, and their experience is simply a seamless connection from Rollup1 to Rollup2. The actual situation behind the scenes is that the cross-chain assets undergo two bridging operations on L1, making the user feel that there is a seamless connection between Rollup1 and Rollup2. During this process, the operations on L1 will be automatically handled, and users do not need to perform any other operations. For users, their current Rollup can perform cross-chain operations to L1 and any other Rollup. This design makes the user experience smoother while hiding the underlying complexity.

NCRC has been launched on the Opside testnet

Opside has now achieved native cross-Rollup communication on the testnet. Anyone can experience it on the official website. We also welcome users and developers to help us discover any potential bugs and security risks, as well as provide any valuable suggestions.

We believe that a trustless native cross-Rollup communication not only enables secure sharing of liquidity across all Rollups, but also provides more powerful multi-Rollup interoperability, opening up new possibilities for decentralized applications and DeFi protocols.