In this article I want to tell about current state of Ethereum scaling, demystify some of false points about rollup-centric Ethereum and explain how to navigate in all of this if you’re a developer or just interested in this topic.

To my surprise, there are no guides of Ethereum scaling angle for developers. Yeah, you can find articles that explain what is a rollup, what are their differences, how to develop on rollups, etc. But all this looks like building on top of another chains and pretty much nothing related to what all these rollups have to do with Ethereum ecosystem and how to build your projects if you want to get the most out of Ethereum while reaching maximum scaling.

It’s expected that you have knowledge of how Ethereum works and all sharding/rollups explanations here are of a reminder nature.

What is scaling

We can define scaling as increasing blockchain network throughput without increasing node requirements, that is, how powerful PC you need to run a client of your network. Ethereum philosophy says that for the actual decentralised network, node requirements must stay at the level of consumer PCs. For example, full node takes slightly more than 1 TB of storage and such SSD can be found for ~100$. All other requirements are approximately at the level of Pi4 microcomputer.

From this fact it’s logical to assume that Ethereum network throughput is quite low. That’s right - it usually processes 12-15 transactions per second. We can’t calculate exact throughput in transactions per second, but if we assume that all transactions are ERC20 tokens transfers, we’ll have a number of 20 TPS.

Is it much? Well, if we take 100M users, it’s 0.017 transactions per day for one user or one transaction per 58 days. Obviously, this is not enough, not to mention all 8 billion people on the planet. To onboard 100M users each making 3 transactions per day, Ethereum network must process ~3472 TPS.

How’s it possible? That’s the task that Ethereum community was trying to solve for years. Previously we were working on sharding.

What is sharding

Sharding is a mechanism that splits the network into many interoperable chains, all of which are proven and coordinated by some central chain.

All of these chains should have been operated by validators distributed into small sections called committees. This system was expected to be released on Ethereum 2.0 upgrade, but it was abandoned in favor of rollups.

Rollups

Many people think that rollups are complicated, but in fact they’re even simpler than sharding mechanism. Rollups are independent blockchains whose validity is verified by the Ethereum blockchain. They’re often called Layer 2 because they in fact stay on top of Ethereum which acts as a Layer 1. How do they prove their validity? There are two basic methods.

ZK Rollups

Group of transactions is executed and bundled in the single structure called batch and sent to the Ethereum blockchain. Then, sequencer or group of sequencers generate a ZK proof of this transaction set’s validity and send this proof to the smart contract on Ethereum L1. Smart contracts executes (validates) this proof, and if it’s valid, then transactions it belongs to are valid by definition.

What is ZK proof? Well, my explanation will not be exhaustive at all, because it entirely sounds as a magic and to understand how it works internally, you should have strong knowledge in cryptography. ZK (Zero-Knowledge) proof is a set of mathematical equations that allow you to prove outputs of some computations without executing these computations yourself, either because they’re too hard for you to execute or because you don’t have some of necessary values to execute it.

In this case, we have a batch of X transactions. They all produce changes in the current network (L2 one) state. Sequencer generates ZK proof that states that if you execute all these transactions, they will all be valid and will produce required changes in the state (transfer some ETH, changing storage in some smart contract, etc).

ZK proof is crazy difficult to generate (it requires lots of GPU computations and some time), but extremely easy (compared to what computations it proves) to validate. That’s why they’re used here - we can execute all hard work off chain, and keep remaining easy work (proof execution) on chain. This way, we keep Ethereum network unloaded, but remain its security guarantees.

Optimistic rollups

ZK cryptography is really young, and when rollup scaling was just adopted, it was too undeveloped to actually prove EVM computations. Because of this, optimistic rollups were invented first.

The point of optimistic rollups is that they assume that loaded batch is valid by default, until some of rollup operators won’t prove the opposite. If some batch appears to be invalid (e.g it has a transaction that double-spent ETH), an operator sends a fault proof to L1 and if it’s valid, rollup’s smart contract on L1 reorgs the chain to remove invalid data. Fault proof is a message that asserts that some transaction inside the batch is invalid.

Among advantages, it’s lightweight. No one has to execute any hard computations and as long as one honest operator exists, the chain is safe.

However, its serious disadvantage is challenge time. In ZK rollups, batch is safe as soon as someone provides a ZK proof to it. In modern ZK rollups, it takes from 15 minutes to an hour and constantly improves. In optimistic rollups, batch is considered safe when no one has provided a fault proof to it in a certain period, which is called challenge time. Usually it’s 7 days and it can’t be lower than few hours because then it becomes possible to attack the chain.

Batch finalisation is a crucial requirement for rollup interoperability. L2→L1 messages are executed only after they’re finalised and safe. Rollup can’t effectively communicate with other rollups if its messages are delayed by 7 days each.

Here we go to the main part of article.

“Rollups are not Ethereum”

This really common point may seem fair, because unlike shard chains, which are interoperable and thus share the same liquidity, dApps, etc, rollups live completely on their own as entirely separate blockchains, and the only thing that they share is security.

However, I’d say that this is partially made by us. We’re not used to new rollup world and trying to build our projects just as we were doing it in alt-L1 era.

Here I’ll share some principles that you should follow as a developer to build efficient apps that are ready for cross-rollup interaction.

1) Be a ZK rollup maximalist

