What L2s need from Based Rollups

Special thanks to: Jagrut Kosti, Alex Müller, Peter K, Odysseas, Mark Tyneway, Justin Drake, Jünger, Jesse Pollak & countless others for feedback.

Big shoutout to our editors: Ben & Evan <3

Preface

I make some assumptions about you, specifically:

1. Justin drake beamchain
2. blobs
3. You watched Martin Köppelman’s Native Rollup
4. You understand that we’re all building the same thing
5. Preconfirmations are not a drop-in replacement for a messaging protocol
6. Bonus points: You managed to get through all this

Short Summary

1. Don’t pursue credibly neutral launched Native Rollups
   1. Focus Ethereum R&D efforts on making the L1 more useable for L2s
   2. Allow L2s to do rapid innovation
2. Ethereum DA should be exclusive to L2s that are based instead of being open to anyone
   1. We should make DA extremely accessible and cheap for based rollups
   2. If this is a huge sticking point, potentially implement separate fee markets for based vs non-based rollups
3. Based rollups should not have to give up all their sequencer fees (eg: 80/20 L2/L1)
   1. L2s like Base are providing an incredible pipeline for onboarding users. They deserve to recapture some of that order flow
   2. L2s need to remain sustainable and not have to rely on grants from the EF
4. Implement penalties for failing to perform Rollup duties
   1. Lets not make the mistake we made with Altair. The sync committee should be slashed and its not implemented that way. 
   2. L1 validators should be held to the same standards that rollup operators today are held to, otherwise slash.
5. What does the upgrade path look like?
   1. L2 teams want guidance on APIs and expected hiccups
6. Implement a native verification system for messaging
   1. We need to move past MPC bridging as the verification mechanism
   2. Create a common verification mechanism for L1<>L2 (and ideally L2<>L2) communication
   3. Leverage light clients similar to IBC, or just use IBC
   4. Native messaging protocols (eg: Superchain) by L2 teams will exist and should be considered the last mile. Treat L2s like their own ecosystem, the same way we bridge into Cosmos, then last mile everything over IBC, use the most secure method once you’re inside that ecosystem.
7. Acknowledge Based Rollups do not create a UX upgrade they are just a rollup security upgrade/option
8. Stop pursuing multiple naming conventions
   1. Based rollups should have the requirement that they are both sequenced by the L1 and they use Ethereum DA

L2s need incentives

The current strategy for Based Rollups boils down to the following statement: “We are going to implement Based Sequencing, and we’re certain all L2s will use it.”

But that won't cut it—we need strong incentives and discussions with the existing L2s to see what it would take for them to join. The current R&D effort would have sufficed if we had developed a brand new protocol with L2s and their security in mind from day zero. Unfortunately, that's not the case. Ethereum exists today, as do many L2s with serious amounts of traction.

We need to take a product-first approach to the rollout of Based Rollups (and perhaps all of Eth R&D).

When it comes to security for rollups, there are literally only three possible paths forward:

1. They keep a single sequencer, and nothing changes
2. They become a based rollup and become sequenced by the L1
3. They implement multiple sequencers and outsource that to third parties

To achieve #2, which is, in my opinion, the optimal path for Ethereum and its L2s, we need to offer L2s some real incentives:

1. Sequencer fees should be fairly remunerated back to the L2
   1. The L1 shouldn’t take all the fees, maybe only 10% or a fee mechanism
   2. The L2 brought the distribution and network effects and should take the majority of what they created. We are not Apple and should not be the App Store.
   3. We want L2s to create treasuries, distribute grants, and not rely on EF funding.
2. We need strong communication channels with Eth R&D, the EF, and other important outlets.
   1. Obviously, this is unwieldy in a world with 100s of rollups, but if you’re a top ten L2 and don’t have a hotline directly to the EF, I think we’re failing them.

Ethereum Managed Native Rollups

Any effort to launch native rollups on Ethereum should be considered greenfield research, which we should avoid. The Ethereum 2.0 specification stopped working on shard chains for a few reasons, most notably its complexity and the fact that L2s started to pursue innovations faster than we could. We should encourage our L2s, talking with them frequently about how to best support their needs and encouraging them to push the barriers of what is possible. Ethereum should ossify the execution layer harder, double down on interoperability and security, and improve the landscape for L2s.

Main problems:

• Ethereum L1 starts to compete with L2s, which is counterintuitive
• L2s are the best incentivized to innovate faster than we can on the L1
• We’ll need to spend far too much additional effort educating people on where to deploy

