TL; DR
The NCRC (Native Cross Rollup Communication) protocol provided by Opside offers a trustless solution for Rollup interoperability. The NCRC protocol does not add an additional third-party bridge to each Rollup, but instead modifies the native bridge of the ZK-Rollup at the system level, enabling direct cross-Rollup communication using the native bridges of each ZK-Rollup. 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?
Rollups have gained increasing attention and usage as they significantly improve the scalability of blockchain networks, reduce transaction costs, and enhance overall efficiency. Opside provides ZK-RaaS services for Web3 applications, allowing developers to create their own Rollups through Opside Rollup Launchbase. In this era of multiple Rollups, it is crucial to have seamless interoperability between different Layer 2 solutions. Currently, Rollups operate relatively independently, lacking real-time cross-chain communication and asset interoperability. This isolation leads to a fragmented landscape 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 tedious 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.
- Evening Must-Read | How is the current situation of Ethereum given the dual expectations of futures ETF and Cancun upgrade?
- Hacker Profits over $7 Million Analysis of the Exactly Protocol Hack on the Op Chain
- List of Top Ten Winning Projects at ETHGlobal Superhack 2023
Most of the current cross-Rollup bridging solutions deploy a new set of cross-chain contracts on the Rollup chains and provide asset cross-chain through multi-chain liquidity incentivization mechanisms. These solutions are not universal message-based cross-chain and come with centralization and trust risks.
To unlock the full potential of the multi-Rollup era, there is an urgent need for a trustless and universal cross-Rollup communication protocol.
Opside’s Solution: Native Cross Rollup Communication
In fact, each ZK-Rollup comes with an L1<>L2 bridge, which we call the Native bridge. Unlike third-party bridges that use liquidity schemes, 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 through the native bridge and also receive the final security endorsement from the native bridge.
We firmly believe in the principle of Occam’s Razor, “Entities are not to be multiplied beyond necessity.” Native Cross Rollup Communication (NCRC) protocol was inspired by the idea of using a native bridge for multi-rollup interoperability instead of adding a third-party bridge. This approach offers a cheaper and faster cross-chain experience but also introduces additional trust costs and security risks, as demonstrated by the recent Multichain incident.
Prerequisites for NCRC
To achieve NCRC between multiple rollups, the following two prerequisites must be met:
-
These rollups belong to the ZK-Rollup type.
-
These rollups are on the same Layer 1 (L1).
ZK-Rollups that meet these 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 proofs, which is the fundamental source of security for NCRC.
Rollup Recognition Contract (RRC)
As of August 2023, several ZK-Rollups have launched their mainnets, including Polygon zkEVM, zkSync Era, Linea, and others. However, these ZK-Rollups are independent and unrelated, resulting in fragmented user assets. The fundamental reason for this issue is that their contracts on L1 (Ethereum mainnet) are unrelated. They are unaware of each other’s existence and cannot achieve direct communication through a native Rollup bridge.
Therefore, the first step is to deploy a special contract on L1 to enable rollups to discover and recognize each other. This is called the Rollup Recognition Contract (RRC). The RRC is responsible for managing all ZK-Rollups participating in NCRC, including adding, pausing, and exiting rollups. Each rollup in the RRC has a unique Rollup ID, while the ID of L1 is fixed at 0.
When initiating cross-rollup transactions using the native bridge on a rollup, the destination rollup’s ID can be specified:
-
If the Rollup ID is 0, it means crossing the message to L1, such as withdrawal.
-
If the Rollup ID is not 0, it means crossing the message to another rollup.
Opside will deploy an RRC contract on each L1 layer and allow corresponding ZK-Rollups to join or exit without permission. This RRC contract will be used to maintain information about each Rollup ID, including the bridge contract address on L1. It is worth noting that the RRC contract only provides data retrieval services and does not have direct contact with cross-chain assets.
Smart contracts and services compatible with the native bridge
Generally, 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 underlying level and provides higher-level encapsulation. The main modifications are as follows:
-
The bridge contract on L2: In addition to preserving the original methods, a new method called “bridgeAsset” is added, which allows users to specify the destination rollup’s ID in the “destinationNetwork” parameter.
-
The bridge contract on L1: A new method is encapsulated to handle the cross-chain messages from the new “bridgeAsset” method. The bridge contract will find the information of the target rollup in the RRC contract based on the Rollup ID and transfer the cross-chain assets to the bridge contract of the target rollup. The cross-chain assets are then deposited into the target rollup.
-
Bridge service: Responsible for message transmission and charging users fees for cross-rollup transactions.
Once a Rollup completes the compatibility adaptation related to NCRC, it can register the Rollup to RRC and join the native cross-rollup communication network.
Process of native cross-rollup transactions
For users, the operation of NCRC is exactly the same as the native bridge of Rollup. When a user initiates a cross-chain transaction from Rollup1 to Rollup2, the entire process is automatically completed, including the following steps:
First, the user User1, who initiates the cross-rollup transaction, 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 that the target network is L1.
Then, this transaction is packaged by sequencer1 of Rollup1. The cost of the cross-rollup transaction 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 bridge contract of Rollup1 in L1. At this time, both Rollup1 and L1 have completed the burn operation and release operation of the assets.
In order to complete the cross-rollup asset transfer, the Bridge service of Rollup1 calls the RRC contract to query the information of Rollup2 corresponding to the parameter destinationNetwork, so as to obtain the bridge contract address of Rollup2 in the L1 layer. Then, the bridge contract of Rollup2 directly takes over these assets and maps the assets to Rollup2 through the bridgeAsset method.
Finally, after the transaction is successfully packaged and the proof is generated, the claimAsset operation is executed by the Bridge service of Rollup2. Eventually, the cross-chain assets issued by Rollup1 will safely arrive at the specified address of Rollup2.
It is worth mentioning that in the entire cross-chain process, the user’s assets flow through: Rollup1 -> the bridge contract of Rollup1 in L1 -> the bridge contract of Rollup2 in L1 -> Rollup2. In other words, the user’s assets do not go through any third-party protocol, but reuse the native bridge of Rollup. The entire process is safe and trustless.
When a user performs a cross-chain operation on Rollup1 and selects Rollup2 as the target, the technical process actually involves the three entities: Rollup1, L1, and Rollup2. However, users do not need to be aware of the existence of L1 during this process. Their experience is simply a direct cross from Rollup1 to Rollup2. Behind the scenes, the cross-chain assets undergo two bridge operations in L1, creating a seamless connection from Rollup1 to Rollup2 for users. In this process, the operations on L1 are 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 and hides the underlying complexity.
NCRC has been launched on the Opside testnet!
Opside has now achieved native cross-Rollup communication on the testnet. Now anyone can experience it on the official website at https://pre-alpha-assetshub.opside.network/. 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 can not only securely share liquidity across all Rollups but also provide more powerful multi-Rollup interoperability, thereby opening up new possibilities for decentralized applications and DeFi protocols.
Like what you're reading? Subscribe to our top stories.
We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!
