Native Rollups becoming real, they will solve all the issues that current rollups have:

• Interoperability, unifying the rollup ecosystem

• Governance attacks, MultiSigs

• Default Experience of the Ethereum.

Yesterday there was a call @drakefjustin led, and there was huge alphas about Native Rollups. Let's give the summary of the sequencing call and my opinion on this topic

@drakefjustin has started by explaining why diversity is important for our Ecosystem and helps us to accelerate the rollup-centric roadmap. He has given several examples of how Ethereum should be celebrating this diversity. EVM is not the only way to scale the Ethereum L2s, some examples:

MegaETH - Performance focused validium, uses EigenDA, centralized sequencer, custom trie

Starknet → CairoVM, performance focused VM with rollups

Aztec → Noir, privacy focused VM

Eclipse → Centralized sequencer, SolanaVM, Celestia

Arbitrum → TimeBoost, Stylus WASM

FuelVM → UTXO model for performance

Then, @ben_chain came into stage and gave a simple message: Optimism is all in on making the OpStack as Based Rollup and Native Rollup. However, he pointed that the main need of Native Stack to be successful, is product focus.

On the based rollups: Optimism will help Optimism to be based and native, and also some other superchain partners.

He think that decentralizing the sequencer is not enough;

• Ethereum needs to lower the deposit times with Based Rollups bc it will allow us to solve the reorg problems

• Atomic guarantees for L1 and L2s, cross L2 coordination also.

As soon as we don’t have these features, we won't be successful:

→ subsecond txs, elegant solutions for reorgs, and clear look ahead.

→ Based rollups need to be cheap, and also it needs to be profitable. MEV

→ The Precompile for native rollups needs to cover the all functions of the State Transition Function of the L2s, not a subset of it.

NameChain @nicksdjohnson simply pointed that NameChain is interested in to became Native Rollups because: → They don’t want to control the chain, either with multisigs, nor with centralized sequencers. → They want to follow the L1s developments directly, not with a separate entity and DAO updates.

Base ( @jessepollak ) is excited for both:

→ interoperability that this approach will give this to other L2s

→ decentralization that this approach will help rollups to decentralize easily.

Also

→ ETH should scale ASAP, and we should build L2s for applications that everyone likes to use.

→ Urgent call for core devs: Scale the Blobs!

Arbitrum @sgoldfed

→ Ethereum ecosystems need is a single unified environment for all L2s and the L1.

→ Embrace the diversity: we’re innovating with L2s, we should keep this; not limit.

Arbitrum had a misunderstanding that working with this, will limit rollups with the EVM equivalence . But the fact it is not limiting. There’s a expandable version of the precompile which helps teams to be native while maintaining being innovative on the VM side as well. Justin added that there’s some ways to have customizability of the precompile, extend the riscV and go beyond EVM. Some hook systems that we might use precompile to use other proof systems.

UniChain: @haydenzadams

Uniswap wants maximum immutability, and naturality. This is why Unichain is interested to make the UniChain stack as native. But they probably wont be a based rollup because UniChain wants to solve the MEV problem in their chain, but Based Sequencing does not help with that.

Lambda Class: @fede_intern

They’re building a consensus client, they managed to be live on holeski without any issues. They also built a consensus layer, already working with Holeski testnet. They also worked with MEV commit. Now, they’re building rogue, a new L2 with no VC no team alloc.

They want to make it Based rollup because they want it to be as decentralized as Ethereum. They’re thinking about making the token mechanism based on proving, those who proves get the tokens → similar to BTC.

They’re from Argentina, an emerging market. They’re working with other emerging markets as well, the main thing that they (emerging markets governments) thinks, that centralized sequencers will be a problem in the future. They think to use Rogue to allow those governances, entities to launch based rollups; and started to build this.

Scroll:

There’s two problems for Based Rollups:

→ the design changes for based rollups creates fragmentation, mainly the how reorg happens, how bridge operates, tx types etc.

