In the last two blogs, we looked at the pieces that make a blockchain work and how the network agrees on what is true.
In here, we will look at how all those pieces sit together as layers, how blockchains are structured, and how Layer 1 and Layer 2 actually differ in practice. Once we know what each layer is responsible for, concepts like rollups, sequencers, proofs and scaling start making sense.
Let’s get started, shall we?
Why a Layered Architecture?
Trying to understand the complexity of Blockchain all at once can feel impossible and daunting, so the easiest way to make sense of them is to break the system into layers.
Before going deeper, I want to make one thing clear. The layers we talk about in this section are architectural layers inside a blockchain: the network layer, the data layer, the consensus layer, the execution layer and the application layer.
These are not the same as Layer 1 and Layer 2, which you will see everywhere in the blockchain world. L1 and L2 are about scaling and refer to where computation or settlement happens. Architectural layers are about how a blockchain is internally organised.
In short:
- Network, data, consensus, execution and application are internal layers of one blockchain.
- Layer 1 and Layer 2 are positions in the overall ecosystem, based on how a chain scales and where it gets its security.
and we will be covering both in upcoming sections.
Let’s start with the architectural layers!
Layer-by-Layer Breakdown
TL;DR
| Layer | What It Does | What It Contains | Why It Matters | Examples / Notes |
|---|---|---|---|---|
| Data Layer (Ledger) | Stores all permanent information on the chain | Blocks, transactions, hashes, global state | Ensures immutability and historical integrity | Uses Merkle trees and hashing to prevent tampering |
| Network Layer (Communication) | Connects nodes and moves data across the system | P2P messaging, gossip protocol, peer discovery | Ensures transactions and blocks reach the network | Slow propagation can lead to temporary chain splits |
| Consensus Layer (Agreement Engine) | Makes the network agree on the canonical chain | Validator logic, fork choice rules, block proposal rules | Prevents double spending and conflicting histories | Explained in detail in the Consensus blog |
| Execution Layer (Computation) | Runs transactions and smart contracts | EVM, WASM, Solana runtime, state transitions, gas | Updates balances and contract storage | More details in the Blockchain Components blog |
| Application Layer (User-Facing) | Where users interact with the chain | Wallets, dApps, explorers, frontends | Makes blockchain usable for normal users | Most phishing and UI based attacks happen here |
A blockchain works because these layers operate together.
The data layer stores the truth, the network layer spreads it, the consensus layer agrees on it, the execution layer updates it and the application layer helps users interact with it.
Detailed
Data Layer (Ledger)
The data layer is the foundation. It stores the actual information that makes a blockchain useful. This includes blocks, transactions, hashes and the global state of the chain. When we talk about state, we are referring to things like account balances and smart contract storage.
The data layer is designed to be permanent. Once something is added to the chain and finalized, it becomes part of the history. The system uses Merkle trees and hashing to ensure that no one can quietly change a block or rewrite past transactions.
This layer does not think or validate anything. It simply holds the truth.
Network Layer (Communication)
Blockchains run on a large collection of nodes, and they need a way to find each other and share information. The network layer handles this. Nodes use a gossip protocol, which is exactly what it sounds like. One node tells a few others about a new transaction or a new block, and those nodes spread the information further. This continues until the whole network knows about it.
If the network layer is slow or unhealthy, blocks take longer to propagate and the chain can temporarily split. This is why good networking is crucial for the stability of any blockchain.
Consensus Layer (Agreement Engine)
Once transactions and blocks move through the network, the system needs a way to agree on which chain is valid. That is the job of the consensus layer.
This layer decides things like who gets to propose the next block, how validators behave and how the system resolves conflicts. The exact rules depend on the blockchain. Bitcoin uses proof of work. Ethereum uses proof of stake. Solana uses a combination of proof of history and proof of stake.
I’ve already covered the mechanics of consensus in detail in the previous blog post, so here we’ll focus only on its place in the architecture. The consensus layer sits above networking and below execution, it acts like a referee, ensuring everyone follows the same rules and that the whole network ends up on the same chain.
Execution Layer (Computation)
The execution layer is where smart contracts and transactions actually run. This is the part of the system that takes a signed transaction, checks what it wants to do and updates the state.
Different blockchains use different execution environments - Ethereum uses the EVM. Polkadot and Cosmos use WASM. Solana has its own runtime designed for high performance.
Here you will also see concepts like gas and transaction fees. Gas is a simple way to measure how much work a transaction is asking the network to do. More work means more gas, which means a higher fee. (For a detailed breakdown of these core components and how they fit together, check out the Blockchain Components blog).
If the execution layer fails or behaves incorrectly, the entire chain can break, even if all other layers work fine.
Application Layer (User-Facing)
This is the layer most people see. Wallets, dApps, explorers, interfaces and every user-facing tool belongs here.
The application layer does not run consensus or validate blocks. It simply helps users create transactions, read the blockchain and interact with smart contracts. For example, when a wallet asks you to sign a message, it is interacting with the execution layer on your behalf.
Most scams and phishing attacks happen here because this is where humans make decisions. The deeper layers do not care if you sign something malicious. They only check rules, not intentions.
Now, that we understand the architectural layers, let’s dive into the scaling layers (L1/L2). If you also had the question about L3 , if they exist, then answer is yes, but hardly talked about, but good to know.
Layer 1 vs Layer 2 - The Scaling Model
Blockchains eventually hit limits. As more people join and more transactions are created, the base chain starts to slow down and fees rise. This is not a design failure. It is simply the cost of keeping a global network secure and decentralized.
This is where Layer 2 comes in. L2s exist to increase throughput and reduce fees without creating a new trust model. The idea is simple. Keep the security of the base chain while moving most of the computation off of it.
Layer 1 (L1): The Base Settlement Layer
L1 is the foundation of the ecosystem. It provides security and final settlement. Examples include Ethereum, Bitcoin and Solana.
On L1:
- Validators secure the chain
- Blocks are finalized
- History is preserved
- The chain acts as the source of truth
L1 is the place that decides what is valid and what becomes permanent.
Layer 2 (L2): The Scaling Layer
L2 systems sit above an L1 and handle most of the heavy lifting. They execute transactions faster and cheaper, then submit a proof back to the base chain.
L2s rely on the L1 for security, so they do not need their own validator set. Instead, they focus on speed, batching and cheaper execution. But that does not mean L2 is free from security issues. It simply faces a different set of problems, and we will talk about those later.
The moment the L2 posts a proof to the L1, the L1 verifies it and updates the canonical state. So basically,
L1 secures, L2 scales.
Now the obvious question becomes: how do L2s actually scale?
The answer today is rollups.
Rollups
Rollups are the most successful design for L2s today. They run transactions off-chain and then submit compressed data back to the L1.
There are two types of rollups -
- Optimistic Rollups - They assume transactions are valid by default. If someone detects fraud, they can challenge it using a fault proof. E.g. - Optimism and Arbitrum.
- ZK Rollups - They generate a validity proof for every batch of transactions. The L1 only has to verify the proof, not re-run the transactions E.g. - StarkNet and zkSync.
Rollups give you lower fees, higher throughput and the same security as the underlying L1.
Consensus in Layer 1 vs Layer 2
Consensus in Layer 1
Layer 1 is where full consensus happens and where the base layer gets its security. At this layer, the blockchain makes final decisions about which blocks are accepted and which transactions become part of the permanent history. If you want a deep dive into how consensus works in detail, check out the Consensus blog, which covers block production, fork choice and finality thoroughly.
In the context of the architecture, L1 consensus is responsible for:
- Full chain security: This is where the network’s economic security is rooted. The rules that protect against double spending and conflicting histories live here.
- The validator or staking set: Validators or miners participate directly on the base layer. They propose and validate blocks, and their behaviour determines finality and fork choice.
- Fork choice and block validity: This layer decides which branch is the canonical chain based on the fork choice rules defined by the protocol.
- Finality: Finality is the point at which the chain agrees that a block cannot be reversed without a huge economic cost.
- Security budget from token issuance: The native token at L1 is what funds rewards and penalties for validators, and this economic weight is what makes L1 secure.
Different blockchains use different consensus mechanisms at L1. For example, Bitcoin uses proof of work, Ethereum now uses proof of stake, and some systems like Solana use specialized combinations such as proof of history with proof of stake.
Consensus in Layer 2
Layer 2 does not run full consensus the way Layer 1 does. The goal of an L2 is to scale the system without creating a new trust model, so it avoids building a full validator or miner set of its own. Instead, an L2 focuses on ordering transactions, executing them cheaply and then sending the results back to the base chain.
Most L2s use a sequencer. A sequencer is a special node or service that orders transactions and creates batches. Think of it as the traffic controller. It decides the order in which transactions appear, which helps keep the L2 fast and responsive.
The important part is that the L2 does not secure itself. It inherits security from the L1 by sending proofs back to the base chain. These proofs allow the L1 to verify that the L2 is behaving correctly.
There are two main proof models:
- Fault proofs for Optimistic Rollups - The L2 assumes everything is valid unless someone proves otherwise. If a mistake or attack happens, the fault proof gives the L1 a way to challenge and fix it.
- Validity proofs for ZK Rollups - The L2 generates a mathematical proof that shows the entire batch of transactions is correct. The L1 verifies the proof without re-running the transactions.
L2 consensus is about ordering and proving, not securing the chain.
Why This Distinction Matters?
Understanding the difference between consensus on L1 and consensus on L2 is important because it changes how we think about security and trust. An L2 is not an independent blockchain. It does not protect itself. Instead, it depends on the base layer for security and finality.
Different Trust Models
- On L1, you trust the validator or miner set to behave honestly because they secure the chain.
- On L2, you trust the proofs that the L2 sends back to the L1. The L1 checks those proofs and enforces the rules.
This shift from trusting validators to trusting proofs changes where trust actually sits in the system.
Different Attack Surfaces
Because the trust model is different, the attack surface changes too. L2 issues look nothing like L1 issues.
- Typical L2 risks include:
- Sequencer censorship
- Delayed or missing proofs
- Incorrect state roots
- Faulty batching or ordering
- Typical L1 risks include:
- Majority control of validators
- Fork manipulation
- Consensus-level failures
These are completely different classes of vulnerabilities.
L2 Is Still Software
It is also important to remember that an L2 is not just a proof system. It is a full software stack with many moving parts, and each part introduces its own security considerations.
L2 systems need to worry about:
- Infrastructure security
- Component-level bugs
- Sequencer availability and reliability
- RPC and API dependencies
- Upgrade and governance mechanics
- Operational misconfigurations
L2s scale execution, but they also increase operational complexity.
Real-world rollups work exactly this way. Optimism and Arbitrum use fault proofs. StarkNet uses validity proofs. All of them depend on Ethereum for final settlement and security.
Layer Interactions
The architectural layers make sense when viewed one by one, but blockchains do not run them in isolation. Each layer constantly interacts with the others, and these interactions are what make the system actually work.
Data <-> Execution
The execution layer reads and updates the state, but the state itself lives in the data layer. When a transaction runs, the execution layer checks the current state, applies the changes and then hands the updated state to the data layer to be stored permanently.
execution decides what changes happen, data remembers those changes forever.
Execution and Consensus
Consensus decides the order of transactions and which block becomes part of the chain. Execution processes those transactions in that exact order. If consensus changes the order, the result also changes. This is why ordering matters so much and why L1s and L2s treat ordering differently.
Execution updates the state. Consensus decides which state updates are accepted by the network.
Network and Consensus
The network layer spreads blocks and transactions across nodes. If the network is slow or unhealthy, different nodes see different data at different times. This can temporarily cause forks when multiple blocks compete for the same height.
Consensus resolves these situations by applying fork choice rules and selecting the canonical chain once enough information has been shared across the network.
The network moves information. Consensus tells the network which version becomes the official one.
Architectural Layers <-> L2
Only some architectural layers run directly on L2:
- The execution layer runs faster and cheaper on L2
- The network layer connects L2 nodes and sequencers
- The application layer talks to both L2 RPCs and L1 RPCs
But the most important interaction is this:
- The consensus and data layers for L2 ultimately depend on L1.
L2 produces:
- New state
- Batches
- Proofs
Then it sends these results down to L1 for verification and final settlement.
Execution happens on L2. Final security happens on L1.
End Note!
We now have the full picture. The architectural layers show how a blockchain works from the inside, and the scaling layers show where L1 and L2 fit in that design. L1 secures the system. L2 scales it. Proofs connect them.
In the next blog, we will look a bit more depth into the Optimism Rollup or OP Stack. In the meantime, feel free to reach out @0xCardinal if you have any questions or concern.
Cheers!