Recently, the blockchain of Ethereum has become the center of hot discussion as a result of its rapidly increasing size, with several industry observers noting that growing bloat may result in problems such as difficulties in synchronizing or archiving. Vitalik Buterin, the co-founder of Ethereum, has struck out against the criticisms of the exponentially increasing block size of Ethereum.
The Stem of the Debate
The exponentially increasing block size of Ethereum will cause a centralized, shrunken network which will increasingly be greater than the bandwidth and hardware capacity of the average network participation – according to an analysis released on Hackernoon on the 24th of May.
Is the Ethereum Blockchain Growing Too Fast?
The speedy increase of the Ethereum blockchain, driven by the creation and deployment of decentralized apps, smart contracts, and thousands of ERC20-based ICOs, has made a lot of observers to hypothesize that the network may crash if a new solution to the rapid growth of the network is not found.
The analysis released on Hackernoon posits that in order for Ethereum to prevent such an eventuality, it has to implement a block size cap.
Referencing to the latest flood of decentralized apps that are not regulated and the negative effect they have on the blockchain of Ethereum, the analysis suggests that the block size cap implementation will increase fees, hence preventing decentralized applications from functioning – resulting in the invalidation of the existence of the Ethereum network.
Vitalik Buterin Strikes Back
Vitalik Buterin – the creator of Ethereum – was quick to pinpoint the flaws in the argument presented, and he labeled the analysis as “severely uninformed.” Buterin said that there is already a block size limit for Ethereum, in the form of its gas limit – it’s been present for over six months now.
He also said that the analysis released on Hackernoon is “highly fallacious,” stating that focusing on the size of the achieve node is relevant, as a lower size of data-dir can be achieved by running self-pruning Parity node or resynchronizing once a year.