→ We need at least shared design alignment. This will help us to unify the rollups, otherwise it will be much harder.

→ Scroll is ready to support Based as soon as its fast and is a working product.

→ They’re also ready to support native rollups but they think that its still far away from us. They’re bullish because there’s some possible legal problems that security councils might face, and native rollups solve those problems.

There were also discussions for Fabric which is a new open-source initiative to develop “neutral” standards for based rollups & preconfirmations.

Front the based rollup infrastructures to make those work together, interoperable and be ready. Its a coordination initiative. As some things are getting standardized, there needs to be some coordination, here are the some examples of what is being standratized:

→ Universal registry contract for based rollups → Extension to PBS for preconfs → Commit-Boost, a sidecar for validators to serve preconfs

My Personal comments on this topic: being native is not enough for being aligned.

In the future, there will be three types of rollups:

→ Enterprise Rollups:

Those rollups will govern, sequence and own the rollup that they’re controlling. This is good for business that have web2 like experiences for their rollups: i.e. control the orderflow, execution logic, applications on their blockchains.

→ Performance Focused Rollups:

There will be “Big” rollups that takes Ethereum’s settlement layer and use altDA to serve the best performance for their users. They wont be superpowered by Ethereum’s other features like Blobs and Execution but will benefit from Ethereum’s settlement properties. They won’t be as decentralized and CR as Ethereum, but the performance advantages makes this disadvantage understandable. They’ll create more usability for the $ETH, which will scale the things you can do with ETH.

→ Aligned & Native Rollups:

There will be rollups that superpowered by Ethereum’s Execution, Data Availability and Decentralized Block Building. They differ from other rollups with:

-They’re as decentralized as Ethereum, no extra trust assumptions (e.g. governance process, MultiSigs, security councils etc)

• They share the same execution zone with Ethereum, which will allow direct state access to other Native Rollups and the Ethereum L1.

• They’re minimal, those rollups won’t need moon math ZK implementations for execution integrity.

• The ZK verification will be a lot cheaper than onchain, with the offchain proofs.

And they will actively be a part of the Ethereum’s network effects, which allow them to create economic value to the Ethereum protocol. There can be some revenue share mechanisms for aligned rollups, but if this does not happen naturally, there’s no way to keep this sustainable.

Ethereum is not the only “multi-chain” ecosystem, and is not the first one. Cosmos, Avalanche and Polkadot also follows the multi-chain path; but none of them have achieved sustainable economics to have a revenue share.

→ Polkadot: rent & use approach.

Polkadot has a rent and use approach, where there’s a bid for using Polkadot’s heteregenous execution zone and be a part of the ecosystem. Users stake their DOT and get ecosystem tokens as a reward. In the start, it was seemed like a good idea, but the reality its just making hard to boost the ecosystem.

→ Cosmos: Share % the tokens to the stakers to be aligned.

In the earlier days of Cosmos, almost every cosmos chain was making airdrops to stakers to be aligned with the broader ecosystem. The fact today, its not sustainable business and if you just cut the revenue or a percent of the token to be aligned, without serving features with this alignment; your model is not sustainable.

Ethereum:

Sharing the revenue “just to be aligned and help public goods” is not good enough to make rollups to share their revenues. In the earlier days, rollups were giving almost 90% of the revenue to the Ethereum, just to get security properties from Ethereum. This is a simple proof that if there’s something valuable, rollups are already ok with sharing the revenue.

Ethereum as a coordination & orchestration chain:

Once Native rollups will became a reality, there will be a possible Ethereum feature that Ethereum is serving the coordination for rollups. In this case, there can be a possible mechanism where rollups share their revenue (or the execution zone) with Ethereum and Ethereum gives the access to the rest of the ecosystem, which will happen naturally. I think the economics of preconfs, the MEV supply chain and native rollups can be designed with this philosophy.

Note: Those are my personal thoughts and can be wrong.

