Overview

Since the launch of Ethereum in July 2015, and after the network started seeing considerable network effects, the focus of the Ethereum community and other core developers around the world shifted to scaling.

But what is Scaling?

As transactions on Ethereum, the global supercomputer rise, users send out txns with higher gas fees in order to have them prioritized first. This leads to limited block space quickly filling up, resulting in ‘gas wars’ that make it expensive and slow to transact on this global computer.

Scaling so far

Researchers have come up with many interesting ways to alleviate this problem with approaches like Plasma generating a lot of interest in 2017. Today zk Rollups, Optimistic Rollups, side-chains and solutions like Polygon’s commit-chain are bringing tremendous scale to Dapps and enabling experiences not possible a few years ago.

What’s the best one?

There are a lot of factors to evaluate when it comes to evaluating a scaling solution, it also depends on your perspective: are you a user or a developer? In this piece, we’ll try to look at how developers can choose the best scaling solution to fit their requirements.

The Ethereum Scaling Framework

We aim to look at the problem of scaling from the eyes of a developer: what factors should you consider while picking a scaling solution?

From a developer or Dapp’s perspective, we can look at scaling from four different perspectives: Ease of Development, Security, User Experience, and Long Term Feasibility.

1. Ease of Development

A big facet of how developers choose a solution is how easy it is to build on top of it. This includes factors like the programming environment and compatibility with existing tooling and infrastructure.

For instance, a commit-chain like Polygon offers 100% EVM compatibility, which means the same code used on Ethereum can be deployed on Polygon without any changes to the code. This also means that all the existing tooling and infrastructure on Ethereum is compatible out of the box with Polygon.

On the other hand, the entry barrier for a ZK Rollups dev would be much higher due to changes required in the code and a lack of a comprehensive tooling infrastructure.

2. Security Level

Depending on the purpose of your project, the security required for the on-chain functions may vary. For eg., a DeFi protocol may have billions of dollars locked in its contracts.

In such cases, zk and Optimistic Rollups would provide higher security.

3. User Experience

The experience of the end-user that uses the Dapp is another important point for a developer to consider. Factors like what operations are natively supported and the confirmation times associated with a transaction will determine the end-user experience while using Dapps.

An NFT or Gaming Dapp will potentially have lower stakes in their on-chain contracts, which means a side-chain/commit-chain like solution would fit better with medium security, but a better UX thanks to faster withdrawals.

4. Long Term Feasibility

Another criterion to look at should be the long term feasibility of the solution. Will the solution be able to scale when mass user adoption picks up?

Eg. If we look at a ZKR based Dapp that does huge transaction volume, how will the required proofs be generated? Even with parallelism and recursive proofs, the developer would need to have a concrete model on how parallel threads communicate, how jobs are divided, etc. to truly scale. Any computational scaling solution will also need to think about how to handle storage. High txn volume results in huge amounts of data which will ultimately need to be stored on Ethereum or a similar data availability layer.

Ultimately, it is important a developer always makes this choice keeping the end-user in mind, is the user looking for security, ease of use or a balance of both?

In the near future, we expect to see smooth transitions of Dapps between multiple scaling options as per requirements, with developments and toolkits like the Polygon SDK. The problems with data storage on Ethereum will also be eased with distributed data availability layers like Avail and Celestia.