Original Author: Opside Team – nanfengpo

Hybrid consensus on PoS & PoW

native rollupIt is a zk-based 3-layer expansion solution, in which layer 2 is an EVM-compatible and Rollup-friendly chain, and layer 3 is composed of multiple zkRollups natively supported by the system (called native rollup). Layer 2 has done many system-level optimizations for zkRollup. Layer 2 and layer 3 in this 3-layer architecture share a consensus mechanism that integrates PoS and PoW:

Layer 2 

PoS: layer 2 will adopt ETH 2.0's PoS and make necessary improvements to it. Therefore, the consensus layer of layer 2 will have more than 100,000 validators. Anyone can stake tokens to become a validator. These validators will also provide a data availability layer according to EIP-4844 to accommodate batches submitted by layer 3 Rollups. In addition, the PoS of layer 2 is provable, and the validator will periodically submit the PoS proof to layer 1. The validator can obtain the block reward and Gas fee of this part of PoS.

Layer 3   

PoS (Sequencer): In addition to proposing the block of layer 2, the validator also proposes the block of layer 3 (that is, the data batch), which means that the validator is also the sequencer of the native rollup in layer 3. Sequencer can obtain the transaction Gas fee.

PoW (Prover): As long as it has the computing power of zkp, any validator can become the prover of native rollup. Prover generates zk proof for each Native rollup of layer 3. For each block of layer 3 submitted by the sequencer, the prover will compete according to the rules of PoW, and the prover who submits zk proof first will get the block reward of layer 3.

About the decentralized consensus mechanism of Native rollup

The following will introduce the decentralized consensus mechanism of native rollup in layer 3 in detail.

Sequencer 

The role of sequencer is assumed by the layer 2 validator. In each layer 2 block, all native rollups have one and only one transaction to submit their respective rollup blocks, and these rollup blocks can only be submitted by the validator of the layer 2 block. If the layer 2 block does not contain all native rollup blocks, the block is invalid.

Even if a native rollup has no transactions for a period of time, the sequencer must submit the rollup's block. At this time, the block of the rollup is empty.

The income of the sequencer is the transaction fee in each native rollup block submitted by the sequencer. Note that all transaction fees in native rollup are paid by layer 2 token (IDE). Therefore, the more rollup transactions packaged by the sequencer, the more revenue it will generate.

When the sequencer packs the rollup block on the chain, the rollup block enters the finalized state. Therefore, the time required for the final confirmation of the block is the same as that of layer 2.

If a rollup block is not verified by the proof submitted by the prover within a certain period of time, the block will be skipped and the corresponding sequencer will also be slashed.

Prover

Unlike the sequencer which must be the validator of the current layer 2 block, the prover can be any validator of layer 2. As long as a validator has zkp computing power, it can be called the prover of any native rollup.

These provers compete through PoW. The first to provide a valid proof of a rollup block will be able to obtain the corresponding block reward. Note that all native rollup block rewards are paid by layer 2 token (IDE). This part of IDE is the reward of the PoW part of layer 2, and the system will automatically adjust the reward amount of PoW according to the supply and demand balance of zkp computing power.

The rollup block packaged by the sequencer already contains all the data needed to generate the proof. Therefore, for each rollup, the prover can generate proofs of multiple blocks in parallel. For the same reason, the verification of these block proofs is also parallel.

Summarize

Summarize

Through the hybrid consensus mechanism of PoS & PoW, layer 2 and layer 3 have the same consensus layer and validator set, which ensures the security and decentralization of the entire architecture. More importantly, each Native Rollup of layer 3 has a standardized decentralized solution on the underlying architecture. Layer 2 defines a unified system contract. Rollup developers only need to implement these standardized interfaces and register rollup slots as native rollups. In this way, developers can pay more attention to the realization of business logic, without having to care about how layer 2 and layer 3 interact at the underlying architecture level, and do not need to maintain rollup full nodes and zkp computing power.