Native Rollups becoming real, they will solve all the issues that current rollups have:

• Interoperability, unifying the rollup ecosystem

• Governance attacks, MultiSigs

• Default Experience of the Ethereum.

Yesterday there was a call @drakefjustin led, and there was huge alphas about Native Rollups. Let's give the summary of the sequencing call and my opinion on this topic

@drakefjustin has started by explaining why diversity is important for our Ecosystem and helps us to accelerate the rollup-centric roadmap. He has given several examples of how Ethereum should be celebrating this diversity. EVM is not the only way to scale the Ethereum L2s, some examples:

MegaETH - Performance focused validium, uses EigenDA, centralized sequencer, custom trie

Starknet → CairoVM, performance focused VM with rollups

Aztec → Noir, privacy focused VM

Eclipse → Centralized sequencer, SolanaVM, Celestia

Arbitrum → TimeBoost, Stylus WASM

FuelVM → UTXO model for performance

Then, @ben_chain came into stage and gave a simple message: Optimism is all in on making the OpStack as Based Rollup and Native Rollup. However, he pointed that the main need of Native Stack to be successful, is product focus.

On the based rollups: Optimism will help Optimism to be based and native, and also some other superchain partners.

He think that decentralizing the sequencer is not enough;

• Ethereum needs to lower the deposit times with Based Rollups bc it will allow us to solve the reorg problems

• Atomic guarantees for L1 and L2s, cross L2 coordination also.

As soon as we don’t have these features, we won't be successful:

→ subsecond txs, elegant solutions for reorgs, and clear look ahead.

→ Based rollups need to be cheap, and also it needs to be profitable. MEV

→ The Precompile for native rollups needs to cover the all functions of the State Transition Function of the L2s, not a subset of it.

NameChain @nicksdjohnson simply pointed that NameChain is interested in to became Native Rollups because: → They don’t want to control the chain, either with multisigs, nor with centralized sequencers. → They want to follow the L1s developments directly, not with a separate entity and DAO updates.

Base ( @jessepollak ) is excited for both:

→ interoperability that this approach will give this to other L2s

→ decentralization that this approach will help rollups to decentralize easily.

Also

→ ETH should scale ASAP, and we should build L2s for applications that everyone likes to use.

→ Urgent call for core devs: Scale the Blobs!

Arbitrum @sgoldfed

→ Ethereum ecosystems need is a single unified environment for all L2s and the L1.

→ Embrace the diversity: we’re innovating with L2s, we should keep this; not limit.

Arbitrum had a misunderstanding that working with this, will limit rollups with the EVM equivalence . But the fact it is not limiting. There’s a expandable version of the precompile which helps teams to be native while maintaining being innovative on the VM side as well. Justin added that there’s some ways to have customizability of the precompile, extend the riscV and go beyond EVM. Some hook systems that we might use precompile to use other proof systems.

UniChain: @haydenzadams

Uniswap wants maximum immutability, and naturality. This is why Unichain is interested to make the UniChain stack as native. But they probably wont be a based rollup because UniChain wants to solve the MEV problem in their chain, but Based Sequencing does not help with that.

Lambda Class: @fede_intern

They’re building a consensus client, they managed to be live on holeski without any issues. They also built a consensus layer, already working with Holeski testnet. They also worked with MEV commit. Now, they’re building rogue, a new L2 with no VC no team alloc.

They want to make it Based rollup because they want it to be as decentralized as Ethereum. They’re thinking about making the token mechanism based on proving, those who proves get the tokens → similar to BTC.

They’re from Argentina, an emerging market. They’re working with other emerging markets as well, the main thing that they (emerging markets governments) thinks, that centralized sequencers will be a problem in the future. They think to use Rogue to allow those governances, entities to launch based rollups; and started to build this.

Scroll:

There’s two problems for Based Rollups:

→ the design changes for based rollups creates fragmentation, mainly the how reorg happens, how bridge operates, tx types etc.

