Justin’s Orb
Orb has ended
0xE45e••bB35
#3

Can you provide an overview of the current state of fragmentation in the ethereum ecosystem between L2s? How can it be improved?

Tx: 0xcc85···0655|
Content Hash: 0xfa93···dc2c
Justin's Response

Can you provide an overview of the current state of fragmentation in the ethereum ecosystem between L2s?

For me an L2 is a chain that settles on Ethereum. This means that everything that characterises an L2, with the exception of the choice of settlement layer, can be idiosyncratic. This idiosyncrasy naturally leads to fragmentation: L2s can have different data availability, VM, proof system, Merkleisation, rate limiting, fee mechanism, sequencing, governance—the list goes on.

Most of the above fragmentation vectors yield beautiful experimentation and diversity that is typical to Ethereum. It's a great thing that Ethereum can permissionlessly run the EVM, the SVM, WASM, RICS-V, that we can experiment with Optimism-style public goods funding, and that hundreds of devs across dozens of L2s are incentivised to engineer zkVMs and grow platforms and communities.

If I were to pick one pain point with the current state of L2s it would be sequencer fragmentation. The reason is that sequencer fragmentation is often a lose-lose game that breaks down network effects. We don't have cross-L2 aggregators like 1inch or Matcha because of sequencer fragmentation: we have lost unified liquidity. Each sequencing zone is a silo that is only loosely connected to other sequencing zones through asynchronous message passing and asset bridging.

Sequencer fragmentation is not just about breaking down liquidity network effects. It makes bootstrapping L2s extremely expensive because L2s have to start from scratch: no apps, no liquidity, no users, no oracle integrations. A new L2 can't easily plug into existing network effects without shared sequencing.

Sequencer fragmentation also makes building complex dapps that span k sequencing zones brittle. For example, if one of the k zones is censoring (even if only censoring preconfirmations and delaying inclusion) then the whole application is censored. Liveness degrades to the weakest sequencing zone.

Last but not least, sequencer fragmentation breaks opportunities for synchronous composability which unlock significantly more fluid UX and DevX. I attribute most of Solana's current success to its synchronous execution—there's no reason Ethereum can't match Solana on synchrony!

How can it be improved?

IMO there is a compelling solution to sequencer fragmentation: shared Ethereum sequencing. The idea is that most L2s opt into using a credibly-neutral and secure shared sequencer, thereby fixing ~80% of the downsides of L2 fragmentation.

My personal thesis is that we ought to use L1 proposers as the sequencing substrate for L2s, with the shared sequencing mechanism inheriting the credible neutrality, security, and network effects of Ethereum L1. That is to say, the shared sequencer ought to be L1-driven, or "based".

Credible neutrality is particularly important to solve the coordination game. Would Arbitrum want to use Optimism's shared sequencer? Would Optimism want to use Arbitrum's shared sequencer? We need to find common neutral ground and Ethereum itself is maximally neutral.

Security is critical for liveness and censorship resistance, and based sequencing is the only way to get a sequencer which fully inherits Ethereum L1 security, without introducing a new 51% attack vector.

Finally based sequencing allows for synchronous composability between L1 and L2 execution environments, something non-based sequencers can't provide. This means that L1 TVL (~$0.5T) which hasn't (and possibly will never) migrate to L2 continue driving the network effects that make Ethereum an unstoppable force.

If you're interested in more details here are some resources:

Tx: 0x0f0f···bf27|
Content Hash: 0x117f···6e56