Introduction to Scaling Solutions

Ethereum, while being an extremely versatile blockchain, still has significant usability constraints. And if you’re a frequent Ethereum user, you know why. Ethereum has trouble with scaling, that is, handling an increasing number of transactions. Fortunately, there have been some remarkable scaling solutions to alleviate this, and we will dive into them in today’s article.

The Problem

The current Ethereum version has low transaction throughput and high latency in processing. This means that transactions are both slow and prohibitively expensive, due to the high demand of people who want to use it relative to what the network can take at any given time.

The experience of spending way too much on ETH gas fees is so specific and recognizable that someone made a tool to share and measure that pain: http://fees.wtf.

Those steep gas prices have caused bizarre scenarios like these:

• Users paying more in gas fees to mint NFTs than the market price of those same NFTs.
• Users not being able to withdraw their assets from a smart contract because it costs more gas than the assets themselves are worth.
• Users choosing not to repay a crypto loan, because the transaction fee costs more than the liquidation penalty.

This is a massive disadvantage for Ethereum, making the usage of ETH-based dApps impractical for many users. And with the ecosystem of on-chain dApps for DeFi, NFTs, and GameFi expanding rapidly, these issues are compounding. ETH users are much in need of a fix.

The Solution

There are two general types of scaling solutions proposed for the above issues:

On-chain scaling refers to any direct modification made to a blockchain, like data sharding and execution sharding in the incoming version of Ethereum 2.0. Another type of on-chain scaling would be a sidechain with two-way bridge to Ethereum, like Polygon.

Off-chain scaling refers to any innovation outside of a blockchain, i.e. execution of transaction bytecode happens externally instead of on Ethereum. These solutions are called L2, because layer 2 works above layer 1 (Ethereum) to optimize and speed up processing. Arbitrum and Optimism Ethereum are two well-known examples of L2 scaling solutions.

Currently, we can distinguish between two leading L2 solutions as:

• Zero-Knowledge (zk) rollups, and
• Optimistic rollups

We’ll explain more about their methodologies later. But for now, just remember that all L2 solutions handle transaction execution off-chain, meaning they rely on a separate infrastructure to both execute incoming transactions and update the state.

So now that we know what rollups are for, how do they work?

Instead of executing and storing all the data on Ethereum, where transactions are only processed at a premium, we decide to only store a summary of the L2 state on Ethereum. This means that all of the actual computation and storage of the contract is done on its execution layer, or Layer 2.

In this way, rollups can inherit Ethereum’s security guarantees, while still acting as an efficient scaling solution. So here’s where we explain the difference between our two flavors of rollups: zk-rollups and optimistic rollups. zk -rollups bundle together many off-chain transactions into a single verifiable batch using zk-SNARK. zk-SNARK is an extremely efficient, zero-knowledge proof that allows one party to prove it possesses certain information without revealing that information. These validity proofs are then posted to the Ethereum blockchain.

Optimistic rollups also batch together off-chain transactions into batches (rolls them), but they do not contain additional proof guaranteeing its validity. These rollups “optimistically’’ assume all transactions are valid. When assertions of the L2 state are posted on-chain, validators of the rollup can challenge the assertion when they think someone has posted an incorrect or malicious state. This is called “fraud detection”. The security of this system relies on the validator posting a bond along with their state that is forfeited to the challenger if the challenger can prove that the state is incorrect.

Let’s look at some examples of rollups that are currently in use.

Arbitrum and Optimism

Arbitrum and Optimism are both scaling solutions based on the concept of optimistic rollups, which means that they store a summary of all L2 transactions on Ethereum. Both of these solutions depend on ‘fraud proofs’, which is a way of detecting whether a transaction being verified is incorrect. The key difference between the two solutions is the way fraud-proofs are handled by the OVM 2.0 and AVM.

But before we talk about that, it’s important to understand the distinction between executing and proving.

Executing means advancing the state of a blockchain by running transactions inside the virtual machine. The Ethereum Virtual Machine has a stack-based architecture. We can control the stack by using the opcodes, like ADD, SSTORE, MLOAD, etc. When smart contracts receive a message, their EVM bytecode is run, which allows them to update the state or even send further messages to other contracts.

‘Proving’ is simply the act of convincing Layer 1 contracts that an execution claim is correct. Some systems based on EVM Layer 1 rely on re-executing the disputed code segment on Layer 1 and comparing the results.

Arbitrum

In Arbitrum, executing is handled separately from proving. Execution is done off-chain in Arbitrum, and proving doesn’t require the re-execution of the disputed code on Layer 1. The reason for this is apparent from its documentation:

