Profile picture of Matt Zand Hacker Noon

@mattzandMatt Zand

As author of the book Hyperledger Fabric by O’Reilly Media, Matt has contributed to IBM, SAP, Alibaba, Linux Foundation, etc.

As you may know, there are differences between horizontal and vertical scaling in distributed systems, which we covered in another article (Scaling horizontally vs. vertical scale in distributed systems). So, in this article, we take the next step by learning how to scale Ethereum blockchain applications.

We’ll also go over different scaling solutions for Ethereum blockchain applications. To follow and understand the concepts discussed in this article, we assume that you have a basic understanding of blockchain technology and Ethereum.

Scaling Ethereum

Like Bitcoin, the main reason for Ethereum’s scalability problem is the network protocol that every node in the network has to process every transaction. Ethereum 1.x implements a slightly modified version of the Proof-of-Work (PoW) consensus mechanism.

In Ethereum, miners must race to find the nonce to reach the target difficulty. Each node must verify that the miners’ work is valid and keep an accurate copy of the current state of the network. This severely limits the capacity of the transaction process and the throughput of the Ethereum blockchain network. Currently, it can only process 12 to 15 transactions per second.

Blockchain scalability trilemma

First used by Vitalik Buterin, Scalability Trilemma is a blockchain concept regarding its ability to handle scalability, decentralization, and security, without compromising any of them. The trilemma claims that it is nearly impossible to achieve all three properties in a blockchain system:

  • Decentralization: This is a fundamental principle upon which Bitcoin and the blockchain were created. Decentralization allows resistance to censorship and allows anyone to participate in a decentralized ecosystem without central authority or intermediary.
  • Security: It’s about the integrity and immutability of the public ledger, and the ability to resist 51% of DDoS network attacks.
  • Scalability: This is the ability to manage an increasing number of transactions in the blockchain network. For the Ethereum blockchain to be the world computer as the inventor imagined it, it must match the transaction rate of many centralized systems, such as Amazon, Visa or Mastercard.

The main scalability challenge is finding a way to achieve all three at the base layer level. Bitcoin and Ethereum’s design choices prioritize decentralization and security while making a sacrifice in scalability.

Solutions for scaling Ethereum applications

The Ethereum scalability solution is one of the most active topics in the Ethereum community. Here are some areas of concern that the community is trying to address:

  • Transaction in progress and block creation time with PoW: how fast can miners process all transactions and create a new block through mining?
  • Purpose of the transaction – how long can the decentralized network reach a consensus that a transaction has taken place and that it cannot be rolled back? Currently, it takes around six blocks in Bitcoin and 3-4 minutes in Ethereum for the network to consider a block as finalized in the mainchain.

The solutions implemented or proposed fall into three categories: on-chain solutions, off-chain solutions and consensus mechanism protocols. There are some obvious or theoretical ones, like increasing the size of blocks or splitting a blockchain into several independent altcoin chains. Due to the nature of peer-to-peer, a traditional horizontal scaling approach may not work.

Specific to the Ethereum network, some attention has also been paid to stateful and stateless smart contracts contributing to scalability issues. We’ll go over the high-level concepts behind all of these solutions, and then dig deeper into some of the most promising.

Block size

This is similar to the vertical scaling approach. Some of the altcoins, like Bitcoin Cash, Ethereum Core, etc., implement a larger block size to improve the overall performance of transactions. The theory behind this approach is that since PoW mining is the main bottleneck in the whole process, by increasing the block size, we can process more transactions per mining. It may take a little longer to create a directed acyclic graph (DAG) for stash-based mining, but the average time to complete mining may not get worse, as most Ethereum clients put the DAG on anyway. hidden.

However, like vertical scaling, in general, this solution requires the nodes in the network to have better compute capacity in order to handle large blocks. This can lead to a scenario where a network is concentrated in a few wealthy hands and, thus, can ultimately compromise decentralization and security, the main tenets of blockchain.


Another solution is not to have a gigantic blockchain, but to have many smaller blockchains and altcoins. This may possibly be the case since many vertical industries are creating or planning to create industry specific chains. This will reduce user activity on each individual blockchain and, therefore, should allow for a more scalable ecosystem.

