Ethereum: Too complex to scale?
Can Ethereum scale beyond Bitcoin? How does the network manage high transactions numbers? How are smart-contracts burdening the network? What are the implications for blockchain Dapp developers? In this blog post, we will dive into Ethereum’s scalability challenges.
The complexity of smart contracts can lead to large amounts of computation that the Ethereum network needs to handle. In order to limit the total amount of computation done and to provide incentives for miners, Ethereum uses a gas system.
In this system any transaction that is sent costs some small amount of ether, called “gas”. The amount varies depending on the transaction code size and complexity. For instance, many loops in the smart-contract code increase its complexity and thus the gas consumption of a respective transaction.
Unlike in Bitcoin, there is no fixed megabyte limit for the size of a block. In Ethereum, a block’s size is limited by a total gas consumption limit. For instance, in April 2016, the total gas limit amounted to 4,712,388 gas which can be spent on every block.
For an average transaction size of 21,000 gas, that are needed for a default value transfer, and a target block time of 15 seconds, about 224 transactions can be placed in one block until the total gas limit is reached. Thus, about 14 transactions can be processed per second.
If the gas limit per block is constantly reached within 15 seconds, the protocol reacts to the increased demand and increases the limit by a factor of 1+1/1024 each block or about 0.09%. This way, Ethereum adapts the gas limit either up or down to meet the targeted block time of 15 seconds.
Thus, compared to the 10 minute block latency in Bitcoin, Ethereum enables much faster verification of transactions. Therefore, Ethereum’s performance-scalability is somewhat better than Bitcoin’s. However, processing about 15 transactions per second is far from what mainstream payment systems require. For instance, VISA handles on average around 2000 transactions per second.
Although faster transaction processing on Ethereum might benefit some Dapp complementors, it should be noted that another restriction exists: The maximum size of a smart contract is restricted by the total gas consumption limit of a block.
For instance, for a block gas limit of about 3 million gas (as of February 2016), any single transaction for which computational effort exceeds this limit cannot be included in a block. Thus, the largest possible transaction data size was about 44kB for a transaction full of non-zero bytes in February 2016.
For decentralized application (Dapp) developers the gas limit makes development of Dapps more cumbersome because highly complex code that exceeds the total gas limit of a block cannot be deployed onto the Ethereum blockchain as a whole. That is why Dapp developers started to rethink their development process. They now, break down complex smart contracts into modular smaller smart contracts. These modular contracts are small enough to be deployed. Once deployed, they can call functions in each other, so that together they provide the functionality of one large smart contract. That way complex Dapps can be deployed on Ethereum.
It should be kept in mind that with a rising number of processed transactions on Ethereum, also gas fees for transactions increase. This might limit the viability of Dapps that require high numbers of transactions. Consequently, Ethereum’s scalability also imposes major challenges on scaling decentralized applications. For instance, an Uber-like application that requires thousands of daily transactions would currently not be able to scale on Ethereum.
Similar to Bitcoin, also Ethereum is working on solving scalability challenges. But again, we are talking about a network with a market cap of roughly $29 Billion USD (Oktober 2017). So it is highly important to ask:
Who has the authority to make decisions about protocol changes on Ethereum? To find out more, see here.
To see an overview of all articles, go here.
