Chapter 4: L1 Blockchains

Overview

Layer 1 (L1) blockchains form the foundational layer upon which all decentralized networks are built. Major L1s such as Bitcoin, Ethereum, and Solana have each been realized through distinct design philosophies and technical choices — choices that invariably carry fundamental trade-offs. Understanding L1 blockchains means understanding why these design decisions were made and how they shape the performance characteristics and properties of each network.

This chapter covers five essential concepts for designing and analyzing L1 blockchains. We begin with the Blockchain Trilemma, which captures the inherent tension between decentralization, security, and scalability. From there, we introduce the Four Planes of Blockchain framework, which decomposes the core functions shared by every blockchain. We then explore the spectrum of Monolithic vs Modular architectures, examine the consensus design tension between Liveness vs Safety, and finally investigate Sharding as a scalability solution.

These five concepts are deeply interconnected. The Trilemma provides the backdrop for every design decision; the Four Planes framework reveals precisely where those decisions are made; the Monolithic vs Modular distinction categorizes the resulting architectural outcomes. The Liveness vs Safety tension represents the central design choice within the consensus layer, while Sharding stands as one of the most prominent attempts to address the scalability challenge. Only by understanding these concepts together does the complete picture of L1 blockchains come into sharp focus.

---

Blockchain Trilemma

Definition

The Blockchain Trilemma, popularized by Ethereum co-founder Vitalik Buterin, describes a practical reality faced by every blockchain system: it is impossible to fully optimize for Decentralization, Security, and Scalability simultaneously. Strengthening any two of these properties will inevitably weaken the third — a structural tension rooted not in mere technological immaturity, but in the fundamental constraints of distributed system design.

Key Points

• Decentralization: The property by which a network is operated by a large number of independent nodes, ensuring no single entity holds control. Higher decentralization requires lower hardware barriers to node participation, which in turn places constraints on throughput.

• Security: The ability of the network to defend against threats such as 51% attacks, double-spending, and malicious node behavior. Robust security generally demands a sufficient number of validators and high economic costs to attack — requirements that can conflict directly with scalability.

• Scalability: The network's capacity to process a high volume of transactions quickly and at low cost. Techniques that boost scalability — such as increasing block size or simplifying the consensus process — tend to raise the cost of running a node, undermining decentralization.

• How Major L1s Navigate the Trilemma: Bitcoin prioritizes decentralization and security above all else, accepting limited transactions per second (TPS) as a consequence. Solana pursues extreme scalability, requiring high-performance hardware to run a node and thereby restricting validator accessibility. Ethereum has chosen a middle path, seeking balance across all three properties through its Layer 2 rollup ecosystem.

• The Trilemma as a Practical Framework, Not an Absolute Law: Advances in technology can gradually push the boundaries of the trilemma. Innovations such as the transition to Proof of Stake (PoS), sharding, and rollups all represent attempts to engineer around these constraints. Nevertheless, the fundamental tension among the three properties remains very much in play.

Related Concepts

The Blockchain Trilemma connects directly to every other concept in this chapter. The Four Planes of Blockchain framework reveals which functional layer each trilemma property is realized in — and where conflicts arise. The debate between Monolithic vs Modular architectures represents two dominant approaches to resolving the trilemma: monolithic designs seek balance within a single unified layer, while modular designs separate functions to optimize each property independently. Sharding is a direct attempt to improve scalability while preserving decentralization and security. And Liveness vs Safety examines the more granular trade-offs that exist within the security property itself.

---

Four Planes of Blockchain

Definition

The Four Planes of Blockchain is an analytical framework that decomposes the core functions every blockchain must perform into four logical layers: Execution, Settlement, Consensus, and Data Availability (DA). In traditional monolithic blockchains, all four functions are handled within a single integrated layer. In modern modular blockchain designs, each function can be separated into a specialized layer or chain dedicated to that specific role. This framework serves as a powerful tool for systematically comparing and analyzing the architectures of different blockchains.

Key Points

• Execution: The layer responsible for actually processing transactions — including smart contract execution — and updating the network state. The Ethereum Virtual Machine (EVM) is the canonical example of an execution environment. Execution is computationally intensive; in modular systems, rollups handle execution off-chain, separating it from the base layer.

• Settlement: The layer responsible for finalizing transaction outcomes as definitive and irreversible. It functions as the ultimate court of record for dispute resolution. In Ethereum's modular rollup-based architecture, the Ethereum L1 serves as the trusted settlement layer that finalizes transactions originating on L2 rollups.

• Consensus: The process by which all participating nodes in the network reach agreement on the ordering and validity of transactions. Consensus mechanisms such as Proof of Work (PoW) and Proof of Stake (PoS) operate at this layer. The design of the consensus layer directly determines the network's security guarantees and degree of decentralization.

