Introduction to Native Rollup (1): Hybrid Consensus of PoS & PoW for ZK-Rollup

Hybrid Consensus of PoS & PoW

Opside is a zk-based 3-layer scaling platform, whose layer 2 is an EVM-compatible and Rollup-friendly chain, and layer 3 is a collection of different zkRollups. Layer 2, or Opside chain, has made many system-level optimizations for zkRollup and introduced the concept of the native rollup.
Layer 2 and 3 of the Opside architecture share a consensus mechanism that integrates PoS and PoW.

Layer 2

  • PoS: Opside will adopt the PoS of ETH 2.0 and make necessary improvements. As a result, Opside’s consensus layer will have over 100,000 validators. Anyone can stake IDE tokens to become a validator. In addition, Opside’s PoS is provable, and validators will periodically submit PoS proof to layer 1. Validators can earn from block rewards and gas fees in layer 2.

Layer 3

  • PoS (Sequencer): The validator proposes not only layer 2 blocks but also layer 3 blocks(i.e. data batch); that is, the validators are also the sequencers of the native rollups in layer 3. Sequencers can earn the gas fee from the transaction in layer 3 transactions.
  • PoW (Prover): Any validator can be the prover of a native rollup as long as it has enough computing power for zkp computation. Provers generate zk proofs for each native rollup in layer 3. A prover generates zk proof for each block of layer 3 submitted by sequencer according to the PoW rules. The first submission of zk proof will get the block reward of layer 3.

Decentralization Mechanism of Layer 3

The decentralized consensus mechanism of layer 3 is described in detail below.


  • The validator of layer 2 assumes the role of the sequencer. In each layer 2 block, all native rollups have one and only one transaction to submit their respective rollup block, and these rollup blocks can only be submitted by the proposer of the current layer 2 blocks. If the layer 2 block does not contain the blocks of all native rollups, the block is invalid.
  • The sequencer must commit the block of a native rollup even if there have been no transactions in that rollup for a while, at which point the block of that rollup is empty.
  • The sequencer’s revenue is the transaction fee in the block of each native rollup submitted by the sequencer. Note that the transaction fees in all native rollups are paid by the Opside token (IDE). Therefore, the more rollup transactions the sequencer packs, the more revenue it generates.
  • When the sequencer packs the rollup block on the chain, the rollup block enters the finalized state. Therefore the time required for the layer 3 blocks to be finalized is the same as for layer 2.
  • If a rollup block is not verified by the proof submitted by the prover within a specific time, the block will be skipped, and the corresponding sequencer will be slashed.


  • Unlike a sequencer, who must be the proposer of the current layer 2 blocks, a prover can be any layer 2 validators. A validator is eligible to be the prover of any native rollup as long as it has zkp computing power.
  • The first prover to provide valid proof of a rollup block will get the corresponding block reward, and the block reward of all native rollups is paid by the Opside token (IDE). This part of the IDE token is the PoW part of the Opside reward. The system will automatically adjust the PoW reward amount according to the supply and demand balance of zkp computing power.
  • The rollup block packed by the sequencer already contains all the data to generate the proof. Therefore, the prover can generate multiple blocks of proofs in parallel for each rollup. By the same token, the verification of these block proofs is also parallel.
  • When a rollup block and all its parent blocks are verified, the block is verified.


Through the hybrid consensus of PoS & PoW, Opside unifies the set of validators of layer 2 and 3, ensuring the system’s security, decentralization, and permissionlessness. Opside defines a unified system contract, and developers only need to implement these standardized interfaces and register rollup slots as native rollups. In this way, developers can focus more on implementing business logic and do not need to care about how layer 2 and layer 3 interact with each other and do not need to maintain a full node or zkp computing power of rollup.

Leave a Reply