Why Sharding Consensus Sacrifices Liveness for Scale

To scale, sharding splits the network into independent committees. This creates a fundamental vulnerability: an attacker can target a single shard with a 1/N of the total stake, halting it and compromising the chain's liveness. The Nakamoto Coefficient plummets, making censorship attacks cheaper.\n- Key Weakness: Single-shard liveness depends on a small, targetable validator subset.\n- Core Trade-Off: Throughput scales linearly with shards, but liveness security degrades.

Networks like Solana and Sui reject sharding, keeping a single global state and consensus. They achieve scale via parallel execution engines (Sealevel, BlockSTM) that process non-conflicting transactions simultaneously. Liveness is preserved because the entire validator set secures every transaction.\n- Key Benefit: Full Nakamoto Coefficient security for all state.\n- Key Benefit: ~50k-200k TPS theoretical throughput via hardware scaling, not fragmentation.

Ethereum's roadmap and Celestia's data availability layer externalize execution to sovereign rollups (e.g., Arbitrum, zkSync). The base layer provides consensus and data, not execution. Liveness of individual rollups can fail without compromising the entire system, isolating risk.\n- Key Benefit: Unbundles consensus from execution, allowing specialized scaling.\n- Key Benefit: Base layer liveness is preserved; rollup downtime is an application-layer issue.

Ethereum 2.0's Danksharding design mitigates liveness risks via crosslinks. While validators are assigned to committees, the Beacon Chain finalizes attestations from all shards frequently. A single shard stall doesn't halt finalization, and the system can re-org around it. Security is pooled, not siloed.\n- Key Benefit: Cross-shard accountability via the Beacon Chain.\n- Key Benefit: Enables ~100k TPS while maintaining robust liveness guarantees.

In a non-sharded chain, an attacker needs >33% stake to halt the network. In a sharded system with N shards, they can target a single shard with a 1/N fraction of total stake, paralyzing a portion of the chain. This is a liveness attack, not a safety failure, but it fragments network utility.

• Attack Cost: Drops from ~$10B+ to attack Ethereum to potentially <$100M to attack one shard.
• Impact: Creates cross-shard arbitrage hell and breaks atomic composability.

Atomic operations across shards require a multi-phase commit protocol (e.g., 2-Phase Commit). This introduces hard latency floors that break the synchronous execution model.

• Finality Time: Adds 2-10 block delays (~12-60 seconds) for cross-shard finality vs. single-shard.
• Complexity: State proofs, fraud proofs, or optimistic rollups between shards add engineering debt and failure points, as seen in early NEAR and Elrond designs.

To keep shards secure, validators must be randomly and frequently reassigned. This forces nodes to maintain state for multiple shards or rely on light clients, creating a trilemma.

• Bandwidth: ~1 Gbps+ required for nodes tracking all shards, centralizing infrastructure.
• State Bloat: If validators don't track all shards, they rely on fraud/validity proofs, pushing complexity to layer 2 (see zkSync, StarkNet). Ethereum's Danksharding sidesteps this by making execution a rollup problem.

The true bottleneck isn't execution, but ensuring data is published for fraud proofs. Sharding the data layer (as in Ethereum's Proto-Danksharding) is necessary but insufficient.

• Throughput Limit: Capped by the slowest node's download speed in the sampling network.
• Liveness Failure: If a shard's data is withheld, its state cannot be reconstructed, freezing assets. Solutions like Celestia externalize this problem but create a new liveness dependency.

Sharding fragments the mempool, preventing arbitrageurs from seeing the global state. This creates cross-shard MEV opportunities that are more profitable and harder to mitigate than single-chain MEV.

• Latency Arbitrage: Exploiting price differences across shards before cross-shard tx finalizes.
• Solution Shift: Forces protocols like UniswapX and CowSwap to use intent-based, off-chain solvers, moving complexity to the application layer.

Adding shards does not yield linear throughput gains due to quadratic message complexity. Each new shard must communicate with all others, creating O(N²) overhead in the worst case.

• Diminishing Returns: Throughput gains flatten after ~64-128 shards in most models.
• Architectural Pivot: This is why Monolithic L1s (Solana) and Modular stacks (Rollups on Celestia) are competing visions—they avoid intra-layer sharding consensus entirely.