• Data Availability (DA): The function of storing and distributing block data so that it remains accessible to all participants. Without publicly available data, no one can independently verify the state of the chain. Specialized DA layers such as Celestia have emerged to serve this function, and Ethereum's EIP-4844 (Proto-Danksharding) represents a targeted effort to reduce DA costs for rollups.

• The Spectrum of Integration vs Separation: Blockchains like Bitcoin and Solana integrate all four planes into a single layer, guaranteeing atomic composability and simplifying the overall design. By contrast, architectures such as Ethereum + rollups + Celestia separate each plane, enabling independent optimization at each layer — but at the cost of increased cross-layer interaction complexity.

Related Concepts

The Four Planes framework provides the direct theoretical foundation for the Monolithic vs Modular distinction: monolithic chains handle all four planes in a single layer, while modular chains distribute them across separate layers. Sharding primarily concerns the horizontal partitioning of the Execution and Data Availability planes. The tension between Liveness vs Safety manifests most directly in the Consensus plane. And the three properties of the Blockchain Trilemma map directly onto the design decisions of each plane — for example, the throughput capacity of the Execution plane determines scalability, while the design of the Consensus plane governs decentralization and security.

---

Monolithic vs Modular

Definition

Monolithic and Modular represent the two extremes of a spectrum in blockchain architecture design. A monolithic blockchain is an integrated design in which all four planes — Execution, Settlement, Consensus, and Data Availability — are handled within a single unified layer. Bitcoin and Solana are the canonical examples. A modular blockchain, by contrast, distributes these functions across specialized, separate layers or chains. Ethereum and its rollup ecosystem, alongside dedicated DA layers such as Celestia, exemplify the modular approach. Each paradigm reflects a fundamental trade-off between composability and optimization.

Key Points

• The Strength of Monolithic Design — Atomic Composability: Because all functions are processed within a single layer, complex transactions across multiple DeFi protocols can be executed and rolled back atomically within a single block. This is a significant advantage for implementing sophisticated financial logic safely. Solana's high-performance DeFi ecosystem actively leverages this atomic composability.

• The Limitation of Monolithic Design — Vertical Scaling Constraints: Improving performance requires upgrading the hardware of individual nodes — a process known as vertical scaling. This raises the cost of operating a node, reduces the pool of eligible validators, and ultimately undermines decentralization. Solana processes thousands of transactions per second, but running a node demands specialized, high-end hardware.

• The Strength of Modular Design — Specialization and Horizontal Scaling: Each layer can be independently optimized for its specific role. Rollups such as Optimism and Arbitrum handle execution off-chain on top of Ethereum, dramatically increasing throughput while inheriting the security and decentralization of the Ethereum L1. Additional execution layers can be added without modifying the base layer, enabling horizontal scaling.

• The Limitation of Modular Design — Fragmentation and Complexity: Moving assets and data between layers requires bridges, which introduce security vulnerabilities. Furthermore, atomic composability between smart contracts deployed on different rollups can break down, giving rise to liquidity fragmentation across the ecosystem.

• Current Trends: The industry is actively searching for the optimal point between pure monolithic and pure modular architectures. Ethereum's rollup-centric roadmap represents a strong institutional endorsement of the modular direction. At the same time, monolithic chains continue to compete by improving their own performance through techniques such as parallel execution.

Related Concepts

Monolithic vs Modular directly illustrates how the Four Planes of Blockchain framework translates into real-world system design. Through the lens of the Blockchain Trilemma, monolithic designs concentrate on maximizing two specific properties, while modular designs attempt to optimize all three by separating concerns across layers. Sharding can be seen as an intermediate approach — seeking to overcome the scalability limitations of monolithic blockchains while preserving the benefits of a unified layer. From a Liveness vs Safety perspective, modular systems introduce additional complexity because each individual layer may operate with a different liveness/safety configuration.

---

Liveness vs Safety

Definition

Liveness and Safety are foundational concepts from distributed systems theory that define a fundamental tension in the design of blockchain consensus mechanisms. Liveness is the property that guarantees a network will continue producing blocks and processing transactions under all circumstances. Even if some nodes go offline or behave maliciously, the chain continues to make progress. Safety is the property that guarantees a network will never finalize conflicting blocks. Even if block production temporarily halts, any state that has already been finalized will never be reversed. According to the FLP Impossibility Theorem, it is theoretically impossible to simultaneously guarantee both properties in an asynchronous network.

Key Points

• Liveness-First Design — Bitcoin: Bitcoin's Nakamoto Consensus prioritizes liveness above all else. The chain with the greatest accumulated proof-of-work difficulty is always recognized as valid. If a temporary fork occurs, the network does not halt — it continues forward, and over time the longest chain is adopted. This design results in probabilistic finality: full certainty that a transaction is irreversible requires waiting for multiple block confirmations.

