Ethereum scaling has been at the heart of concerns for several months, and among the different scaling techniques (sidechains, state channels, plasma, etc.) one seems to stand out: rollups

In this article, we will try to simplify this solution, which is in my eyes the most promising.

Key Terms:

Layer 1: a term used to define the basic network layer of a blockchain (such as Ethereum for example).

Layer 1 is qualified today as "monolithic" because the 3 main functions of a blockchain are grouped on the same layer:

• Consensus: how the nodes in the network agree on which transactions take place and in what order.

• Execution: the processing of these transactions (determining which ones are valid and their impact on the state of the network).

• Data availability: how transactions data are made available to nodes for download.

This approach is becoming outdated and more modular architecture is essential for scaling up.

Layer 2: “secondary” blockchain built on top of Layer 1. In the case of Ethereum, Layer 2 will help it scale by handling transaction execution while benefiting from the security of Layer 1.

Sidechains like Polygon differ from Layer 2 because they have their consensus and therefore their security, and will provide a bridge between their sidechain and the associated layer.

State: consider the state of a blockchain as a snapshot at a given moment of its database. In this database, you can find the accounts balance, smart contracts code, smart contracts internal memory, etc.

The state of the EVM (Ethereum Virtual Machine) will transition from one block to another.

Merkle tree: a data structure that concatenates the hash of a set of transactions until a unique hash is obtained, the Merkle root. The Merkle root is a kind of concise summary of all the transactions hashes.

In the case of Ethereum, it can be seen as the fingerprint of the blockchain's state.

I will talk about state verification in this article but understand that a state verification is Merkle’s root check, attesting to the current state of the blockchain.

There are different types of rollups, but the basic principle remains the same. A smart contract will be deployed on the L1 (Ethereum in this case) and will have two tasks: process deposits and withdrawals and check the proof that everything on the Layer 2 follows the established rules.

In other words, the role of the smart contract is to maintain the blockchain state.

The rollup will be in charge of the transaction’s computation, and if we want to be more precise, we will say that it moves the computation and the storage of the EVM state.

Once the transactions are executed, transaction data will be compressed and sent as a batch to the smart contract located on Ethereum.

The smart contract will then check the validity of the batch (it validates or not the state transition).

One can legitimately ask how Ethereum ensures that the posted data are valid and not sent by a malicious actor?

Two different approaches have emerged: Optimistic rollups and ZK-rollups.

Several parties will be involved in such a scheme.

The first part is the aggregator. An aggregator collects transactions on Layer 2 and compresses them into a batch before sending them to the smart contract located on Ethereum.

To be more precise, the transactions batch sent contains a Merkle root representing the rollup state.

Any user can be an aggregator if he has enough capital to deposit a bond (a kind of deposit often in eth) stored on the smart contract.

The second part is the one that will observe the transaction execution process on Layer 2.

During a 7-day dispute period, any user will be able to submit a fraud proof accusing the aggregator of submitting an invalid transaction batch (i.e., submitting a batch containing an invalid Merkle root).

Optimistic rollups are considered optimistic because we assume that the aggregator is honest. We will therefore trust him for about seven days and consider that the new state of the EVM is the one that he advances.

If no one submits a valid fraud proof for seven days, the transactions are finalized and the state transition is applied by the smart contract.

If a user submits a valid fraud proof, the transactions that took place during seven days are rolled back and the state returns to its last valid state.

A rollback means that all blocks produced during these seven days are considered orphaned and are abandoned.

A valid fraud proof implies that a part of the bond filed by the aggregator is burned while the other part rewards the user who submitted the proof of fraud.

If you are not familiar with Zero-Knowledge technology, my first article may be a good introduction.

Instead of relying on optimistic logic and using fraud proofs, ZK-rollups use validity proofs to prove that the transactions were executed with integrity.

Each transaction batch has cryptographic proof of its validity.  This proof proves that the post-state Merkle root is the correct result of the batch execution.

It is then sent to the smart contract on Ethereum which will check it mathematically and proceed with the state transition.

Transaction batches with valid proof are quickly verified, while invalid batches are immediately rejected.

In ZK-rollups, only a prover with a lot of computing power will generate the proofs that can then be verified by any user.

The first difference between ORs and ZK-rollups is that ZK-rollups do not require 7 days to finalize transactions, because user funds are available as soon as the transaction batch and proof of validity are submitted to Ethereum.

