The ZK/OP Debate in RaaS: Why ZK-RaaS Takes the Lead


Compared to Optimistic Rollups, ZK-Rollups offer the following advantages:

  • Compressed transaction data results in lower L1 gas costs.

  • Enhanced security with no need for validators to challenge.

  • Faster transaction confirmation speed and shorter withdrawal time.

In addition to these benefits, ZK-RaaS has advantages through network effects:

  • ZK-RaaS utilizes ZK-PoW to provide scalable computational power for numerous ZK-Rollups, thereby reducing the cost of ZKP calculations.

  • Thanks to the faster transaction finality of ZK-Rollups (in the order of minutes), native Cross-Rollup Communication (NCRC) is possible among ZK-Rollups. This resolves the issue of fragmented liquidity.

What is RaaS?

Rollups-as-a-Service (RaaS) provides an abstraction layer on top of the Rollup framework and SDK, making it easy to deploy, maintain, and build on customized, production-grade specific application Rollups (AppRollups). Similar to SaaS(Software-as-a-Servic) products, RaaS allows developers to focus on building the application layer, transforming what used to be a process requiring multiple engineers and dozens of hours into a 10-minute no-code deployment.

There are two main types of Rollups: Optimistic rollups and ZK-Rollups. They differ in transaction verification and dispute resolution, with distinct advantages and disadvantages. Based on the type of Rollup offered, this article divides RaaS into Op-RaaS and ZK-RaaS.

1. Cost

ZK-Rollups have lower L1 Gas costs compared to Optimistic Rollups.

One of the primary objectives of Rollup solutions is to increase the transaction throughput on L1 and reduce users’ gas fees. Both Optimistic rollups and ZK-Rollups achieve this goal by batching transactions and periodically submitting them to the L1. Consequently, they both incur gas fees for submitting data to L1.

  • Due to the use of fraud proofs, optimistic rollups need to publish all transaction data on-chain. As a result, they require more gas to submit data batches to the main chain.

  • ZK-Rollups, on the other hand, utilize efficient data compression techniques (e.g., using indexes to represent user accounts rather than addresses, saving 28 bytes of data). This helps to lower the cost of publishing transaction data on the underlying chain.

Therefore, ZK-Rollups can save more L1 Gas compared to optimistic rollups.

ZK-RaaS reduces ZKP computation costs through massive miner participation.

However, ZK-Rollups entail additional computation costs for generating zero-knowledge proofs, which is exactly what ZK-RaaS aims to address.

As ZK-Rollups are being adopted on a large scale, generating ZKPs requires significant computational power from hardware and mining machines, including CPUs, GPUs, and FPGAs. Opside has also introduced the concept of ZK-PoW, involving miners in maintaining zkEVM nodes and performing ZKP calculations. The Opside ZK-PoW protocol is deployed across multiple chains, including but not limited to Ethereum, BNB Chain, Polygon PoS, and Opside Chain itself.

To encourage more miners to participate in ZKP computation tasks, Opside has introduced ZKP’s Two-Step Submission Algorithm. The PoW reward share corresponding to a ZKP is distributed to the submitter of valid ZKPs, which are the miners, following specific rules.

  1. Submitting Proof Hash: Within a time window, multiple miners are allowed to participate in the calculation of zero-knowledge proofs for a specific sequence. After calculating the proof, miners do not directly submit the original proof. Instead, they calculate the proofhash of (proof / address) and submit this proofhash to the contract.

  2. Submitting ZKP: After the time window, miners submit the original proof and validate it against the previously submitted proofhash. Miners whose validation is successful receive PoW rewards, with the reward amount distributed proportionally based on the miner’s staked amount.

In Opside, the Two-Step Submission Algorithm for ZKP achieves parallel computation and sequential submission of ZKPs, enabling mining machines to execute multiple ZKP generation tasks simultaneously. This significantly accelerates the efficiency of ZKP generation.

2. Transaction Finality and Fund Efficiency

  • Optimistic Rollups: There is a challenge period of up to 7 days in Optimistic Rollups. Transactions are only finalized on the main chain after the challenge period ends. Therefore, Optimistic Rollups have a high latency in terms of transaction finality.

  • ZK-Rollups: ZK-Rollups excel in low latency for transaction finality, usually taking just a few minutes or even seconds. Once the operator of the nodes verifies the validity proof, it results in a state update.

