Optimistic Rollups: Consensus - lukso-network/network-optimism-integration-test GitHub Wiki

Merged Consensus

One of the key distinguishing features of optimistic rollup is merged consensus, a consensus protocol that is verifiable on-chain (save for actual block validation, which is done implicitly through fraud proofs). But what is a decentralized consensus protocol?

Decentralized consensus protocols consist of a few distinct features:

• A fork choice rule (how to choose between two otherwise valid chains)
• A block validity function (state transition function)
• A leader selection algorithm (who is permitted to attempt to progress the chain by extending its tip with a new block)
• A Sybil resistance mechanism (Proof-of-Work, Proof-of-Stake, etc.)

Together, they give a blockchain economic security: the cost of manipulating history. (Note that I’m ignoring some things here for the sake of brevity e.g., some decentralized consensus protocols are leaderless).

With optimistic rollup, the side chain is fork-free by construction, so a non-trivial fork choice rule is not needed. Block validity is executed off-chain, and can be proven incorrect on-chain through a fraud proof. This leaves us with leader selection and Sybil resistance.

The spec proposed a “first come, first serve” scheme, with the first transaction that extends the side chain simply being accepted. Leader selection is implicit and post-facto, while Sybil resistance is provided by the main chain itself (i.e., transaction fees and blocksize/gas limits). Why does this simple choice of leader selection work? Because the Ethereum chain already provides security. The only way for a side chain block to be orphaned is if it’s invalid or builds upon an invalid block, or if the Ethereum chain is re-orged. Valid blocks therefore have the same finality and security guarantees as Ethereum itself! As such, we don’t need a complex leader selection algorithm or an expensive Sybil resistance mechanism to provide security; security is provided for free so we can parametrize the system as simply as possible.

Okay, but what if we want to know the leader beforehand? One suggestion is you can just run PoS + RANDAO on-chain to do leader selection. A separate token is not needed, and is in fact detrimental to this process.

There is no “honest majority” in optimistic rollup, nor is there a separate notion of security, so a native token is completely unnecessary and would add nothing but friction over just using ETH.