On scaling Ethereum and accelerating transactions with Layer-2 rollups
Contents
- From frustration to innovation (Introduction)
- First up – what are rollups?
- How do rollups work?
- Rollup wars (Optimism vs ZK)
- Appendix
“They see me rollin’, they hatin’, gotta catch me riding dirty.”
Roll this, roll that, roll-up. What is everyone in Web3 going on about rollin’?
Well, it is Layer 2 season and scalability is the name of the game (actually airdrop hunting is the name of the game, but let’s gloss past that for now). With both Optimism and Arbitrum airdrops firmly in the rear-view mirror, crypto twitter is eagerly awaiting the next one. The talk of the town is that it is likely going to zkSync. We will be looking to unveil the shroud of mystery that surrounds ZK-EVMs in the next post. However for today, let’s focus on roll-ups as a whole.💡 The crucial distinction between sidechains and rollups is that sidechains rely on their own security, while rollups inherit the security of Ethereum.
From frustration to innovation
If you have been around for the last bull market, you would know how congested and bottlenecked Ethereum has become. Network fees are easily hitting three-figure values even for two-figure transactions. The key issue for users – high fees for small transactions, compounded by a long delay. Waiting for your Ethereum transaction to go through feels like waiting for France to sort out its political crisis – slow and painful. Ridiculous, right?
Hence, the conversation that giga-brains are having regarding scaling. Here’s the TLDR. (Note: For the lengthier explanation on scaling, skip to “An aside on the scalability problem” section)
Two methods to scale a blockchain network
First up – what are rollups?
So what exactly are we rolling here? Let’s open this can of worms with a couple of points.
- Rollups execute the transaction off-chain (from Ethereum), batch the transaction data, compress them, and send them to Ethereum. This reduces the load on the main Ethereum network since it does not need to process those transactions.
- How do we ensure that the transaction data posted onto Ethereum by rollups is valid? Different rollup types handle this differently. There are two broadly accepted approaches: Optimistic Rollups and ZK-rollups.
We should also note that the propagation of rollups plays well into Ethereum’s roadmap, which is very much roll-up centric. Key points are:
- Computation will migrate from mainnet to rollups
- Rollups will settle to Ethereum, i.e. post final copy of ownership to mainnet
How do rollups work?
Transactions from an account on the main Ethereum network itself can only occur sequentially. Let’s say you would like to transfer some tokens to Persons A, B, C, and D. You would have to first send the transactions but it is likely you will experience longer confirmation times and higher gas fees.
Rollups provide a solution by reducing the overall time and cost to carry out these transactions. In a nutshell, rollups have a number of smart contracts deployed on Ethereum to manage interaction between themselves (L2 chain) and the L1 chain. Users deposit funds into one of these contracts, and receive an equivalent amount on the L2 – very similar to bridging assets.
💡 Rollups involve bundling multiple off-chain transactions in huge batches before you submit them to Ethereum. With such a method, rollups can facilitate spreading of fixed costs throughout multiple transactions, thereby reducing end-user fees. What’s more, the transaction data still derives their security from the main Ethereum network.
Brief step-by-step on rollups
- Deposit some funds into the Layer 1 rollup contract. The rollup contract will then maintain a state root on the main chain. A state root is the Merkle root of the rollup’s state. It records the addresses, account balances, contract codes, and other information that are within the rollup.
- Once the funds are deposited, you can create a transaction on the L1 chain that requests the transfer of the deposited funds to the L2 rollup.
- The rollup contract will lock the deposited funds and create a corresponding entry or state root on the L2 chain, which represents the deposited funds. The deposited funds become available on the L2 chain and can be used to execute transactions within the rollup.
- You can send each transaction to the rollup contract on the L2 chain. The rollup will validate and execute the transaction according to its rules.
- To execute a transaction on the L2, you can send the transaction to the rollup contract on the L2 chain.There exists a sequencer, whose purpose is to bundle multiple transactions into a batch on the L2. The sequencer will then submit the batch of transactions on the L2 back to the L1 chain via a single transaction. The batch will either be accepted or verified according to the corresponding rollup mechanism. If you want to withdraw the funds from the L2 back to the L1 chain, you can call another function on the Layer 2 smart contract. This will lock the funds on the L2 rollup and create a corresponding entry on the L2 chain.
That’s a lot of details but the key point is that computation takes place on the L2 chain. Practically speaking, what does it mean and how does this work? Users are expected to bridge their assets over to the L2 chain, and then execute whatever transactions they wish to. This way, transactions occur ‘off-chain’ from the L1. They are instead processed and batched on the L2. The results are compressed and sent back to the L1 for recording.
The wider impact is that an increasing number of protocols and projects will be looking to build upon L2 chains so that users can interact with them in a less computationally intensive – and consequently, a lower gas-intensive – environment. All these transactions can now occur without fear of gas ways and $200 gas fees, off-chain, on an L2 rollup. The updated states will be reflected on mainnet accordingly.
Now while there are several other actors and contracts in the mix, this high-level explanation should serve as a useful entry point.
Next up, the ROLL-UP WARS!
Roll-up wars
Alright, so we have answered one question and left you with a couple more. Let’s start with the obvious ones first – what are Optimistic and ZK rollups are?
- Optimistic rollups assume transactions are valid and depends on fraud proofs to identify inaccurate transactions within the challenge period of seven days.
- ZK-rollups submit validity proofs along with batches. This allows for immediate withdrawals, since transaction verification is done together with submission.
Brief notes on Optimistic rollups
- Termed as “optimistic” because these rollups assume all transactions in the batch submitted are valid by default
- After an Optimistic rollup batch is submitted to Ethereum, anyone can challenge these transactions within a certain time window known as the “challenge period”. As a result, withdrawals can take up to a week.
- Challengers submit fraud proofs as means to deny the submitted batch of transactions as illegitimate.
- When a batch is proven to be illegitimate, the roll-up protocol re-executes the transactions and updates the rollup. If a transaction is invalid, its block validator will receive a penalty. Off with his head!
- Smart contracts are on Ethereum which control the operation of optimistic rollups. So, they depend on the Ethereum for security. However, they still have increased chances of fraud when there is a lack of honest validators or nodes.
- Scaling factor: optimistic rollups are expected to have an estimated ~100x more throughput compared to the mainnet.
- Examples: Optimism, Arbitrum
For a more detailed view of the Optimism architecture, please find on the Appendix under Optimism Architecture.💡 Optimistic rollups have a big trade-off. The challenge window must pass before settlement is finalised. This simply means that withdrawals from the L2 into L1 require a 7-day settlement period. In traditional finance, a 7-day settlement would be considered excessive.
We will be diving deep into the ZK world in the next article. But for now, here is a snippet for the sake of comparison.
Brief notes on ZK-rollups
- Similar to optimistic rollups, users firstly deposit assets into a smart contract on the mainnet. The ZK-rollup operator then mints an equivalent amount of assets on the rollup chain and gives it to the depositor. On the mainnet itself, the assets remain in escrow.
- ZK-rollups derive settlement from Ethereum, akin to optimistic rollups. This allows the rollup chain to be much more centralised without sacrificing trustlessness.
- However, where optimistic rollups assume that everyone acts honestly, ZK-rollups operate by ensuring that it is indeed the case.
- Transaction batches are accompanied by their validity proofs, which are submitted on the L1. They serve as a proxy for their corresponding bundles – proof that no shenanigans were had.
- Validity proofs are essentially known as Zero-Knowledge Proofs. It is a category of mathematical proofs that allows one party (prover) to prove to another party (verifier) that a statement is true without revealing the statement itself.
- As with optimistic rollups, proof generation is difficult and computationally intensive but proof verification is easy.
- Example: zkSync, StarkNet
So those are our two main contenders. Who will emerge victorious, you may ask? God knows. Many have got their money on zkSync, simply because there is no withdrawal delays. Computational power can also increase, easing the process of ZK-proof generation.
That’s a fair belief, given how closely technological progress has so far trailed Moore’s law. Time will only tell which approach comes out on top, and then the market will decide accordingly. Or else the SEC will.
Appendix
An aside on the scalability problem
It’s crucial for blockchain to decentralise in order for regular users to be able to run a node easily The reason – to prevent coordinated attacks by larger entities that might organise a change in the block structure to further their own interests. Therefore, scalability is not about TPS; it’s about resources. Increasing decentralisation is equivalent to increasing the likelihood that someone is able to participate in the network.
Scalability has two goals:
- Maximise the population of nodes. The ideal state would be that anyone can run a node and validate transactions in real-time.
- Reduce fork rate. Block producers can start working on the next block as fast as possible.
Bottlenecks to Scalability
- Storage: How big is the blockchain? Can node hardware deal with such sizes?
- Compute: How long does it take me to get a copy of the blockchain to date, and be convinced that it is authentic?
- Bandwidth: How long does it take for blocks to propagate across the network? Can we fall behind because we cannot receive the blocks in time? What other latency issues are there due to distance and connectivity?
Optimistic Architecture
For more research and insights by Arcane Group, explore here.
Stay updated and follow Arcane Group on LinkedIn and Twitter.