While choosing a rollup to build on, you may choose Arbitrum and Optimism for the single reason - they’re popular and already have many users, so it’ll be simpler to attract people. Now you’re trapped in the chicken-egg problem.

Arbitrum and Optimism are the most popular because they were first and attracted first people, which attracted first dApps, which attracted new people, which… you know what’s next. Arbitrum and Optimism are both optimistic rollups with 7 day challenge time, it means that they won’t effectively communicate with people on other rollups in the near future.

Ok, what’s wrong in only using these two and not using anything else? - In short, centralisation risks and stack limitations. Your project may require built-in account abstraction, general purpose languages, fast communication with L1, and other things that exist on other rollups, but not on Arbitrum and Optimism.

ZK rollup ecosystem is developing really actively. Most of them already have <=30 minutes finality. This means that no matter which ZK rollup you’ll take, as long as it’s ZK rollup, it is fast in finality and it will be even faster when technology improves.

This might all seem like a rude or biased statement, so I’ll clarify. Optimistic rollups have a right to exist, but ZK rollups are more modern in many ways and if you look for a rollup to build on, take a closer look at the rollups, even if they’re not so popular. You will not regret in the future.

2) Choose a rollup based on your needs

One non-obvious advantage of rollups over shard chains is that rollups are developed independently by various groups based on different paradigms and principles. All rollups are not alike - different zkVM/zkEVM types, account systems, proof systems, gas prices. They’re all different so that you, as a developer, can choose the one you need for your project.

If you want an experience close to Ethereum - use Scroll or Linea.
If you want an experience too close to Ethereum - use Taiko, it will cost you higher fees.
If your project is expected to execute many changes of same state elements - use zkSync, its state diff-based proof system lets you pay once for multiple state element changes. It also has built in account abstraction that you may need as well.

If you want to use WASM - use Fluent.
If you want to use Solana VM - use Eclipse.
If you want to build a private dApp - use Polygon Miden or Aztec.

There are many different systems with different features and drawbacks, and it’s worth exploring many options to choose the one that suits you best.

3) Application-specific Rollups or “RollApps”

If you feel that your project is going to be big, or you’re already the big project on Ethereum L1, it’s worth taking a look at rolling out your own rollup.

The huge advantage of this approach is that you can deal with the load yourself and you don’t have risks related to staying on general purpose rollups. Also, if your project is used really frequently, the rollup you stay on can overload and proof generation will significantly slow down, while on your own rollup you can set up sequencer rigs yourself. Users from all rollups can enjoy the same liquidity and prices, which isn’t possible when project is deployed on many chains raw.

You can make it open for everyone or restrict to your project, use EVM, SVM or no VM at all, possibilities are unrestricted. Whatever you implement, you still seriously reduce fees for users.

However, it leads to many difficulties. In particular, you have to develop and control your own chain, which is quite complex and expensive, even using existing stacks (ZK Stack, Polygon zkEVM Stack, etc). Also, you’ll probably have to make a web interface with built-in bridging to your rollup.

Generally, this approach isn’t for everyone, but for huge projects such as Uniswap, AAVE, Curve, that’s probably the best option.

4) Token-based projects

If you’re an RWA project, let’s say stablecoin, or liquid staking provider, consider not using rollups at all. If your project has a token for governance or utility purposes, deploy the token on L1. Why?

The main reason is that it’s way easier for cross-rollup transfer solutions to transfer tokens that only exist in the form of bridged L1 assets. All rollups have built-in ERC20 and ERC721 bridges, and the first liquidity that rollups gets after its launch is inherited liquidity from ERC20 tokens on L1. Mostly it’s stablecoins and liquid staking tokens.

You can always move a token to L2 if it’s deployed on L1, but not vice versa. For example, that’s the reason why native USDC on Arbitrum is still not really used compared to the natively bridged USDC.e that is also redeemed from the most bridges for the same reason. Natively deployed assets break inter-rollup supply chains by making it impossible to reorganise funds through common L1 by unbridging-bridging.

Same goes for RWAs and NFTs. You probably want your NFTs to be traded and transferred between different users on different rollups, and for these tasks it’s worth deploying on L1.

5) On cross-rollup protocols

It’s worth noting that currently no cross-rollup protocols were developed, it means that all wallets are tied to their chain and can’t use apps from another chains out of the box. Of course, such protocols will start releasing in the near future, but if you want to attract users from another rollups right now, you’ll have to implement algorithm of cross-rollup interaction with your project yourself.

I can note that such system can be built using L2→L1 and L1→L2 messages that exist in all rollups. You can use optimistic-style communication or transmit messages off-chain, the logic is on your side. However, I wouldn’t recommend using protocols that work on their own consensus such as Chainlink or LayerZero, because then you not only accept the risk of failure of Ethereum consensus, but also of the cross chain protocol.

Summary

We can summarise rules for building on rollup-centric Ethereum like this:

• Consider using ZK rollups for your project

• Choose a rollup based on your needs and not TVL or users

• If you’re a big project, consider running your own rollup

• Do not deploy to L2 tokens that you expect to be used outside this L2

• Use L1-L2 communication possibilities to unlock cross-rollup interaction

By following these rules we are paving the way to the interconnected, interoperable Ethereum future, and the solidity of Ethereum ecosystem is the key to the user experience and mass adoption.

Thanks for reading.