Execution is optimized for speed in a local, trusted environment because local execution is the common case. On the other hand, proving will be needed less often but must still be efficient enough to be viable even on the busy Ethereum L1 chain. Proof-checking will rarely be required, but proving must always be possible.

Proving in Arbitrum is an off-chain process, featuring multi-round fraud proofs. For example, Alice and Bob disagree on the execution of the transaction. This results in a binary search of a disputed part of the execution until they disagree about a single step of the execution. Alice sends the N-step claim to Bob, and Bob breaks down the claim in half. He then picks one half, and breaks down the new claim in half again. This process continues, halving the disputed execution at each stage.

When the smallest single-step execution dispute is finally found, only then does the Layer 1 arbitrator resolve the dispute. All of the computation for this arbitration process is done off-chain to be gas-efficient. Only the actual resolution of the dispute (with economic consequence) is done on-chain.

If you want to learn more about the Arbitrum and how it works under the hood, you can check out the official docs.

Optimism Ethereum

Optimism’s approach is different from the one we explored earlier. Here, executing and proving are done together.

If there were a dispute between Alice and Bob, the transaction in question would be re-executed (replayed) on the L1 chain. But this introduces some potential issues, as we cannot rely on certain OPCODES to return the same value on the L1 chain and the L2 chain. Certain ones like BLOCKNUMBER, for example, wouldn’t produce the same value as certain opcodes rely on system-wide parameters.

The solution to this is introducing a mechanism that would help retain the context of the disputed transaction between L1 and L2. Optimism Virtual Machine replaces all context-dependent OPCODES with its counterparts like ovmBLOCKNUMBER.

As Georgios Konstantopoulos explains in the following example:

A L2 transaction calls the TIMESTAMP opcode, returning e.g. 1610889676

An hour later, the transaction (for any reason) has to be replayed on Ethereum L1 during a dispute

If that transaction were to be executed normally in the EVM, the TIMESTAMP opcode would return 1610889676 + 3600. We don’t want that!

In the OVM, the TIMESTAMP opcode is replaced with ovmTIMESTAMP which would show the correct value, at the time the transaction was executed on L2

There are lots of interesting design decisions that are made in Optimism. We recommend checking the following article, which goes deeper into some of these choices.

STARKNet, Aztec Network, LoopRing, and zkSYNC

Also worthy of a mention are the scaling solutions relying on zk-rollups instead of optimistic rollups.

STARKNet’s alpha is expected to launch sometime in November. There isn’t much yet to discuss here as the network is still under development, but if you want to learn more, please check their announcement linked here.

Loopring, which originally launched in 2019, also uses zk-rollups, and claims to be the first to do so. They have a mobile Ethereum wallet that runs on their L2 solution, as well as an L2 orderbook and AMM DEX.

AztecNetwork, another zk-rollup scaling solution, is currently live on the Goerli testnet. Aztec uses zkSNARK proofs to provide privacy while scaling with their zkRollup service. More info is available here.

Last but not least, zkSYNC is another scaling solution utilizing zk-rollups, and their network is currently live on mainnet as well as testnet. More info can be found here.

Polygon

Polygon is also notable, as it differs from the previous scaling solutions as it is a sidechain, not a rollup.

A sidechain is a separate blockchain from Etheruem, but at its core still uses EVM as an execution engine. This means all the smart contracts deployed on Ethereum can work exactly the same on the sidechain. To communicate, there are two-way bridges allowing for a transfer of assets between the networks.

The main difference is in the consensus algorithm used by the two networks. Often Proof of Authority, Proof of Stake, or Delegated Proof of Stake are used as the consensus mechanism. This allows for higher transaction throughput, lower gas fees, and shorter time to finality, all while still using the same underlying logic of the EVM. The main downside is that the network is more centralized, as not everybody can be included with two of the three methods listed: PoA or DPoS.

For transaction validation, Polygon relies on a set of validators that run their Proof of Stake nodes. These validators act as their operators to secure the network, run a full node, produce blocks, validate them, and participate in consensus and commit checkpoints on the Ethereum mainnet. One can only become a validator by staking the required MATIC tokens on an Ethereum smart contract.

As always, if you want to learn more about Polygon and how it works, we recommend checking official documentation here, or by checking the YouTube video from Finematics:

Summary

It would be impossible to completely cover what each of these scaling solutions offer in a single article. Instead, we showcased the more interesting ones and explained rollups. This serves as more of an introduction to a deeper and more interesting topic which is Zero-Knowledge Proofs.

Look forward to our upcoming article, where we will dive deeper into zk-proofs, as well as an explanation of how they work. Scaling solutions are often very much a blend of creativity and wizardry, and well worth knowing and understanding even for the average user.