Chapter 3: Technical Deep Dive into the Layered Architecture of Blockchains

This chapter takes modular blockchains as the core framework and explains the paradigm shift that decouples Execution, Settlement, Consensus, and Data Availability (DA). Using Ethereum’s gas mechanism, it dissects resource pricing and transaction processing, clarifies the low-level principles behind transaction structure (nonce, gas model, CALLDATA, signature, ChainId), and then expands layer by layer—from L0 (cross-chain interoperability and shared security; Polkadot, Cosmos), L1 (root of trust focusing on final settlement, security, and DA; an assessment of Ethereum’s scalability challenges and the EIP-4844 evolution), L2 (rollups, sidechains, state channels, explaining the algorithmic machinery and differing security assumptions of Optimistic vs. ZK rollups), to L3 (application-dedicated layers serving high-frequency DEXs, blockchain games, and compliance-specific scenarios). Finally, it summarizes a full-stack model across L0–L3: L0 interconnects, L1 provides trust, L2 carries scaling, L3 unlocks application innovation—showcasing the frontier trend of modular design balancing performance, security, and flexibility.

1. Modular Blockchains — A New Paradigm for Layered Architecture

Traditional monolithic blockchains bundle all core functions—Execution, Settlement, Consensus, and Data Availability (DA)—into a single layer. The modular paradigm advocates decoupling these functions so specialized, composable layers can shoulder them, improving system performance and flexibility.

• Execution layer: Processes and executes transactions, updating state (e.g., smart-contract calls).

• Settlement layer: Verifies transaction validity, arbitrates disputes, and confers finality on asset transfers.

• Consensus layer: Establishes global agreement on ordering and canonical history.

• Data Availability (DA) layer: Functions like a public, trustworthy “archive board.” It ensures that raw transaction data remain accessible for nodes to download and verify at any time. Data availability underpins transparency and security because it allows any independent observer to:

  1. Independently verify whether L2-posted state transitions are correct;

  2. Submit fraud proofs when malicious behavior is detected;

  3. Force-withdraw assets safely on L1 if an L2 operator goes offline or censors users, using the published data.

Understanding this modular framework is the prerequisite to grasping how different layers divide responsibilities and interoperate.

2. Ethereum Transactions and the Gas Mechanism

Before discussing layering, we must first understand how Ethereum prices resources and processes transactions—that is, the gas mechanism.

2.1 Ethereum as a “World Computer” and Pricing of Compute Resources

Ethereum is often described as a “world computer,” centered on the Ethereum Virtual Machine (EVM). Every full node runs the EVM to maintain a globally consistent state. Users submit transactions to request EVM operations—from simple transfers to complex contract calls. Since these operations consume compute, storage, and bandwidth across thousands of nodes, Ethereum must price them and prevent abuse—hence gas.

2.2 Gas: The Unit Measuring Computational Work

• Definition: Gas is not a token; it is an abstract unit that measures computational work in Ethereum. Each EVM opcode (adding numbers, storing variables, sending a transaction) has a fixed gas cost. A standard ETH transfer costs 21,000 gas.

• Purpose: By pricing computation, gas quantifies resource consumption so the network can charge appropriately for requested work.

2.3 What Makes Up the Fee: Gas Price and Gas Limit

The total transaction fee (gas fee) is: Gas Fee = Gas Used × Gas Price

• Gas Used: The actual gas consumed by execution.

• Gas Price: The price (typically in Gwei) the user is willing to pay per unit of gas. Under congestion, higher prices gain priority.

• Gas Limit: A user-specified upper bound on gas the transaction may consume—a safety mechanism to prevent runaway costs (e.g., an infinite loop due to a buggy contract). If execution exceeds the limit, the transaction reverts, but the gas spent up to that point is not refunded.

2.4 Structure of a Standard Transaction and the CALLDATA Field

A standard Ethereum transaction is a serialized data structure with these core fields:

• Nonce: A per-account, zero-based counter representing how many transactions the from address has sent. Each transaction must have a unique, increasing nonce—critical to preventing replay attacks and duplicate processing.

