How Base can solve their short term blob problems with based L3s using altDA

Posted on:February 25, 2025 at 09:34 PM

Table of Contents

Open Table of Contents

The Blob Problem

there aren't enough blobs

I probably don’t need to convince you of this if you are reading this post, but Ethereum faces a significant blob capacity issue: the current supply of blobs is insufficient to meet growing demand.

Here is a great thread from f(gautham) from Polynomial on the capacity issue:

Jesse from Base explicitly identifies blob limitations as a key obstacle to L2 scaling:

Many people (like colludingnode from Celestia) believe that Base will not be able to beat Solana’s throughput without switching to altDA:

And here are two amazing threads from my favorite blobfluencer: Bread from MegaETH

What this should be telling you is:

  1. Ethereum doesn’t have enough blob capacity today, and will not in the future unless something changes
  2. Rollups are thinking about 1. and will need to find a solution or accelerate L1 DA scaling progress (or likely both).

I’ve also personally heard from multiple Superchain rollups that blobs are their single greatest scaling concern. I won’t name any names here, but you can find some great data about L2s and their blob usage on this Dune dashboard by Hildobby.

L3s -> fully composable network extensions

fully composable based L3 and network extensions are the same thing

Today’s L3s such as Degen use a new, discrete centralized sequencer. This centralized sequencer has no different coordination interface with the L2 they settle on than any other user or app on the L2. This means that the discrete L3 is not composable with the L2, and I’ll explain why:

To get composability (defined as the ability to interact seamlessly with another chain) you need 3 things:

Atomic block proposals is pretty easy to achieve by including a block proposal of one chain as a transaction in the block proposal of another. For example, Taiko does this on Ethereum today. Shared finality also requires that validity of at least one of the chains can be verified during block proposal (which requires realtime proving). Instant withdrawals are of course also enabled by realtime proving.

Coordinated sequencing for a discrete L3 is nonexistent almost by definition, and certainly in practice. While it may be possible to colocate an L3’s sequencer with the L2’s sequencer, the coordination is still through basic L2 transactions sent through the L2’s public mempool. Unfortunately this frequency and depth of communication is not enough for full synchronous composability.

The Spire design for based L3s introduces a dedicated sidecar colocated with the L2 sequencer that effectively extends the functionality of the L2 sequencer to include the ability to sequence L3s (which means: running full nodes, accepting L3 transactions, building L3 blocks, proposing L3 blocks). This design inherently enables coordinated sequencing. For instant withdrawals, multiple models are possible (e.g. trusting the sequencer with rate limited bridges, TEE proving a la op-enclave, or even an execution engine opcode like that for native rollups). Combined, this is enough for ✨ synchronous composability ✨ between based L3s and the contracts, tokens, liquidity, protocols, and state of the L2.

With additional changes to the derivation pipeline for the L3s (including changing the state transition) and the L3’s block proposal transaction on the L2, full composability can be achieved. Full composability is a special type of synchronous composability that supports seamless cross chain contract calls. Deploying an app in execution environment A that is fully composable with execution environment B is indistinguishable from deploying directly on execution environment B (barring lower gas fees, faster transactions, and possibly some chain constants if desired).

That’s really cool. And we can take it even further with backwards compatible based rollups. More on that another time.

Because fully composable based L3s are incredibly seamless extension of an L2, I think the term “network extensions” is appropriate. Additionally, “L3” as a term has a negative connotation and imo fails to communicate the proposed relationship between what is functionally a L3 and their L2.

sprinkle on a little altDA and call it a day

keep calm and use altDA for a little bit

L3s using the Spire L3 based stack can use any DA provider supported by the L2’s sidecar. I expect many based L3s will put their [compressed] data into L2 calldata (which downstreams into Ethereum blob space). This option is the most secure and likely easiest to implement, but does not help with blob capacity issues and may be more expensive than alternative options.

Much more interesting is the use of an altDA provider. A based L3 can offer full composability with an integrated L2 while still using altDA. Note that for instant withdrawals using alt-DA you also need the alt-DA (e.g. celestia) to settle DA attestations instantly (e.g. update blobstream). Using altDA reduces the effective usage of the native L2 DA (blobs) while introducing the security/liveness tradeoffs of the chosen altDA. In terms of cost, altDA should be dramatically cheaper than Ethereum blob space, and capacity should be plentiful.

While I believe altDA is a cool temporary solution, it is my explicitly expectation that many based L3s that use altDA will eventually migrate back to blobs for DA (through L2 calldata). As the L1 DA scaling roadmap progresses, L1 DA capacity will increase and DA will no longer be the bottleneck for scaling. At this point, the tradeoffs of altDA may no longer be worth it for many L3s.

But this type of optionality is exactly the point. I like to think of an L2 that supports based L3s as an L2 with support for smart contracts with different DA providers. Imagine customizing the usage of altDA only for social and gaming apps, but using only blobs for DeFi! Full composability enables a completely different way of thinking about the expressivity that L2s can offer their developers.

Conclusion

the gang solves blob capacity issues

The blob problem is a serious constraint on the scalability of Ethereum L2s like Base, and its only going to get worse as demand grows. Based L3s provide a compelling path forward, offering full synchronous composability with their parent L2 while using alternative DA solutions to offload blob pressure. This allows rollups to scale effectively in the short term without introducing fragmentation.

By reframing L3s as seamless network extensions rather than standalone chains, we unlock a new paradigm where execution environments can remain deeply integrated while optimizing for cost and scalability. With the Spire design for based L3s, developers can leverage altDA in a way that is backwards compatible with existing L2 infrastructure, providing optionality without sacrificing composability.

Note: At Spire, we remain focused on building based rollups on the L1. Many of the problems and solutions presented here are somewhat transferable to L2 based rollups!