In the traditional Web2 world, “Infrastructure” is synonymous with Availability.
When we talk about infrastructure, we think of AWS EC2 instances, Kubernetes clusters, and regional failovers. The primary goal is uptime: ensuring that when a user hits a URL, the server responds.
However, in Web3, the infrastructure mandate undergoes a fundamental shift. It is about Immutable State, not just the availability.
In Web3, infrastructure is the “hardened ground” upon which digital property rights are built. Unlike a cloud database, where a DBA (Database Administrator) can manually run a DELETE command or a CEO can de-platform a user, Web3 infrastructure serves as a Global State Machine.
Every transaction is a transition from State A to State B that, once confirmed, is etched into history. This infrastructure doesn’t just host code, but also enforces Social and Mathematical Contracts that no single entity—not even the developers who wrote it—can unilaterally shut down or edit.
The Trinity of Responsibility
To achieve this level of resilience while remaining usable, the Web3 stack divides its labor into three critical functional layers:
Settlement (L1): The Supreme Court. This layer provides the ultimate “Source of Truth” and finality. It ensures that once a transaction is settled, it is mathematically impractical to reverse.
Execution (L2): The High-Speed Workspace. This layer handles the “heavy lifting” (the high-frequency calculations and transaction processing) without clogging the main settlement layer.
Accessibility (RPC): The Gateway. This is the bridge that allows our familiar Web2 tools (browsers, mobile apps) to communicate with the complex, peer-to-peer reality of the blockchain.
The goal of this architectural design is to provide a “Source of Truth” that is globally accessible yet locally unverifiable.
By decoupling where we execute transactions (L2) from where we settle them (L1), and how we read them (RPC), we create a system that is robust enough to survive geopolitical shifts and corporate failures.
For a Web3 builder, understanding this layer is a mindset shift from building “Apps” to building “State-driven Protocols.”
Well, at least that’s how I felt when I first learnt about it.
Layer 1 Blockchain
In the Web3 stack, the Layer 1 (L1) is the base infrastructure. It is the “Settlement Layer”, the final point of truth where disputes are resolved and the state is finalized. If you think of Web3 as a global bank, the L1 is the Core Ledger.
Consensus as a State Machine
At its core, every L1 is a State Machine. It maintains a global state (who owns what) and updates that state based on new transactions.
The “Consensus Mechanism” is simply the protocol that ensures every node in the network agrees on the next state. For engineers, this is essentially a Distributed Transaction Log:
Proof of Work (PoW): To write to the log, you must solve a cryptographic puzzle. This uses energy as a “cost of entry,” making it physically and economically impossible to rewrite history (Finality).
Proof of Stake (PoS): To write to the log, you must lock up capital (Stake). If you try to cheat the ledger, the network “slashes” your money. This replaces physical energy with financial risk.
The Blockchain Trilemma
Why can’t we just make Ethereum handle 100,000 transactions per second? This is because of the Trilemma. You can only optimize two of these three:
Decentralization: How many people can run a node? (High hardware requirements = lower decentralization).
Security: How hard is it to attack or revert the chain?
Scalability: How fast can the network process data?
Case Studies in Engineering Trade-offs
To see these trade-offs in action, let’s look at the “Big Three” from your diagram (sorry for the screenshot from Canva, Substack can’t insert a table):
Settlement!
As a builder, you treat the L1 as your “Anchor of Truth.” While you might build your app on a faster Layer 2 (which we will cover next), that Layer 2 eventually “settles” its data back to the L1.
The L1 provides the Economic Security that ensures a user’s funds are safe even if the application layer fails.
Layer 2 Scaling
If you have ever tried to buy a $10 NFT on Ethereum and realized the “Gas Fee” was $40, you have experienced the Ethereum Traffic Jam.
The L1 is secure, yes. But it’s also congested and expensive.
It’s like a world-class restaurant with only one table. If you want to eat there, you have to outbid everyone else in the city.
Layer 2 (L2) is the solution.
Its job is simple: Do the heavy lifting elsewhere, but keep the security of the L1.
The “Bar Tab” Analogy
Think of an L2 like a Bar Tab.
In a world without tabs (L1 only), every time you order a beer, you would have to:
Pull out your credit card.
Wait for the transaction to authorize.
Sign the receipt.
Do this again 5 minutes later for the next round.
That is slow, annoying, and fills up your bank statement with 10 different tiny charges.
An L2 is the bartender saying, “Just give me your card now. Drink all night, and at the end of the shift, I will charge you one single total.” You did 10 “transactions” (drinks), but the L1 (the bank) only had to process one final settlement.
The Magic of Rollups
In the industry, this is called modular architecture. We split the work here:
Execution (L2): The fast-paced work of calculating “Who sent what to whom.”
Settlement (L1): The final act of recording the final balance in the “Supreme Court” ledger.
Most L2s today are called Rollups.
Why? Because they literally “roll up” hundreds of transactions into a single “compressed” package and post it to the L1.
Optimistic vs. ZK: two ways of saying “trust me”
There are two main ways L2s prove to the L1 that they aren’t lying about the transactions:
Optimistic Rollups (Arbitrum, Base): “Innocent until proven guilty.”
They assume all transactions are valid. However, there is a 7-day challenge period where anyone can point out fraud. If you catch them lying, the liar gets punished.
It’s easier to build and is very compatible with existing Ethereum code.
ZK-Rollups (Starknet, zkSync): “Prove it with Math.”
They use Zero-Knowledge Proofs—a complex piece of cryptography that proves the transactions are 100% correct without revealing the data itself.
There is no 7-day wait. It’s instant and theoretically more secure, but it requires a “math wizard” level of computation.
Wait, but why …
You might ask: “If L2s are faster and cheaper, why does the L1 even exist anymore?”
Because L2s are not sovereign. An L2 is only as strong as the L1 it settles on. If Ethereum disappeared tomorrow, your Arbitrum “Bar Tab” would be worthless because there’s no “Bank” to settle the final bill.
Nodes & RPCs
You have picked your L1 (The Supreme Court) and your L2 (The Bar Tab).
Now comes the part where most Web2 devs pull their hair out: how do we actually talk to the chain?
If you are coming from the world of AWS or GCP, your first instinct is to look for the “official ethereum API.” You will soon realize it doesn’t exist. There is no “api.ethereum.org/v1/balance”.
Wait, but why?
Because a blockchain is a Peer-to-Peer (P2P) network of thousands of computers, not a centralized server. To get data, you need a Node to act as your translator.
JSON-RPC
Blockchains don’t speak REST or GraphQL (usually). They speak JSON-RPC.
When your frontend asks, “How much ETH does this user have?”, it’s not a simple database query.
Your node has to look at the latest state of the blockchain, verify it hasn’t been reorged (changed), and give you an answer.
This is the “Portal Problem.”
If your portal is slow, your app feels like it’s running on a 1990s dial-up modem, even if the blockchain itself is “fast.”
Build vs. Buy
As a builder, you have two choices for your portal, and both have “hidden costs”:
The hard way (self-hosted): You rent a beefy server (we’re talking 2TB+ NVMe SSD and 32GB RAM minimum), download the entire history of the chain, and run execution clients like Geth or Reth.
You get the total sovereignty. No one can track your IP, censor your transactions, or rate-limit you.
It’s a DevOps nightmare. If your node falls out of sync by even 12 seconds, your app is effectively “offline.”
Managed RPC providers (like AWS): You use Infura, Alchemy, or QuickNode. They run massive clusters of nodes and give you a clean URL (an RPC Endpoint).
It takes 30 seconds to set up. You get fancy dashboards, analytics, and “Enhanced APIs” (like getting all NFTs in a wallet with one call instead of fifty).
However, you are putting a “Middleman” back into a “Middleman-free” system. If Alchemy goes down, your “decentralized” app goes down with it.
The RPC Infrastructure
A junior dev hardcodes one Alchemy URL into their .env file and calls it a day.
A senior web3 builder treats RPCs like critical plumbing!
Blockchains are global, but nodes are physical. If your user is in Singapore and your RPC provider is in Virginia, you’re adding 200ms of lag to every button click.
Real apps use RPC Aggregators or “Load Balancers.” You provide your app with three different providers. If Provider A returns a 429 (Rate Limited) or a 500 error, your code automatically fallbacks to the Provider B.
Don’t think of Nodes as just “servers.”
Think of them as your eyes and ears on the blockchain.
If your eyes are blurry (slow RPC) or closed (provider outage), it doesn’t really matter how fast the L2 is—your user is stuck in the dark.
To wrap up
Building in Web3 is fundamentally different from building in Web2 because you are operating in an environment of "managed chaos."
In Web2, if AWS is up, your app is up. In Web3, the blockchain might be up, but your RPC might be lagging, or your L2 might be undergoing a 7-day fraud-proof window.
To be a top-tier builder, you must treat this layer like critical plumbing for your application.
You don’t just “set it and forget it.” You design with the following three principles in mind:
Trust, but Verify: Don’t trust a single source of truth for your frontend. Use fallback RPCs and quorums to ensure your users aren’t just seeing “phantom” balances.
Pick Your Battlefield: Choose your L1/L2 based on the specific needs of your app. If you are building a high-frequency game, you need the parallel execution of Solana or a fast L2. If you are building a protocol for institutional wealth, you want the absolute finality of Ethereum L1.
Design for Redundancy: In the decentralized world, “Single Point of Failure” is the ultimate sin. Whether it’s having backup RPC providers or using indexers (like The Graph network) to handle complex data, your architecture should assume that any single piece of the stack can—and will—hiccup!
If you can only remember three things from this article, let it be these:
L1 (Settlement): The ultimate source of truth. Slow, expensive, but unshakeable.
L2 (Execution): Where the action happens. Fast, cheap, and “rolls up” to the L1 for security.
RPC (Accessibility): Use multiple providers to avoid “going blind.”
By understanding these three layers, you’ve moved from being someone who just “writes smart contracts” to someone who understands the foundation of the new internet.
Hope you enjoy this post. I am putting smart contract in the next issue because I don’t want to make this too long (given how short attention span we modern people have).
Cheers.