This period is very restrictive for ORs users because their transactions take the risk of being on a blockchain that may be rollback at the end of the dispute period (which has already happened in early 2022).

Fortunately, DEXs such as HOP offers liquidity pools where atomic swaps can reduce these 7 days for a fee (only works for ERC-20 tokens).

The second difference is in the way that ORs and ZKRs are implemented, architecturally speaking.

The complexity of ZK-proofs makes EVM compatibility difficult, forcing DApps to rewrite their application logic to accommodate rollups.

The applications that are built-in Starknet environment with smart contracts written in Cairo are a good example.

ORs have lower technological complexity, allowing them to run their own EVM version where almost all smart contracts will be deployable without code rewriting.

The third difference concerns the processing of data during the transaction’s computation on the L2.

ORs consider that all data should be on-chain on Ethereum, while a "sorting" of data will be done in the context of ZK-rollups.

We will extract the data that are not necessary to update the state, and we will compress those that are before sending them to the smart contract.

In such a scheme a hierarchy of data is made, considering that some data are less important than others and therefore do not deserve the same security.

Data considered less relevant can be temporary data such as oracle price, time limiter, etc.

Some projects like StarkWare are already thinking about building other layers to distribute the different activities according to their security needs. We could then have DeFi applications that are executed on a different layer than gaming applications.

The fourth difference is the scaling enabled by these solutions.

The gas cost per transaction batch is more expensive with ZK-rollups because proof checking is computationally intensive.

However, the cost per transaction is more expensive on Ethereum with ORs because, as explained earlier, all data transactions must be published.

Fewer data contained in each batch means higher throughput and therefore greater scalability for ZK-rollups.

There seems to be a consensus within the Ethereum community that ORs will be more effective in short-term scaling due to their ease of implementation.

On the other hand, once ZK proofs are more technologically mature with more developed ecosystems, ZK-rollups will out in the long run because they provide more security, have higher scalability limits, and are faster than ORs.

Scaling Ethereum is not easy, but rollups seem to be the hoped-for solution.

Whether Optimistic rollups or ZK-rollups, both approaches have the common goal of universalizing the use of Ethereum and making it more accessible.

And beyond being extensions of Ethereum, rollups could push the boundaries of the Ethereum Virtual Machine and open the door to innovative applications.

Ethereum scaling has been at the heart of concerns for several months, and among the different scaling techniques (sidechains, state channels, plasma, etc.) one seems to stand out: rollups

In this article, we will try to simplify this solution, which is in my eyes the most promising.

Key Terms:

Layer 1: a term used to define the basic network layer of a blockchain (such as Ethereum for example).

Layer 1 is qualified today as "monolithic" because the 3 main functions of a blockchain are grouped on the same layer:

• Consensus: how the nodes in the network agree on which transactions take place and in what order.

• Execution: the processing of these transactions (determining which ones are valid and their impact on the state of the network).

• Data availability: how transactions data are made available to nodes for download.

This approach is becoming outdated and more modular architecture is essential for scaling up.

Layer 2: “secondary” blockchain built on top of Layer 1. In the case of Ethereum, Layer 2 will help it scale by handling transaction execution while benefiting from the security of Layer 1.

Sidechains like Polygon differ from Layer 2 because they have their consensus and therefore their security, and will provide a bridge between their sidechain and the associated layer.

State: consider the state of a blockchain as a snapshot at a given moment of its database. In this database, you can find the accounts balance, smart contracts code, smart contracts internal memory, etc.

The state of the EVM (Ethereum Virtual Machine) will transition from one block to another.

Merkle tree: a data structure that concatenates the hash of a set of transactions until a unique hash is obtained, the Merkle root. The Merkle root is a kind of concise summary of all the transactions hashes.

In the case of Ethereum, it can be seen as the fingerprint of the blockchain's state.

I will talk about state verification in this article but understand that a state verification is Merkle’s root check, attesting to the current state of the blockchain.

There are different types of rollups, but the basic principle remains the same. A smart contract will be deployed on the L1 (Ethereum in this case) and will have two tasks: process deposits and withdrawals and check the proof that everything on the Layer 2 follows the established rules.

In other words, the role of the smart contract is to maintain the blockchain state.

The rollup will be in charge of the transaction’s computation, and if we want to be more precise, we will say that it moves the computation and the storage of the EVM state.

Once the transactions are executed, transaction data will be compressed and sent as a batch to the smart contract located on Ethereum.

The smart contract will then check the validity of the batch (it validates or not the state transition).

