---
id: 12
title: "Mapping Blockchain Scaling: What L1 Parallelism, L2s, Sharding, and DA Actually Solve"
slug: blockchain-scaling-map
date: 2026/08/24
summary: L1 parallelism, L2s, sharding, and data availability all get lumped together, but they solve different problems. This piece places parallel EVM on the full blockchain scaling map and draws clear boundaries between the approaches.
keywords: blockchain scaling,layer 2,sharding,data availability,parallel EVM
heroImage: /images/community-bg.png
---

Over the past few years, nearly every chain's homepage has carried the word "scaling," but the term rarely means the same thing twice. Rollup teams say they're scaling. Data-availability teams say they're scaling. Parallel-execution L1s say they're scaling too. Line these projects up and their technical approaches, security assumptions, and performance ceilings turn out to be completely different, even though they share the same fuzzy marketing vocabulary. The result is that outsiders struggle to tell whether Arbitrum and Solana are even solving the same problem, and plenty of people inside the industry still conflate "sharding" with "parallel execution."

This piece has a straightforward goal: break the scaling problem into a handful of non-overlapping layers, and be precise about where L2 rollups, Ethereum's sharding roadmap, standalone data-availability layers, and L1 parallel execution each sit, and which bottleneck each one actually addresses. Then answer a more practical question: where does parallel EVM sit on this map, and is it competing with the other approaches or complementing them?

## Scaling isn't one problem — it's four

For a chain to function, it has to do at least four things: order transactions and commit to that order immutably (consensus), publish transaction data so anyone can verify it (data availability), actually run the transaction logic and compute the resulting state (execution), and expose the final result as a trusted source of truth to the outside world (settlement). When Ethereum launched in 2015, it bundled all four into a single piece of node software — what the industry now calls a "monolithic" architecture. The upside is simplicity and a single, unified security assumption; the downside is that a bottleneck in any one layer drags down the entire chain.

Execution was the first layer to hit a wall in this bundled design: Ethereum mainnet's real-world throughput has stayed stuck in the single digits to low teens of transactions per second, and gas fees spike quickly whenever a popular application shows up. Rather than trying to fix execution in place, Ethereum's core developers pivoted around 2020 toward a "rollup-centric" roadmap — move execution off-chain, and have the base layer focus on being the referee for data availability and settlement. That decision is the starting point for understanding everything that follows.

## L2 rollups: move execution out, keep security on mainnet

A rollup's idea is to run transaction execution on a separate chain and send back to Ethereum mainnet only the transaction data and a proof of the execution result. Ethereum doesn't need to re-execute the transactions — it only needs to check that a proof is valid (ZK rollups) or give anyone a window to submit a fraud proof if something's wrong (optimistic rollups). This shifts the execution-layer compute bottleneck onto the rollup's own sequencer, while final settlement security still anchors to Ethereum's validator set.

According to public data from L2BEAT, as of April 2026 the 73 rollups the platform tracks held roughly $48 billion in total value locked. Arbitrum One leads with about $16.9 billion, over 40% of the whole L2 market; Base follows at roughly $12.8 billion; OP Mainnet sits at about $5.6 billion. The optimistic camp — Arbitrum, Base, and OP Mainnet together — accounts for roughly 80% of total L2 TVL, while the ZK rollup camp (Starknet, Linea, zkSync Era) is much smaller, each in the hundreds of millions of dollars. That distribution says something concrete: the heaviest capital in the market today still trusts the "execute first, leave a fraud-proof window" optimistic approach more than the theoretically cleaner zero-knowledge-proof approach, which still carries engineering hurdles around proof-generation cost and circuit complexity that haven't been fully cleared.