• Safety-First Design — BFT Chains: Chains using Byzantine Fault Tolerant (BFT) consensus — such as Cosmos chains built on Tendermint — prioritize safety. Only blocks approved by more than two-thirds of validators are confirmed with instant finality. If the required supermajority cannot be reached, the network halts rather than risk producing conflicting blocks. The trade-off is reduced availability during network partition events.

• Ethereum's Balanced Approach — Inactivity Leak: Ethereum's Gasper consensus protocol seeks equilibrium between both properties. Under normal conditions, blocks are finalized using BFT-style consensus that ensures safety. However, if a network partition or large-scale validator dropout makes finalization impossible for an extended period, the Inactivity Leak mechanism activates. Offline validators have their staked ETH gradually penalized and slashed, increasing the proportional stake of active validators until a two-thirds supermajority is once again achievable — allowing the chain to resume progress.

• Connection to the CAP Theorem: The CAP Theorem from distributed systems theory describes a closely analogous trade-off. Consistency maps to Safety, and Availability maps to Liveness. In the event of a network Partition, it is impossible to simultaneously guarantee both Consistency and Availability.

• Practical Significance: The liveness/safety choice has direct implications for a blockchain's use cases. Payment systems and DeFi applications demand immediate and certain transaction finality — a safety-first concern. By contrast, when censorship resistance is the paramount objective, ensuring the chain always continues making forward progress — a liveness priority — may matter more.

Related Concepts

Liveness vs Safety addresses the central design decision within the Consensus plane of the Four Planes of Blockchain framework. Within the Blockchain Trilemma, the Security property encompasses more than just defense against external attacks — it also includes this internal balance between liveness and safety. In Monolithic vs Modular systems, modular architectures introduce additional complexity because different layers may operate with different liveness/safety priorities. In Sharding environments, an additional layer of complexity emerges from the need to coordinate liveness and safety guarantees simultaneously across multiple shards.

---

Sharding

Definition

Sharding is a horizontal scaling technique originally developed for traditional distributed databases, adapted for blockchain networks to partition the network's state and transaction processing across multiple parallel segments called shards. Rather than every node processing the entire network state, each node is responsible only for the data within its assigned shard. This dramatically reduces the burden on individual nodes while significantly increasing the overall throughput of the network — analogous to widening a single-lane road into a multi-lane highway. In theory, throughput can scale linearly as more shards are added.

Key Points

• Ethereum's Sharding Journey: Ethereum originally had an ambitious roadmap to implement 64 execution shards, in which each shard would process transactions independently while the Beacon Chain coordinated across them. However, with the rapid maturation of rollup technology, the Ethereum Foundation pivoted in the early 2020s away from execution sharding toward a rollup-centric roadmap. Under this strategy, execution scaling is delegated to rollups, while the Ethereum L1 focuses on serving as the Data Availability and Consensus layer.

• Data Availability Sharding — Danksharding: In Ethereum's revised direction, sharding is applied to data availability rather than execution. EIP-4844 (Proto-Danksharding) introduced blob data structures, enabling rollups to post data to Ethereum at significantly lower cost. When full Danksharding is implemented, Data Availability Sampling (DAS) will allow nodes to verify data availability without downloading the entire dataset — dramatically reducing bandwidth requirements while maintaining strong security guarantees.

• The Challenge of Cross-Shard Communication: One of the most significant technical challenges in sharding is handling transactions that span multiple shards. Enabling an asset on Shard A to interact with a smart contract on Shard B requires complex cross-shard messaging protocols, which directly undermine atomic composability. This difficulty was a major contributing factor to Ethereum's decision to shift responsibility for execution scaling to rollups.

• Sharding and the Blockchain Trilemma: Sharding is a direct attempt to resolve the trilemma. By distributing workload across shards, it enhances scalability without requiring every node to process all transactions, thereby preserving decentralization. However, new security challenges emerge — particularly the data withholding attack, in which a malicious block producer withholds shard data while still submitting block headers. DAS is specifically designed to address this threat.

• Sharding in Other Ecosystems: Beyond Ethereum, other ecosystems have adopted sharding-inspired approaches. Ethereum's Danksharding remains the most technically sophisticated implementation currently in development, but the broader architectural principle continues to inform blockchain design across the industry.

Related Concepts

Sharding is fundamentally an architectural strategy for resolving the Blockchain Trilemma at the intersection of the scalability, security, and decentralization properties. Within the Four Planes of Blockchain framework, sharding primarily targets the Execution and Data Availability planes through horizontal partitioning. From a Monolithic vs Modular perspective, sharding represents an intermediate approach — it preserves the unified base layer while distributing workload horizontally, rather than separating functions into entirely distinct chains. In Liveness vs Safety terms, coordinating consensus across multiple shards introduces additional complexity: ensuring both liveness and safety across all shards simultaneously requires careful protocol design, particularly in adversarial or partitioned network conditions.