Due to the challenge period in optimistic rollups, users cannot withdraw funds before its expiration, causing inconvenience. In contrast, ZK-Rollups lack a challenge period, offering users superior fund/liquidity efficiency, allowing them to withdraw funds at any time.

3. Shared Liquidity

It’s worth noting that due to the swift confirmation of transactions in ZK-Rollups, it’s possible to achieve trustless communication between ZK-Rollups, allowing all Rollups to share asset liquidity. However, due to the presence of a 7-day challenge period and fraud proofs, achieving trustless native communication between optimistic rollups is impractical.

Opside’s ZK-RaaS platform introduces the NCRC (Native Cross Rollup Communication) protocol, providing a trustless Rollup interoperability solution. The NCRC protocol doesn’t involve adding an additional third-party bridge to each Rollup; instead, it transforms the native bridge of ZK-Rollups at the system level. This enables direct utilization of the native bridges of various ZK-Rollups for cross-Rollup communication. This approach is not only more concise and comprehensive but also inherits the absolute security of native bridges while avoiding the complexity and trust costs associated with third-party bridges.

Opside has successfully implemented NCRC on the testnet. Anyone can now experience it at

4. Security

Optimistic Rollups: Fraud proofs in optimistic rollups protect the blockchain network by relying on honest validators to ensure the validity of transactions. If there are no honest nodes to challenge invalid transactions, malicious actors could exploit this vulnerability and steal funds, rendering these optimistic rollups insecure.

ZK-Rollups: ZK-Rollups don’t rely on honest validators; instead, they use zero-knowledge proofs to verify transactions. The advantage is that ZKPs provide security assurances through mathematical proofs rather than human participants, making ZK-Rollups trustless.

While fraud proofs in optimistic rollups are theoretically viable and a handful of rollups are currently operational, the risks of this security model are exposed over time as the number of optimistic rollups increases. This risk could become a “grey rhino” or even a “black swan”. Running an honest validator incurs costs and is mostly unprofitable. When Op-RaaS creates numerous optimistic rollups, beyond a few leading rollups, ensuring honest nodes for each rollup becomes challenging, particularly for those with less attention.

On the other hand, the security of ZK-Rollups is trustless, as they don’t rely on users or validators to challenge fraudulent transactions. Instead, they provide security guarantees through mathematical proofs.


Whether it’s ZK-RaaS or Op-RaaS, developers can have their own Rollup application chains without the need to manage complex software and hardware.

ZK-RaaS platforms like Opside , representing ZK-RaaS, have introduced features such as ZK-PoW and the NCRC protocol, which further highlight the advantages of ZK-Rollups.


1 post – 1 participant

Read full topic

Opside’s NCRC: A Trustless Native Cross Rollup Communication Protocol


Opside’s NCRC (Native Cross Rollup Communication) protocol offers a trustless solution for Rollup interoperability. The NCRC protocol doesn’t involve adding an additional third-party bridge to each Rollup; instead, it transforms the native bridge of ZK-Rollup at the system level, allowing direct utilization of the native bridges of different ZK-Rollups for cross-Rollup communication. This approach is more streamlined and comprehensive, inheriting the absolute security of native bridges while avoiding the system complexity and trust costs associated with third-party bridges.
Opside has successfully implemented NCRC on the testnet. Anyone can now experience it on the official website at

Rollup Recognition Contract(RRC)

As of August 2023, several ZK-Rollups have gone live on the mainnet, including Polygon zkEVM, zkSync era, Linea, and more. However, these ZK-Rollups are independent and unrelated, leading to fragmentation of user assets. The fundamental reason for this issue lies in the fact that their contracts on L1 (Ethereum mainnet) are unrelated. They remain unaware of each other’s existence and are unable to directly communicate through native Rollup bridges.

Therefore, the first step we need to take is deploying a specialized contract on L1 to enable Rollups to discover and recognize each other. This is referred to as the RRC (Rollup Recognition Contract). The RRC is responsible for managing all participating ZK-Rollups in the NCRC, including additions, pauses, and exits of Rollups. Each Rollup within the RRC is assigned a dedicated Rollup ID, while the ID for L1 remains fixed at 0.