Rollups solve the horizontal-scaling problem at the execution layer, but they inherit two constraints from Ethereum mainnet: every transaction still ultimately has to publish its data on-chain (even if it's just compressed calldata or a blob), and users pick up an extra layer of trust hand-off between L2 and L1. That's exactly why a rollup is never a standalone solution — it has to depend on a data-availability layer that's cheap and secure enough to lean on.

## Ethereum's own pivot: from execution sharding to data sharding

Anyone who followed Ethereum's history will remember that "sharding" originally meant execution sharding: splitting Ethereum's state into multiple shards, each executing transactions independently, with throughput scaling — in theory — with the number of shards. That approach was designed and debated heavily between 2018 and 2020. But as rollup technology matured, Ethereum's core developers concluded that rebuilding a complex cross-shard execution protocol themselves made less sense than handing execution over to rollups entirely and focusing solely on guaranteeing data publication and verifiability — which is exactly the rollup-centric roadmap.

The concrete outcome of that pivot is Danksharding, with Proto-Danksharding — EIP-4844 — as its first step. That proposal went live in the Dencun upgrade in March 2024, introducing a new transaction type: the blob transaction. Each blob is about 128 KB, a block can carry up to six of them, and this data is only retained at the consensus layer for 18 days before being pruned, rather than permanently occupying full-node storage. According to multiple sources, after Dencun shipped, L2 data-publishing costs fell by roughly 90% compared to the earlier calldata approach, which directly drove down rollup transaction fees. The next step toward full Danksharding is Data Availability Sampling, which lets nodes confirm that the overall dataset is available by storing only a small fraction of it, scaling blob capacity up by another order of magnitude.

It's worth clearing up a common misunderstanding here: sharding, in today's Ethereum context, no longer addresses execution-layer throughput at all — it addresses capacity at the data-availability layer. Execution itself has been handed entirely to the rollup ecosystem. That also explains why Ethereum sharding and parallel-execution projects like Solana or Bitroot, despite both flying the "scaling" banner, are actually solving completely different bottlenecks.

## Standalone data-availability layers: modular design's third leg

Ethereum's own blob capacity takes time to scale up, and not every rollup wants to tie its data availability to Ethereum mainnet anyway — which gave rise to a wave of standalone data-availability projects, most notably Celestia, EigenDA, and Avail.

Celestia was the first to pull data availability out into its own independent chain, with data-availability sampling as its core innovation: light nodes can download just a small slice of the data and still confirm, with very high probability, that the full dataset is actually available. According to public sources, as of mid-2025 more than 56 rollups had integrated with Celestia, 37 of them deployed on mainnet; the Matcha upgrade in January 2026 raised block capacity to 128 MB while cutting node storage requirements by about 77%. EigenDA takes a different route, leaning on Ethereum's restaking mechanism to reuse the economic security of Ethereum's existing validator set rather than standing up a new independent chain, with a publicly stated throughput target around 15 MB per second. Avail is led by Polygon Labs, and alongside data availability itself, it's simultaneously building out a cross-chain interoperability layer (Nexus) and a security layer (Fusion).

Together, these three represent a layer of specialization within modular blockchain design: data availability is no longer a byproduct of the base chain, but an independent service that any rollup or app-chain can procure as needed. The underlying premise is that splitting execution, settlement, and data availability into independent components and optimizing each one separately beats a monolithic chain trying to carry everything itself — at the cost of more complex cross-layer trust assumptions and more components for users and developers to understand.

## L1 parallel execution: don't relocate, replace the engine

Unlike rollups, sharding, or standalone DA layers, L1 parallel execution takes a different direction entirely: instead of moving execution elsewhere, it redesigns the execution engine itself so the same base chain can process non-conflicting transactions concurrently. The logic underpinning this approach is that the EVM's performance bottleneck is fundamentally a product of single-threaded, sequential execution — and if multi-core hardware can genuinely be saturated while preserving state consistency, there's no need to outsource execution to a second layer at all.

Within this track there are several distinct technical approaches. Solana's Sealevel requires transactions to declare upfront which accounts they'll read and write, and the runtime builds a dependency graph from those declarations to schedule non-conflicting transactions across different cores in parallel. According to public data, Solana's total value locked reached roughly $8.3 billion in April 2026, making it the third-largest chain behind Ethereum mainnet and its L2 ecosystem, with an officially claimed peak throughput around 65,000 transactions per second. Sui and Aptos take a resource-oriented object-model approach instead: Sui models on-chain assets as independent objects, so transactions that share no state can execute fully in parallel or even bypass consensus altogether; Aptos's Block-STM engine uses optimistic concurrency control, detecting conflicts dynamically during execution and selectively rolling back rather than declaring dependencies in advance. Sui's TVL grew from about $380 million in January 2025 to roughly $1.8 billion in April 2026 — nearly a 4.7x increase — showing that the object-model approach has picked up clear capital and application traction over the past year.

Doing parallel execution while staying fully EVM-compatible is another path, one that stays closer to Ethereum's existing ecosystem, with Monad, Sei, and Bitroot as representative projects. Monad launched mainnet on November 24, 2025, with a publicly stated throughput target in the tens of thousands of transactions per second, using optimistic parallel execution of bytecode-compatible EVM while decoupling consensus from execution to shorten the communication rounds needed for final confirmation — its TVL climbed quickly to around $410 million after launch. Sei V2 also takes the optimistic-parallelization route and has three mainnets running; industry analysis suggests its real-world throughput under actual dApp load sits in the range of 2,500 to 3,500 transactions per second, some distance from the officially advertised figures — a useful reminder that evaluating any parallel EVM project means distinguishing lab benchmarks from sustained throughput under real load. Bitroot belongs to this same track: an optimistic parallel EVM Layer 1 that raises single-chain throughput while preserving full EVM compatibility through dynamic transaction grouping, multi-engine parallel execution, and multi-stage conflict detection, layering state sharding on top as a further path to horizontal scaling — a technical approach this series will unpack layer by layer in later pieces.

## One table, everyone's lane

| Approach | Representative projects | Layer addressed | Core mechanism | Source of security assumption |
|------|----------|----------|----------|--------------|
| L2 rollups | Arbitrum, Base, Optimism, zkSync, Starknet | Execution | Off-chain execution + on-chain verification/fraud proofs | Ethereum mainnet |
| Ethereum sharding (Danksharding) | Ethereum mainnet | Data availability | Blob transactions + data availability sampling | Ethereum's own validator set |
| Standalone DA layers | Celestia, EigenDA, Avail | Data availability | Independent consensus / restaking reuse of Ethereum security | Their own validators or restaking sets |
| L1 parallel execution | Solana, Sui, Aptos, Monad, Sei, Bitroot | Execution | Dependency analysis or optimistic concurrency, saturating multi-core hardware | Own validator set |

## Complementary, not mutually exclusive

Laying this table out flat reveals that the four approaches actually sit on two separate axes. One axis is "where execution happens": rollups move it off-chain, L1 parallelism optimizes it in place. The other axis is "who provides data availability": it can be Ethereum mainnet itself, or an independent DA layer. That means real-world combinations are far more varied than a simple either/or choice: a rollup can perfectly well keep execution on its own sequencer while outsourcing data availability to Celestia instead of Ethereum mainnet; a parallel-execution L1 like Bitroot isn't precluded from routing part of its own data-availability needs to a standalone DA layer down the road, or conversely, from becoming a settlement destination for capital and assets flowing out of the rollup ecosystem.

So it's not quite accurate to think of parallel EVM as simply "Solana's competitor" or "a substitute for Ethereum sharding." What it's actually competing against is the bottleneck within one specific stage — execution. As transaction volume rises and contract logic grows more complex, a single-threaded execution model can't keep up, and while rollups can scale out the number of execution instances horizontally, they don't solve the efficiency problem within any single execution instance. What parallel EVM is trying to do is make that one thing — execution inside a single chain, a single instance — faster.

Once this map is clear, later technical pieces in this series become easier to parse: which numbers can be directly compared, and which ones actually describe entirely different system components. Putting Bitroot's single-chain throughput side by side with a rollup's throughput in the same table, for instance, first requires being explicit about whether each side's data-availability costs are counted — details this series will unpack one at a time.

## Further Reading

- Previous: ["The Single-Threaded EVM's Performance Ceiling: From Gas Congestion to Confirmation Delay"](/en/blog/evm-single-thread-bottleneck)
- Next: ["Three Paths to Parallel Execution: Deterministic, Optimistic, and Object-Based Models"](/en/blog/parallel-execution-approaches)