• Gas price / EIP-1559 fee model:

  • Pre-EIP-1559: gasPrice was the user’s per-gas bid (in wei).

  • Post-EIP-1559: Replaced by maxPriorityFeePerGas (tip to validators) and maxFeePerGas (overall cap). Effective fees comprise a dynamic baseFee (burned) plus a priorityFee (paid to validators).

• Gas Limit: Maximum gas the sender is willing to spend. Unused gas is refunded after execution.

• To: Destination address. If an externally owned account (EOA), it’s an ETH transfer; if a contract account, it triggers code execution; if null, it creates a new contract.

• Value: Amount of ETH transferred (in wei; 1 ETH = 10^18 wei). For contract calls, this may be zero.

• Data / CALLDATA: An optional field containing arbitrary bytes.

  • Definition: CALLDATA is a read-only, byte-addressable input region for contract calls.

  • Uses:

    1. Usually empty for simple ETH transfers;

    2. For contract interactions, it contains the function selector and ABI-encoded parameters;

    3. For L2 rollups (pre-EIP-4844), it served as a public “bulletin board” to publish L2 transaction data back to L1.

  • Cost: CALLDATA also costs gas—4 gas per zero byte, 16 gas per non-zero byte. Thus, the more data rollups publish, the higher the L1 gas they pay.

• V, R, S: ECDSA signature components proving authenticity and integrity; any node can verify using the sender’s public key.

• ChainId: Introduced by EIP-155 to prevent a transaction valid on one chain from being replayed on another (e.g., mainnet = 1).

3. Layered Mechanisms

3.1 Layer 0 (L0): Protocol Base / Network Layer

Definition & role. L0 sits beneath L1; it does not process app transactions directly but focuses on interoperability among heterogeneous blockchains. Its goal is to become the “internet of blockchains,” offering cross-chain communication standards and optional shared security.

Core functions

1. Cross-chain messaging protocols: Standardized mechanisms allowing L1 chains built atop L0 to transmit messages and transfer assets securely and trust-minimized.

2. Shared security (optional): Some L0s let new chains “rent” security by staking the L0’s native token, reducing the security bootstrapping cost.

Representative examples

• Polkadot: A Relay Chain provides network-wide security and consensus. Independent L1 parachains plug into it, leveraging the validator set for shared security while retaining independent application logic.

• Cosmos: Anchored by the IBC protocol (akin to TCP/IP), enabling sovereign zones to interoperate securely—forming a decentralized “internet of blockchains.”

3.2 Layer 1 (L1): Core Protocol / Settlement Layer

Definition & role. L1 is an independent base chain with its own consensus, nodes, and native token. In modular terms, L1 is the root of trust, chiefly responsible for final settlement, security, and data availability.

Core functions

1. Final settlement: Once finalized on L1, state transitions become irreversible.

2. Security: Decentralized consensus (PoW/PoS) defends against attacks, securing everything built on top.

3. Data availability: Ensures state-transition data are publicly retrievable and verifiable—foundational for safe L2 operation.

Ethereum L1 scalability challenges and its own evolution

• Bitcoin: The first successful L1; focuses on value storage and peer-to-peer payments. It uses the UTXO model and a non-Turing-complete Script, maximizing simplicity and security while deliberately limiting complex logic.

• Ethereum: Introduced a Turing-complete EVM, creating the smart-contract platform. Constrained by the scalability trilemma, Ethereum prioritizes decentralization and security at the expense of scalability. Bottlenecks include serial execution and global state consensus, limiting TPS (~15–20), raising gas fees, and inflating state.

• L1 scaling via sharding — and the EIP-4844 waypoint

  • Sharding vision: Horizontally partition the blockchain into multiple shards for parallel throughput. In full Danksharding designs, Ethereum evolves into a beacon chain plus many data shards.

  • Current pain (pre-shards): L2 rollups publish data to L1 via CALLDATA:

    1. High cost: Competes in the L1 gas market; fees spike during congestion;

    2. Permanent storage: CALLDATA is kept forever even though only temporary availability is needed.

  • EIP-4844: Introducing blobs, toward Proto-Danksharding

    • Core contribution: New “blob-carrying transactions” paving the way for future sharding.

    • Blob characteristics:

      • Temporarily stored: Required only for a short window, then can be pruned;

      • Non-executable: Opaque to the EVM, saving compute;

      • Separate fee market: Blob fees are decoupled from gas.

    • Significance: With new transaction types, KZG commitments, and a distinct fee market, EIP-4844 previews data-sharding concepts within a monolithic chain—hence Proto-Danksharding.