An alternative path

This isn’t just about sequencing. I believe there are a few areas that we as a community need to examine in order to best prepare ourselves for the optimal future. I’m breaking down this proposal into two main categories: Security and Messaging.

Security

Today, we have rollups with a central sequencer that drives the chain forward and then posts its rollup data to Ethereum DA. While the future of having a Based Rollup replaces the sequencer with the L1 validator set. Finally, a native rollup enforces two conditions: the sequencer is replaced by the L1 validator set, and Ethereum DA is used.

Firstly, it is imperative to understand how Ethereum looks today and how Based is slated to look like. As you can see from the diagrams, the primary difference between today and tomorrow is that Ethereum Consensus will replace the sequencer and ultimately drive L2s forward, which allows rollups to inherit Ethereum security. There is a caveat: right now L2 security is derived from the sequencer contract on the L1 and rollup data being posted to Ethereum DA. In the Based rollup, future L2s can still post their L2 data to Ethereum DA while not being driven by the L1 itself. This seems a bit silly. If we prioritize Based rollups, why are we allowing non-based rollups to use valuable blob space? That's why Native Rollups are important.

If we are going to follow the path of Based Rollups, we should redo the naming conventions such that we do not get stuck in the situation where we have 50 iterations of Plasma. The mechanics of Native Rollups should define a Based Rollup, and we move on from the bikeshedding.

If we allow for a world of Based Rollups and Native rollups we enter murky territory of being overly modular with consensus and our DA layer. This is why I propose if we’re going to allow L1 sequencing, you must also force the rollup to use Ethereum  DA. I would say we should most likely also consider a slight re-design of the fee market within the DA layer itself.

Priority should be given to rollups that are sequenced by the L1. We should enforce a few properties:

1. The DA costs are cheaper than Native Rollups 
2. DA priorities Native Rollups first, everything else second

The economic incentives exist to make this happen, and it should be part of the protocol itself. If a rollup is giving up some share of their sequencer revenue back to the protocol, we should ensure that rollup data has priority in DA. In a world with 100s of rollups, where non-Native Rollups have larger war chests than the Native Rollups, who gets priority? The highest bidder, or the rollup that is deeply engrained into Ethereum consensus. I’d argue the latter.

The Messaging Layer

What does Ethereum have that other ecosystems don’t? There are endless MPC bridges that don’t leverage a standard verification format. Due to the complexity of validator key verification, it’s tough to prove the light client bridge today. Ethereum needs a messaging layer that is fully verifiable and can be leveraged by third parties, such as bridges, to ensure their messages are secure. 

The goal should be:

• A standard message format for talking between L1 and L2s.
  • Emphasis on cross-chain messaging and cross-chain verification (Storage proofs, light clients, etc..)
• No additional trust assumption other than the L1
  • Cost is a significant factor. ZK and proof aggregation are the main levers that drive down costs.
• We should just use IBC

We should treat the L1 as a hub, and L2s should be considered as their ecosystems that may implement a more potent verification mechanism than what we can offer at the L1. If a user wants to go to a rollup that lives as a “Layer 3” on Optimism, they would use the Ethereum message layer to Optimism, and from Optimism to Layer 3, you would use the Superchain messaging format. 

This is a very normal pattern for bridging today, such as moving USDC from Ethereum to Osmosis (on Cosmos):

• User can construct a message saying move USDC to Osmosis.
• The transaction initiates a CCTP transfer from Ethereum to Noble (USDC issuance chain on Cosmos).
• Once it lands on Noble, an IBC token transfer message is triggered and sends the funds to Osmosis

This is an ideal outcome for a native Ethereum messaging protocol because we can scope the research to exclusively find the best possible solution for just supporting the immediate L2. Anything that happens after the message lands on the L2 is irrelevant, and at least we know that the L2 received that message on the strongest possible verification method.

About ChainSafe

ChainSafe is a leading blockchain research and development firm specializing in protocol engineering, cross-chain interoperability, and web3 gaming. Alongside its contributions to major ecosystems such as Ethereum, Polkadot, and Filecoin, ChainSafe creates solutions for developers across the web3 space utilizing expertise in gaming, interoperability, and decentralized storage. As part of its mission to build innovative products for users and improved tooling for developers, ChainSafe embodies an open-source and community-oriented ethos to advance the future of the internet.

Website | Twitter | Linkedin | GitHub | Discord | YouTube