Section II: Blockchain Architectures
The Four Planes
Every L1 is fundamentally a bundle of four core functions. Think of a blockchain as a restaurant that needs to handle these essential operations:
Execution is the kitchen where orders (transactions) get processed and meals (state changes) get prepared. Settlement is the dining room where completed meals get delivered and customers pay their bills (finalized state). Consensus is the management system, ensuring everyone agrees on which orders came first and which tables they belong to. Data availability is the record-keeping, maintaining receipts and records so anyone can verify what happened.
The Modularity Spectrum
Now that we understand these four functions, the key question becomes: should they be bundled together or separated? Blockchain architecture exists along a spectrum from fully integrated to fully unbundled designs. At one end sit monolithic blockchains that handle all four functions (execution, consensus, settlement, and data availability) within a single unified layer. At the other end lie designs that separate each function into specialized, interoperable components. Most real-world implementations occupy various points along this spectrum, blending characteristics from both extremes based on their specific goals and constraints.
Monolithic designs prioritize tight integration. When execution, consensus, settlement, and data availability all share a single chain, most applications live inside one global atomic composability domain. Atomic composability means a single transaction can touch many contracts, and either all state changes are applied or they all revert together, like an "all or nothing" guarantee. This makes building complex DeFi systems much simpler, because everything settles within the same state machine. Bitcoin and Solana sit closer to this end of the spectrum architecturally, even though they differ dramatically in throughput and hardware requirements.
High-throughput monolithic chains demand more powerful hardware and networking infrastructure, a tradeoff we'll explore in Section V when examining vertical scaling approaches.
The unbundled approach asks: why force the same nodes to handle lightning-fast trading execution and long-term data storage? Separated architectures let different layers specialize. Execution layers handle transaction processing. Settlement layers provide economic finality and dispute resolution. Consensus layers optimize for fast, secure block production. Data availability layers efficiently store and distribute transaction data.
Ethereum's evolution exemplifies this transition. The network's rollup-centric roadmap transforms Ethereum into a base layer where L2s handle most transaction execution, while L1 specializes in consensus, settlement (verifying rollup proofs and resolving disputes), and data availability for rollup transaction data. Rollups optimize for throughput and cost; Ethereum provides security and finality.
Key Design Choices
Where a blockchain sits on this spectrum determines fundamental capabilities and constraints. The most significant tension involves composability: the ability to combine protocols atomically in a single transaction.
Monolithic chains offer local composability. Complex multi-step operations work seamlessly because all actions execute in a single atomic transaction. If any step fails, everything reverts, leaving you exactly where you started. Flash loans exemplify this power: a user can borrow millions of dollars, use those funds across multiple protocols, and repay the loan all within a single transaction that either succeeds completely or fails completely with no partial execution (Chapter VII covers flash loans in depth).
Distributed architectures require cross-layer composability, coordinating actions across multiple chains with different finality timings and trust assumptions. The same single-transaction arbitrage that’s trivial on a monolithic chain cannot be expressed as a truly atomic operation across rollups. Flash loans remain strictly local to one execution environment. Cross-rollup arbitrage instead relies on pre-funded capital (or credit lines) and accepts inventory and bridge risk while messages or assets move between domains. Atomicity across rollups generally isn’t possible without extra coordination mechanisms that synchronize execution across multiple chains, which are still maturing.
This composability difference shapes what builders can create and how they must think about application design. As we'll see in Section VI on interoperability, this remains one of blockchain's central challenges.
The modularity spectrum we've discussed doesn't just affect composability; it also determines how chains scale capacity. Beyond choosing where on this spectrum to sit, chains must decide how to distribute work across multiple parallel chains.
Scaling Through Modularity: Horizontal Approaches
While vertical scaling pushes individual chains to process more transactions (covered in Section V), horizontal scaling distributes work across multiple parallel chains.
Sharding represents the classic horizontal approach, like dividing a large database into smaller pieces that can be processed independently. It splits the network's state and transaction processing across multiple parallel shards, each handled by different validator subsets. Ethereum's original roadmap envisioned execution sharding, but this approach has largely fallen out of favor for L1s. The complexity of cross-shard communication, validator assignment, and security guarantees proved more challenging than anticipated.
Instead, Ethereum pivoted to a rollup-centric model: L2s provide the parallelism and handle most user transactions, while the L1 focuses on settlement and data availability. Through blob transactions (EIP-4844, covered in Chapter II) and planned future upgrades, Ethereum spreads rollup data across validators rather than splitting execution into separate shards. This exemplifies how separated layers can optimize independently while coordinating through well-defined interfaces.
Alternative Approaches to Specialization
Other ecosystems pursue specialization differently. Avalanche scales through a subnet architecture where independent, application-specific blockchains run in parallel, each with its own set of validators selected from a larger validator pool. Unlike systems where all chains share the same security, subnets operate independently and can customize their own rules, including which virtual machine to use, what token to charge for fees, and how governance works.
This design provides performance isolation, meaning that heavy applications on one subnet don't slow down or increase costs for applications on other subnets. These chains communicate with each other through Avalanche Warp Messaging, a system that enables secure cross-chain messaging without requiring all subnets to pool their security together. The result is a federation of customizable blockchains that can scale horizontally by adding more subnets rather than competing for space on a single shared network.
The architectural choice between integrated and unbundled designs involves trading the simpler composability of monolithic chains for the specialized optimization that separation enables, though it introduces the cross-layer coordination challenges inherent to fragmented execution environments. These architectural patterns shape everything from how validators coordinate to how developers build applications.
But architecture is just the foundation. The consensus mechanisms that enable validators to actually agree on transaction ordering and validity determine the security and performance characteristics that make those architectures viable. That's where we turn next.