→ We need at least shared design alignment. This will help us to unify the rollups, otherwise it will be much harder.

→ Scroll is ready to support Based as soon as its fast and is a working product.

→ They’re also ready to support native rollups but they think that its still far away from us. They’re bullish because there’s some possible legal problems that security councils might face, and native rollups solve those problems.

There were also discussions for Fabric which is a new open-source initiative to develop “neutral” standards for based rollups & preconfirmations.

Front the based rollup infrastructures to make those work together, interoperable and be ready. Its a coordination initiative. As some things are getting standardized, there needs to be some coordination, here are the some examples of what is being standratized:

→ Universal registry contract for based rollups → Extension to PBS for preconfs → Commit-Boost, a sidecar for validators to serve preconfs

My Personal comments on this topic: being native is not enough for being aligned.

In the future, there will be three types of rollups:

→ Enterprise Rollups:

Those rollups will govern, sequence and own the rollup that they’re controlling. This is good for business that have web2 like experiences for their rollups: i.e. control the orderflow, execution logic, applications on their blockchains.

→ Performance Focused Rollups:

There will be “Big” rollups that takes Ethereum’s settlement layer and use altDA to serve the best performance for their users. They wont be superpowered by Ethereum’s other features like Blobs and Execution but will benefit from Ethereum’s settlement properties. They won’t be as decentralized and CR as Ethereum, but the performance advantages makes this disadvantage understandable. They’ll create more usability for the $ETH, which will scale the things you can do with ETH.

→ Aligned & Native Rollups:

There will be rollups that superpowered by Ethereum’s Execution, Data Availability and Decentralized Block Building. They differ from other rollups with:

-They’re as decentralized as Ethereum, no extra trust assumptions (e.g. governance process, MultiSigs, security councils etc)

• They share the same execution zone with Ethereum, which will allow direct state access to other Native Rollups and the Ethereum L1.

• They’re minimal, those rollups won’t need moon math ZK implementations for execution integrity.

• The ZK verification will be a lot cheaper than onchain, with the offchain proofs.

And they will actively be a part of the Ethereum’s network effects, which allow them to create economic value to the Ethereum protocol. There can be some revenue share mechanisms for aligned rollups, but if this does not happen naturally, there’s no way to keep this sustainable.

Ethereum is not the only “multi-chain” ecosystem, and is not the first one. Cosmos, Avalanche and Polkadot also follows the multi-chain path; but none of them have achieved sustainable economics to have a revenue share.

→ Polkadot: rent & use approach.

Polkadot has a rent and use approach, where there’s a bid for using Polkadot’s heteregenous execution zone and be a part of the ecosystem. Users stake their DOT and get ecosystem tokens as a reward. In the start, it was seemed like a good idea, but the reality its just making hard to boost the ecosystem.

→ Cosmos: Share % the tokens to the stakers to be aligned.

In the earlier days of Cosmos, almost every cosmos chain was making airdrops to stakers to be aligned with the broader ecosystem. The fact today, its not sustainable business and if you just cut the revenue or a percent of the token to be aligned, without serving features with this alignment; your model is not sustainable.

Ethereum:

Sharing the revenue “just to be aligned and help public goods” is not good enough to make rollups to share their revenues. In the earlier days, rollups were giving almost 90% of the revenue to the Ethereum, just to get security properties from Ethereum. This is a simple proof that if there’s something valuable, rollups are already ok with sharing the revenue.

Ethereum as a coordination & orchestration chain:

Once Native rollups will became a reality, there will be a possible Ethereum feature that Ethereum is serving the coordination for rollups. In this case, there can be a possible mechanism where rollups share their revenue (or the execution zone) with Ethereum and Ethereum gives the access to the rest of the ecosystem, which will happen naturally. I think the economics of preconfs, the MEV supply chain and native rollups can be designed with this philosophy.

Note: Those are my personal thoughts and can be wrong.