One can legitimately ask how Ethereum ensures that the posted data are valid and not sent by a malicious actor?

Two different approaches have emerged: Optimistic rollups and ZK-rollups.

Several parties will be involved in such a scheme.

The first part is the aggregator. An aggregator collects transactions on Layer 2 and compresses them into a batch before sending them to the smart contract located on Ethereum.

To be more precise, the transactions batch sent contains a Merkle root representing the rollup state.

Any user can be an aggregator if he has enough capital to deposit a bond (a kind of deposit often in eth) stored on the smart contract.

The second part is the one that will observe the transaction execution process on Layer 2.

During a 7-day dispute period, any user will be able to submit a fraud proof accusing the aggregator of submitting an invalid transaction batch (i.e., submitting a batch containing an invalid Merkle root).

Optimistic rollups are considered optimistic because we assume that the aggregator is honest. We will therefore trust him for about seven days and consider that the new state of the EVM is the one that he advances.

If no one submits a valid fraud proof for seven days, the transactions are finalized and the state transition is applied by the smart contract.

If a user submits a valid fraud proof, the transactions that took place during seven days are rolled back and the state returns to its last valid state.

A rollback means that all blocks produced during these seven days are considered orphaned and are abandoned.

A valid fraud proof implies that a part of the bond filed by the aggregator is burned while the other part rewards the user who submitted the proof of fraud.

If you are not familiar with Zero-Knowledge technology, my first article may be a good introduction.

Instead of relying on optimistic logic and using fraud proofs, ZK-rollups use validity proofs to prove that the transactions were executed with integrity.

Each transaction batch has cryptographic proof of its validity.  This proof proves that the post-state Merkle root is the correct result of the batch execution.

It is then sent to the smart contract on Ethereum which will check it mathematically and proceed with the state transition.

Transaction batches with valid proof are quickly verified, while invalid batches are immediately rejected.

In ZK-rollups, only a prover with a lot of computing power will generate the proofs that can then be verified by any user.

The first difference between ORs and ZK-rollups is that ZK-rollups do not require 7 days to finalize transactions, because user funds are available as soon as the transaction batch and proof of validity are submitted to Ethereum.

This period is very restrictive for ORs users because their transactions take the risk of being on a blockchain that may be rollback at the end of the dispute period (which has already happened in early 2022).

Fortunately, DEXs such as HOP offers liquidity pools where atomic swaps can reduce these 7 days for a fee (only works for ERC-20 tokens).

The second difference is in the way that ORs and ZKRs are implemented, architecturally speaking.

The complexity of ZK-proofs makes EVM compatibility difficult, forcing DApps to rewrite their application logic to accommodate rollups.

The applications that are built-in Starknet environment with smart contracts written in Cairo are a good example.

ORs have lower technological complexity, allowing them to run their own EVM version where almost all smart contracts will be deployable without code rewriting.

The third difference concerns the processing of data during the transaction’s computation on the L2.

ORs consider that all data should be on-chain on Ethereum, while a "sorting" of data will be done in the context of ZK-rollups.

We will extract the data that are not necessary to update the state, and we will compress those that are before sending them to the smart contract.

In such a scheme a hierarchy of data is made, considering that some data are less important than others and therefore do not deserve the same security.

Data considered less relevant can be temporary data such as oracle price, time limiter, etc.

Some projects like StarkWare are already thinking about building other layers to distribute the different activities according to their security needs. We could then have DeFi applications that are executed on a different layer than gaming applications.

The fourth difference is the scaling enabled by these solutions.

The gas cost per transaction batch is more expensive with ZK-rollups because proof checking is computationally intensive.

However, the cost per transaction is more expensive on Ethereum with ORs because, as explained earlier, all data transactions must be published.

Fewer data contained in each batch means higher throughput and therefore greater scalability for ZK-rollups.

There seems to be a consensus within the Ethereum community that ORs will be more effective in short-term scaling due to their ease of implementation.

On the other hand, once ZK proofs are more technologically mature with more developed ecosystems, ZK-rollups will out in the long run because they provide more security, have higher scalability limits, and are faster than ORs.

Scaling Ethereum is not easy, but rollups seem to be the hoped-for solution.

Whether Optimistic rollups or ZK-rollups, both approaches have the common goal of universalizing the use of Ethereum and making it more accessible.

And beyond being extensions of Ethereum, rollups could push the boundaries of the Ethereum Virtual Machine and open the door to innovative applications.