A typical Yoruba Nigerian party always includes souvenirs and a variety of food to share with guests. When it's time to share, it often becomes chaotic and time-consuming, with biases, and in the end, food and souvenirs still don't reach all the guests.
My neighbour's wedding came with high expectations and careful planning. In her words, "I want all my guests to be well-fed, and souvenirs must go around." She budgeted for 500 guests, even though invitations were sent out for only 200. You can see she planned it well and was ready to satisfy everyone.
The day arrived like any other. The hall was beautifully decorated, the caterer was prepared, and the souvenirs for 500 guests were sorted out. Everything was going smoothly until I heard, "Food has finished." I looked around the hall, and 40% of the guests had not been served. Immediately, I alerted my mom about the incident.
Like a lioness ready to defend her den, my mom rose and questioned the caterer about how the food ran out. To be honest, the caterer was nervous because she knew the consequences. She said, "Mrs. Adelanke, please don’t be angry. The guests kept coming and asking for food, and I thought everyone had been served." Immediately, more food was prepared, and the rest of the guests were taken care of.
The same issue happened with the souvenirs; only 50% of the guests received them. The bride wasn’t happy, even though there were no complaints (some were left), because most of the guests left angrily due to the food distribution problem.
After the celebration, I sat down and analyzed the incident. I realized that we could have used servers and ushers to manage the distribution of food and souvenirs.
This scenario can be likened to Ethereum’s scalability problem. Ethereum faces challenges in efficiently processing transactions. As the network grew, it struggled to handle multi-transactions, leading to congestion and high gas fees. To address this issue, Layer 2 solutions were developed, which act like servers and ushers in managing the distribution at the party.
This article will reveal how the Ethereum L2 solution has evolved from Earlier solutions like State Channels and Plasma Chain to Rollups and zkEVM, including how these solutions work and their advantages over each other.
Early Attempts at Scaling Ethereum: Plasma and State Channels
The adoption of layer 2 scalability solutions in the Ethereum network can be traced to the earlier development of State Channels and Plasma in 2015 and 2017, respectively.
State Channels
State channels are a scaling technology solution that Ethereum developers have explored since the blockchain first launched in 2015. State channels are peer-to-peer (p2p) protocols that allow two entities to securely transact with one another off-chain while minimizing the interaction with the Ethereum mainnet.
Participants exchange cryptographically signed messages(transactions), and any proposed state update is only valid if it is signed by all involved parties. Once the interaction is complete, the final state is settled on-chain, reducing gas fees and transaction latency.
For more understanding, See State channel as a private board room located out of a company (Ethereum), where managers and department leads hold meetings(transactions), and once the meeting is completed, the secretary closes the meeting and submits the summary to the company.
State channels are likened to an access card in a hotel. You use this card to open your room, enjoy your stay, and then lock it with the card when it's time to check out.
How State Channel Works
A State channel involves participants, a multi-sig smart contract, a channel, and a blockchain(Ethereum), and it goes through this process:
- Opening of the Channel
- Opening a channel is like depositing some amount of money in a new account. Participants are required to fund a smart contract on the mainnet. This deposit serves as a facilitator so that participants can transact freely without needing to pay gas fees for every transaction.
- This deposit also serves as a commitment to each participant's honest behaviour. That is, if a participant is guilty of a fraudulent act during the dispute resolution phase, the contract slashes their deposit.
- Using the Channel
- After participants have signed the initial state, participants interact by signing and sending transactions to each other for approval. They initiate the state updates with these transactions and sign updates from others.
- Closing the Channel
- Closing a state channel is similar to leaving a booked room in a hotel. It requires submitting the channel’s final, agreed-upon state to the on-chain smart contract. The details referenced in the state update include the number of each participant’s moves and a list of approved transactions.
- After checking that the state update is correct, the smart contract closes the channel and divides the locked funds based on the channel's results. Off-chain payments are added to Ethereum's state, and each participant gets their share of the remaining funds.
Plasma Chains
Due to the shortcomings of State Channel, Plasma chains were first popularized back in 2017 as a scaling solution to off-load data and computation from the Ethereum mainnet. Plasma chains are independent child chains to a parent chain (Ethereum); they operate with their block validation mechanisms and are managed by smart contracts deployed to the parent chain.
You can compare these chains to a mother and her child, where the mother manages and secures the child's life with rules and regulations. The child relieves the mother of the stress of house chores (congestion and computational burden) in her way while staying under her mother’s protection.
How Plasma Chains Works
- Child Chains
- These are chains created by smart contracts that are deployed to Ethereum. These smart contracts enable the child chains to function on their own defined accord.
- Off-computations
- As mentioned earlier, the child chain relieved the stress of computational burden. Plasma offloads some of these transactions to child chains, and these child chains use their operators to execute them.
- State Commitment
- After these transactions have been executed, these child chains submit the “STATE COMMITMENT” periodically to the Ethereum mainnet. This state commitment uses a technique called commitment schemes. A commitment scheme is a cryptographic technique for committing to a value or statement without revealing it to another party.
- This mechanism prevents fraudulent or invalid transaction profilration.
- Entries and Exits
- Plasma chains use master contracts running on Ethereum to track state commitment, transfer, manage deposits and withdrawals, and prevent fraud through challenge mechanisms.
- This is how entries and Exist works :
- Diddy wants to use Plasma, so the first thing she will do is deposit some coins and tokens into the plasma smart contract on Ethereum. The Plasma operator monitors this and recreates the equivalent amount on the Plasma chain, releasing it to Diddy’s address. Once Diddy confirms receipt, she can use the funds for transactions on the Plasma chain.
- When she wants to withdraw this deposit, she must present a “no-Fraud-proof,” validating her ownership of the token. If she passes, Her token or coins will be withdrawn successfully from the plasma contract on Ethereum.
The Rise of Rollups
State channels and Plasma chains provided initial solutions to reduce transaction execution time and congestion on the Ethereum mainnet, but they have limitations in terms of usability and security. These limitations led to the rise of Rollups.
State Channels require participants to be online and involved in every transaction which means that it can’t be used for border use cases in terms of processing transactions offline. Plasma chains, on the other hand, use their consensus mechanism that doesn’t tally with the parent’s mechanism. Plasma chains also faced challenges with complex exit protocol, data availability issues, complex user experience, and security.
Rollups use more advanced and reliable techniques to process transactions off-chain and then “roll” them up to a single transaction that is submitted to the Ethereum mainnet.
Let's use an analogy to explain Rollup using the examination process. Ethereum is the teacher who sets the questions, and the students’ answer booklets are the transactions. It is time-consuming if the students have to submit their answer booklets to the teacher individually. Instead, the teacher employs invigilators (Rollups) to supervise the examination process, collect the answer booklets on behalf of the students, remark the scripts, and submit the students’ scores to the teacher (Ethereum).
Types of Rollups
There are two types of rollups, each with its own way of processing transactions off-chain. They are Optimistic and Zero-knowledge rollups.
Optimistic Rollups
This is an approach to scaling Ethereum that involves moving computation and state storage off-chain. It uses compression techniques to reduce the amount of data submitted to the Ethereum mainnet. They are considered “optimistic” because they assume off-chain transactions are valid and don't publish proofs of validity for transaction batches posted on-chain. Instead, it uses Fraud proving scheme to detect incorrect transaction calculations.
Optimistic Rollups comprise two parts:
- On-chain Smart Contract: Optimistic rollup operation is being controlled by a smart contract running Ethereum. This contract handles state updates, stores rollup blocks, and tracks users’ deposits.
- Off-chain Virtual machine: Optimistic rollups perform their operations and state storage on another VM separately from the Ethereum virtual machine(EVM).
- The off-chain VM is where applications live and state changes are executed; it serves as the upper layer or "layer 2" for an optimistic rollup.
How Optimistic Rollups Work
- Transaction Execution and Aggregation: Users submit transactions to “operators”(nodes) also known as validators or aggregators who process, aggregate, compress and publish them on Ethereum. These operators leverage the same Ethereum penalties for invalid blocks.
- Submitting Rollups Blocks Ethereum: These operators bundle the transaction, compress the data and submit it to Ethereum as a Calldata or blob.
- State commitment: the state is organized as a organized as a Merkle tree called a “state tree”, with the state root stored in the rollup contract to reference the latest state. Each state transition creates a new state root, which operators submit with the old state root when posting transaction batches. If the old state root matches the current one, it is replaced by the new state root. Operators also commit a Merkle root for the transaction batch, allowing verification of a transaction's inclusion. These commitments are essential for validating state changes, and invalid state roots can be discarded to ensure accuracy.
- Fraud proving: Optimistic assumes all transactions are valid without proof of validity, so anyone can publish a block. In case, anyone challenges the validity of the block, Fraud proof is used to ensure the correctness through multi-round interactiveness.
- L1/L2 Interoperability: Optimistic rollups are designed for interoperability with Ethereum Mainnet and allow users to pass messages and arbitrary data between L1 and L2. They are also compatible with the EVM, so you can port existing dApps to optimistic rollups or create new dApps using Ethereum development tools.
Zero-Knowledge Rollups(ZK Rollups)
ZK rollups work similarly to optimistic rollups. The only difference is that ZK rollups prove each batch of transactions correct by having a validity proof (zero-knowledge (ZK) proof) submitted on-chain for every batch of transactions.
Zero-knowledge proof is a cryptographic protocol that allows one party to convince another that a statement is true without revealing any additional information.
The ZK-rollup's state is also controlled by a smart contract deployed on the Ethereum network. To update this state, ZK-rollup nodes must submit a validity proof for verification. The validity proof is a cryptographic assurance that the state change proposed by the rollup is the result of executing the given batch of transactions.
How ZK Rollups Work
- Transaction Process: After users have signed a transaction, these transactions are processed by a centralized sequencer or validator(L2 operator). The operator then aggregates these transactions into batches and submits them to Ethereum.
- Data Storage: Zk rollups also published compressed on-chain as call data. The reason is because
calldata
does not affect Ethereum's state, making it a cheap way to store data on-chain.
- State Commitment: ZK rollup’s state is stored as a Merkle tree, including L2 accounts and balances. When a batch is processed, the rollup operator computes a new Merkle root to reflect state changes and submits it to the L1 contract for verification.
- Validity Proofs: ZK rollups use Validity Proofs either ZK-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) or ZK-STARK(Zero-Knowledge Scalable Transparent Argument of Knowledge) to confirm the correctness of off-chain state transitions without having to re-execute transactions on Ethereum or revealing the statement itself.
- Entries and Exit: Users deposit funds into the ZK-rollup by sending transactions to the rollup’s L1 contract. Exiting involves providing Merkle proof and transaction data to withdraw funds back to L1.
How Rollups Enhance Ethereum’s Scalability While Maintaining Trustlessness
Rollups enhance Ethereum scalability while still maintaining trustlessness by :
- Off-chain Computation: Rollups process transactions off-chain and then submit a single compressed transaction to the Ethereum mainnet.
- Proving validity: Rollups, despite reducing the amount of data storage on Ethereum, still ensure security by employing various techniques to prove this data.
- Compatibility with EVM and Solidity allows developers to port Ethereum-native smart contracts to rollups or use existing tooling to create new dApps.
- Data Recovery: stored data can be recovered off-chain state on L1, which guarantees security, censorship resistance, and decentralization.
- Rollups can handle complex and multiple transactions without requiring constant participant interaction.
Prominent L2 rollup Projects include Optimism, Arbitrum, zkSync, Starknet, Canvas Connect, etc.
zkEVM: The Next Evolution
Zero Knowledge Ethereum Virtual machine(zkEVM) is now the new kid in the Block. It represents the next evolution in Ethereum’s Layer 2 scaling solution. It is a virtual machine that executes smart contract transactions in a way that’s compatible with both zero-knowledge-proof computations and existing Ethereum infrastructure. This enables them to be part of zero-knowledge rollups, layer-2 scaling solutions that increase transaction throughput while lowering costs.
Initially, zk-rollups did not have the capability for smart contract execution, thereby focusing specifically on general token payments and exchanges., In this case, zkEVMs empowers zk-rollups to offer support for dApp development on Ethereum and also allows smart contracts to execute off-chain with cryptographic guarantees of correctness.
Components Of zkEVM
From the name, zkEVM comprises two main components, namely: Ethereum Virtual Machine(EVM) and Zero Knowledge Proof(ZKP).
- Ethereum Virtual Machine (EVM): The underlying framework that allows developers to execute smart contracts. zkEVM extends EVM by adding zero-knowledge proofs to ensure contract execution correctness without needing significant changes in the code.
- Zero-Knowledge Proofs: This cryptographic method ensures that the correctness of transactions and contract executions can be verified without revealing sensitive data.
How zkEVM works
- zkEVM Execution Environment: The zkEVM Execution Environment works similarly to EVM by enabling smart contract execution. It takes the initial state, computes transactions, and outputs a new, updated state and an accompanying zero-knowledge proof. Because zkEVMs are based on Ethereum’s EVM, developers can easily port Ethereum dApps and tokens to the zkEVM.
- zkEVM Proving Circuit: the proving circuit generates ZKPs to confirm that transactions were processed correctly without revealing sensitive information.
- zkEVM verifier contract: zkEVM takes responsibility for verifying the validity of proofs generated by the ZK rollups. The verifier carries out computation on the proof while confirming the correctness in the computation of outputs from the concerned inputs.
Advantages of zkEVM over L2 Rollups
- Secure Scalability: zkEVM doesn’t have to adhere to Ethereum’s consensus protocol, but zkEVM still strictly verifies all layer 2 transactions on it. This means that despite optimizing speed, there is no security compromise.
- Low cost: Some L2 rollups still struggle with high gas fees because they post all transaction data on-chain. In contrast, zkEVMs only need to publish final state changes on-chain, as the zero-knowledge proofs ensure the validity of all transactions in the batch. This reduced cost benefits applications and end users of the zkEVM.
- Fast Finality: In the case of zkEVMs, the transactions posted on Ethereum are finalized immediately with verifiable proof of validity. As a result, the Ethereum mainnet could ensure faster implementation of state updates.
Examples of zkEVM include Polygon zkEVM, zkSync Era, Nethermind’s Warp, etc.
Conclusion
From my observation, the evolution of Layer 2 solutions from State Channels and Plasma chains to Rollups and zkEVM shows that the Ethereum network is here to stay. As the network continues to grow, more scaling solutions with low fees will emerge, making it more efficient for dApps to thrive in the ecosystem.
Reference
What is Plasma Blockchain
Ethereum Doc
What is a zkEVM?
Know Everything about zkEVM.