3.3 Layer 2 (L2): Scalability Layer

Definition & role. L2 comprises protocols built atop L1 to scale it—primarily taking on the execution role. L2 does not create a fully sovereign base chain; it anchors to L1 for security and extends performance off-chain.

Core idea and mainstream designs

• Rollups: Execute transactions off-chain while publishing data back to L1 for DA.

  • Optimistic Rollups (algorithmic flow):

    1. Sequencer batching: The L2 sequencer collects, orders, and batches user txs, computing the new state root;

    2. Data submission: The sequencer submits compressed tx data and the computed state root to L1 contracts;

    3. Presumption of correctness + challenge window: The system assumes correctness for a period (e.g., 7 days);

    4. Fraud proofs: Any verifier can locally re-execute using L1-posted data; if the locally computed root diverges, they submit a fraud proof to L1;

    5. On-chain arbitration: L1 replays the disputed slice; proven faults slash the sequencer’s bond and reward the challenger; failed challenges are penalized;

    6. Finality: If unchallenged within the window, the state root becomes final. This explains multi-day withdrawals from Optimistic rollups to L1.

  • ZK Rollups (algorithmic flow):

    1. Proof generation: The sequencer/prover batches txs, executes them, and generates a zero-knowledge validity proof (e.g., ZK-SNARK/STARK);

    2. Validity guarantee: The proof convincingly attests that the batch followed the rules, without revealing tx details;

    3. On-chain verification: The prover submits compressed data plus the proof to L1;

    4. Near-instant finality: L1 verifies the succinct proof efficiently; once accepted, the state is final—enabling fast withdrawals via cryptographic certainty rather than game-theoretic delays.

• Sidechains: Independent chains with their own consensus and security, connected via two-way pegs. They do not inherit L1 security; they trade different trust assumptions for performance/flexibility.

• State channels: Let participants transact privately off-chain many times, touching L1 only to open/close the channel and settle the final state. Bitcoin’s Lightning Network is a classic example.

3.4 Layer 3 (L3): Application Layer

Definition & role. Sometimes called app-specific chains, L3s are built atop L2s and are highly tailored for particular applications or domains.

Core functions

1. Feature customization: If L2s are general-purpose scaling, L3s tailor the environment to specific needs (e.g., orderbook-based high-frequency DEXs, large-scale games, social apps). Developers can customize tx types, fee models (e.g., subscription or maker–taker instead of gas), and even the VM.

2. Massive scaling & isolation: Offload workload from general L2s to achieve peak app performance and isolate apps from one another.

3. Privacy & compliance: Implement app-specific ZK circuits or domain compliance at L3 without burdening generalized L2s.

Composition and examples L3 settles its data to its parent L2, which then settles to L1: L3 (application) → L2 (general scaling) → L1 (final security)

• Arbitrum Orbit: Lets developers spin up customizable L3 chains atop Arbitrum (an L2).

• zkSync Hyperchains: An L3 ecosystem atop zkSync Era (an L2) sharing the same zkEVM engine for fast inter-L3 interoperability.

---

4. Summary: A Complete Technology Stack

Together, these layers form a coherent stack with specialized roles:

• Layer 3: Provides flexibility for application innovation and extreme performance.

• Layer 2: Serves as the execution layer to overcome general-purpose scalability limits.

• Layer 1: Acts as the settlement and data availability layer, supplying decentralization and final economic security.

• Layer 0: The network layer that breaks silos via interoperability (and optionally shared security).

Understanding this modular, layered model is key to grasping current blockchain trends and evaluating technical roadmaps across projects.