However, there are some issues with this option. One concerns security issues. It is commonly believed that the network is more secure if more nodes in the network participate in the processing of transactions in the blockchain. With the wider distribution of altcoin chains, fewer nodes will operate on a given blockchain. This can make the blockchain less secure, as a smaller altcoin network can be more vulnerable to network attacks. Let’s say we have about 10,000 nodes on the largest network, it will take at least 5,001 nodes (or called 51%) to be compromised to launch an attack on the network. If we split 10,000 nodes into 50 smaller chains, each chain has 200 nodes, and it only takes 101 nodes to eliminate a smaller chain, which we call a 1% attack problem.

Another problem is cross-chain integration. While there are solutions to handle cross-blockchain integration, the overall complexity of integrating smaller chains and altcoins will increase dramatically.

Chain solutions

On-chain solutions, sometimes also referred to as Layer 1 solutions, should seek solutions to address scalability and performance issues at the base layer level of the Ethereum blockchain network. One of these solutions is sharding. Sharding is not a new concept, as traditional RDBMS and newer big data platforms have used sharding as a means to improve scalability and performance for many years.

With the Ethereum network, the purpose of sharding is to group the network nodes, blockchain, and global states into different shards, and each shard will reach a consensus on the shard-wide transaction state among those nodes. within the group. Conceptually, it may not be much different from Plasma, the Layer 2 side chain approach, but the technical difficulty, implications, and network efforts are quite different. We’ll go into sharding details in the Ethereum and Casper sharding article.

Another Layer 1 or on-chain solution is the move to a Proof of Stake (PoS) consensus mechanism, which is one of the most active areas of research dealing with scalability and performance issues in Ethereum. There are many debates in terms of the pros and cons of a PoW-based consensus mechanism. It is quite efficient in securing the blockchain in the decentralized network, but it is also a major bottleneck in the performance of the blockchain.

Off-chain solutions

Similar to the rationale for an on-chain solution, the Ethereum community is also actively looking for off-chain solutions, sometimes referred to as Layer 2 solutions. One is a side chain solution with Plasma. Instead of putting all transactions in the main chain, Plasma allows anyone to create sidechains and link sidechains in the global blockchain. This is similar to the lighting network solution in Bitcoin.

Another solution is a state channel solution with Raiden, similar to Bitcoin payment channels. The assumption behind this approach is that many transactions between parties only need to be validated by the parties involved, and that it is not necessary that all transactions be validated by the whole party. network. Along with off-chain solutions, the choice of cloud provider and your API architecture for communications between on and off data exchange plays an important role in the scalability and availability of your blockchain application.

For example, Hyperledger has a powerful library called Hyperledger Avalon that allows developers to safely move most heavy transactions on-chain to off-chain processing machines. A good understanding of on-and-off chain solutions is essential for doing blockchain consulting and development.


One of the limitations of Bitcoin is the privacy issue. Zcash is the first and perhaps the most popular cryptocurrency to implement a succinct, non-interactive knowledge argument to zero knowledge, or abbreviated as ZK-SNARK, as a means of solving privacy concerns in the public blockchain.

It maintains strong confidentiality by allowing the transaction to be fully encrypted on the blockchain, and encrypted transactions can still be verified as valid with ZK-SNARK proofs. Under the ZK-SNARK consensus rules, one, as prover, can let others, as verifiers, know that he has certain knowledge without revealing specific knowledge and without any interaction between them.

The Ethereum community is also integrating ZK-SNARK into the Ethereum blockchain implementation, with the intention of using ZK-SNARK to mass validate transactions, greatly improving Ethereum’s scalability.


In this article, we have discussed the challenges of scaling an Ethereum blockchain application as well as reviewing 5 practical solutions such as block size, on-chain and off-chain solutions.

This article is written by Matt Zand (lead author of the book “Hands-On Smart Contract Development with Hyperledger Fabric V2” by O’Reilly Media) in collaboration with Brian Wu who is a lead author of “Learn Ethereum: Build Your own decentralized applications with Ethereum and smart contracts ”.

Parts of this article are also published on:

Profile picture of Matt Zand Hacker Noon
through Matt Zand @mattzand. As author of the book Hyperledger Fabric by O’Reilly Media, Matt has contributed to IBM, SAP, Alibaba, Linux Foundation, etc.
Read my stories

Key words

Join Hacker Midi

Create your free account to unlock your personalized reading experience.