When initiating cross-Rollup transactions through the native bridge on a Rollup, addresses can specify the target Rollup ID:

  • If the Rollup ID is 0, it signifies crossing the message to L1, such as withdrawal.

  • If the Rollup ID is not 0, it indicates sending the message to another Rollup.

Opside will deploy an RRC contract on every L1 layer and allow corresponding ZK-Rollups to join or exit without permission. This RRC contract will be used to maintain information for each Rollup ID, including the bridge contract address on L1. It’s important to note that the RRC contract solely provides data retrieval services and does not directly interact with cross-chain assets.

Compatibility with Native Bridge Smart Contracts and Bridge Services

Generally, Rollup’s native bridge is divided into three components: the bridge contract on L1, the bridge contract on L2, and a bridge service responsible for message relay. The NCRC protocol leverages these components at the underlying level and adds higher-level encapsulation. The main modifications are as follows:

  • Bridge contract on L2: While preserving the original methods, a new method named bridgeAsset is added. This method allows users to specify the target Rollup’s ID in the destinationNetwork parameter.

  • Bridge contract on L1: A new method is encapsulated to handle the cross-chain messages of the new bridgeAsset method. The bridge contract, based on the Rollup ID found in the RRC contract, locates the information of the target Rollup and transfers 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 message relay and charges users fees for cross-Rollup transactions.

Once a Rollup completes the NCRC-related compatibility adaptation mentioned above, it can register with the RRC to join the native cross-Rollup communication network.

Process of Native Cross-Rollup Transactions

For users, the operation of NCRC is entirely consistent with that of Rollup’s native bridge. Initiating a cross-Rollup transaction from Rollup1 to Rollup2 is an automated process, including the following steps:

  1. The initiator, User1, on Rollup1, invokes the bridgeAsset method of the native bridge 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 bridge contract address. If the Rollup ID is 0, it signifies the target network as L1.

  2. Subsequently, this transaction is packaged by Sequencer1 of Rollup1. The initiator, User1, bears the cost of the cross-Rollup transaction, paying it to Sequencer1 on Rollup1. Rollup1’s Bridge service then transfers the cross-chain asset to the Rollup1 bridge contract on L1. At this point, both Rollup1 and L1 complete the burn and release operations of the asset.

  3. To complete the cross-Rollup asset transfer, Rollup1’s Bridge service queries the RRC contract to retrieve information about the target Rollup2 corresponding to the destinationNetwork parameter. This information provides the L1 bridge contract address of Rollup2. Then, the bridge contract of Rollup2 takes control of these assets and maps them to Rollup2 through the bridgeAsset method.

  4. Finally, once the transaction is successfully packaged and the proof is generated, Rollup2’s Bridge service executes the claimAsset operation. Consequently, the cross-chain assets initiated by Rollup1 safely arrive at the designated address on Rollup2.

It’s worth mentioning that throughout the cross-chain process, the user’s assets flow through the following path: Rollup1 → Rollup1’s L1 bridge contract → Rollup2’s L1 bridge contract → Rollup2. In other words, the user’s assets do not go through any third-party protocol; they leverage Rollup’s native bridge. The entire process is secure and trustless.

When users execute cross-chain operations on Rollup1, selecting Rollup2 as the destination, the technical process actually involves three entities: Rollup1, L1, and Rollup2. However, users do not need to be aware of the existence of L1 in this process; their experience is simply a direct cross from Rollup1 to Rollup2. The underlying reality is that cross-chain assets undergo two bridging operations on L1, creating a seamless connection from Rollup1 to Rollup2 in the user’s perception. During this process, operations on L1 are handled automatically, and users do not need to perform any additional actions. From the user’s perspective, their current Rollup can perform cross-chain operations to both L1 and any other Rollup. This design enhances user experience fluidity while concealing underlying complexities.

NCRC is now live on the Opside testnet!

Opside has successfully implemented native cross rollup communication on the testnet. Anyone can now experience it on the official website at We also welcome users and developers to help us identify potential bugs and security risks and provide any valuable suggestions.

We believe that trustless native cross rollup communication will not only securely share liquidity across all Rollups but also provide robust multi-Rollup interoperability, opening up new possibilities for decentralized applications and DeFi protocols.

1 post – 1 participant

Read full topic