please read my previouos ethereum blog before reading this
The fundamental scalability issue with ethereum is that it has a fixed amount of **storage (**for example - 2kb) in a single block and every 12 seconds a new block is minted in ethereum.
but there is a problem with this fixed storage cap on the block. what if someone runs a transaction which is computationaly very heavy and takes more than 12 seconds?
so what’s the solution?
in my ethereum blog I explained that how much computation and storage your transaction is going to take is calculated in GAS by EVM. so every ethereum block does not have a storage limit like bitcoin but a GAS limit. This is the fundamental issue in the scalablity of ethereum.
Layer 2 Networks were invented to solve this.
Layer 2 Networks are not blockchains, they are simple programs running off-chain.
suppose you want to do transactions on L2 network. you will request a **bridge contract (**don’t worry its just a fancy name of a smart contract) , that please give my 2 eth from my ethereum main net (Layer 1) to this Layer 2 offchain software.
these layer 2 Networks have their own State in their harddrive, which stores your public address (same as the one you use of Layer 1) and balance.
note: layer2 networks are not blockchains, far from it, they are just your normal softwares, there are no miners, the state they store has no relation or similar data to your layer 1 blockchain
so when you asked bridge network to give layer 2 2eth, an event is emmited by the bridge contract which obviously gets stores in etheruem state. these layer 2 networks are continously listening for those events, so as soon as the layer2 network heard that event, it stored 2eth in your address in his local state.
now suppose you transfered 1eth to bob, the transfer would be instantanious, you would not have to wait 12 seconds or grater like on ethereum main net. but there is a catch
this balance would not show up in your etheruem balance (ethereum state has not been changed, how could this balance show up there)
you can not withdraw this 1eth left with you from the L2 networks, the withdrawl can only happen through L1 network, so this 1eth would have to be transfered to the main net first which is not instantneuos.
now there are just two problems left to be solved for L2 Networks to really work
1. how do we verify L2 network is not melecious?
see in L1 networks the transactions are verified every 12 seconds and then only it shows up in your account, so every transaction is verified. but in L2 networks the transactions are instant no verification, no blockchain.
solution
after every some-number of transactions on L2 (say 10k), the L2 networks sends the transactions and state root (hash of his entire state upto that point) to the main net, the main net then opens up a 7 day window where any verifier can verify if the transactions given by L2 networks correct.
these verifiers are special programs whose entire role is to verify these L2 networks, if any L2 network is found milicious, their colletral ( a certain amount one has to deposit as security to act as L2 networks ) is seized and a reward money is given to these verifiers
99.99% L2 networks behave trustfully the .01% is where verifiers make money.
after verifiers have verified that all the transactions are correct, these transactions are added to the ethereum block but not executed by the evm and therefore not stored in the ethereum state.
if we had to execute transactions ( execution takes a lot more gas then storage) then why would we even build these l2 networks.
how does this verifier work
these verifiers store previous states of various L2 networks, so when l2 networks submit transactions and state root to L1 networks, these verifires run those transations and build the new state and calculate the state root from that new state.
if the state root of verifier and L2 network does not match, the l2 network is found guilty and peanalised and all the transactions are destroyed (that is why it is not advised to do very big transactions on L2 networks).
2. How to withdraw money stored in L2
the core problem is you can not withdraw money from L2 networks (becuase it has not been approved by the verifier yet) and L1 networks do not know how much money do you have in L2 networks because these two do not share any state between them. and you definately do not want to give whole state of L2 networks which is in gigabites to L1 network to verify
solution?
he answer, once again, is a Merkle Tree.
1. The "Withdrawal Tree": A Dedicated Ledger for Exits
To make this process clean and efficient, Optimistic Rollups don't just mix withdrawal receipts in with all other state changes. They maintain a dedicated, separate Merkle Tree just for withdrawals.
What it is: A simple Merkle tree where each "leaf" is the hash of a single withdrawal action.
A Leaf's Data: HASH(user_address, amount, nonce) -> e.g., HASH("0xAlice...", 1 ETH, 1)
This Hash is what is called “withdrawal recipt”
The Root: As withdrawals happen on L2, they are added as leaves to this tree. The Sequencer calculates the withdrawal_tree_root ( the top hash of the merkel tree).
This withdrawal_tree_root is now a crucial piece of data. It is this specific root that the L2 Sequencer must commit to the L1 Bridge Contract.
so with transaction data and state root this merkel tree root is also sent to the L1 network
2. The User's Proof: The Merkle Proof
Let's say Alice's withdrawal was one of four in a batch (W_A, W_B, W_C, W_D). The Sequencer built a Merkle tree and submitted the final root (Root_ABCD) to L1.
The Withdrawal Tree on L2 looks like this
[ Root_ABCD ] <-- This is what's stored on the L1 contract.
/ \
[ Hash_AB ] [ Hash_CD ]
/ \ / \
[ H_A ] [ H_B ] [ H_C ] [ H_D ]
Alice now wants to prove to the L1 contract that her withdrawal (W_A, which hashes to H_A) is part of this root.
She goes to a public L2 node (or block explorer) which has all the batch data and asks for a Merkle Proof for her withdrawal. The node gives her the necessary "sibling" hashes to reconstruct the root:
Her own withdrawal receipt (W_A).
The hash H_B.
The hash H_CD.
This collection of data {W_A, H_B, H_CD} is her proof.
The Last problem
so to withdraw any money from L2 networks you will have to wait around 7 days to first the transactions from L2 network get approoved on L1 networks
how can we solve this?
solution :- Insurers ( also known as liquidity providers )
Insurers have money in both L2 networks and L1 networks, when you want to withdraw money from your L2 network, you transfer your money from your L2 account to their L2 accounts and they transfer same amount of money from their L1 account to your L1 account and take a percentage of cut offcourse.
they also bear the .01% risk of L2 behaving miliciously and they loosing their L2 money
Zero Knowledge Rollups
the above method of L2 prooving L1 that transactions are fair is time consuming and costly, l2 networks working on above methods are called optimistic rollups
Optimistic Rollups use an economic, court-like system: "Innocent until proven guilty." They rely on a 7-day challenge period and economically incentivized Verifiers to catch fraud. The proof is social and economic.
ZK-Rollups (Zero-Knowledge Rollups) use a purely mathematical system: "Guilty until proven innocent." They force the Sequencer (now called a Prover) to generate a cryptographic proof that every single transaction was executed correctly. The proof is mathematical.
1. The Core Idea: Zero-Knowledge Proofs (The Magic)
This is the most complex part, but we can understand it at a high level without needing a PhD in cryptography.
A Zero-Knowledge Proof (ZKP) is a cryptographic marvel. It allows one party (the Prover) to prove to another party (the Verifier) that a statement is true, without revealing any information about the statement itself other than the fact that it is true.
For our purposes, the statement is: "I started with L2 State Root A, correctly executed this batch of 10,000 transactions, and ended up at L2 State Root B."
The ZKP is a small, compact piece of data that mathematically proves this entire statement is true.
Key Properties of a ZKP in a Rollup Context:
Validity: A Prover can only generate a valid proof if they actually performed the computation correctly. It is computationally impossible to create a valid proof for an invalid state transition (i.e., to prove a lie).
Succinctness (The "S" in SNARKs/STARKs): Generating the proof is computationally very intensive and requires powerful hardware. However, verifying the proof is incredibly fast and cheap. An L1 smart contract can verify a proof for 10,000 transactions in a fraction of a second, using very little Gas.
Zero-Knowledge (Less Important for Rollups): The "ZK" part means the proof doesn't reveal the details of the transactions, just that they were valid. This has privacy implications, but for scaling, the "Validity" and "Succinctness" properties are the most important.
Note: The two main types of ZKPs used are ZK-SNARKs and ZK-STARKs. You don't need to know the difference other than that they are competing cryptographic technologies to achieve the same goal.
2. The ZK-Rollup Workflow: Instantaneous Verification
Let's see how the workflow changes compared to an Optimistic Rollup. The L2 side is similar, but the interaction with L1 is fundamentally different.
Step 1: Off-Chain Execution (Same as Before)
Users submit transactions to an L2 Sequencer/Prover.
The Prover orders them, executes them, and updates its local L2 state.
Step 2: Proof Generation (The Hard Part)
After executing a batch of, say, 10,000 transactions, the Prover's powerful machine begins the intensive process of generating a ZKP for that entire batch of computation.
This process proves the transition from the old l2_state_root to the new l2_state_root.
Step 3: On-Chain Verification (The Fast Part)
The Prover submits a single transaction to the L1 Bridge Contract (often called a Verifier Contract). This transaction contains:
The compressed transaction_data (for data availability, just like before).
The new l2_state_root.
The Zero-Knowledge Proof.
The L1 Verifier Contract now performs its magic. It does not have a challenge window. It immediately runs its verify() function on the proof.
This verify() function is a mathematical calculation that checks the validity of the ZKP. It will return either TRUE or FALSE.
If the proof is valid (TRUE), the contract instantly accepts the new l2_state_root as final and canonical. The state is updated immediately.
If the proof is invalid (FALSE), the contract simply rejects the entire transaction. The malicious Prover has wasted a huge amount of computational effort and the gas fee for the failed transaction.
This was all for Layer-2 networks, suscribe to get more blogs like these.
ERC-20 and NFT Internals blog are commit out next