The Ethereum-blockchain size has exceeded 1TB, and yes, it’s an issue

(TL;DR: It has nothing to do with storage space limits)

May 23, 2018 · 21 min read


This is an indirect response to the following article by Afri Schoedon, a developer for the Parity Ethereum client, written less than a year ago:


  • My Argument: Ethereum’s runaway data directory size is just the tip.
  • My Prediction: It will all work, until it doesn’t.
  • My Suggestion: Transpose.

My Argument: Larger blocks centralize validators.

It’s that simple. It’s the central argument in the entire cryptocurrency community in regards to scaling. Not many people familiar with blockchain protocol actually deny this. The following is an excerpt from what I consider to be a very well put together explanation of various “Layer 2” scaling options. (Of which, the only working one is already implemented on Bitcoin.)

Here is what a blockchain provides:

  • An immutable & decentralized ledger.
  • That’s it.

Here is what a blockchain needs to keep those properties:

A decentralized network with the following prerogatives:

  • Append my ledger — Work
  • Incentivise my needs — Token

Here is what kills a blockchain:

  • Any feature built into the blockchain that detracts from the network’s goals.
  • You can prune the blockchain if you need to anyway.
  • You don’t need to validate everything from the genesis block, the last X amount of blocks is enough to trust the state of the network.
  1. Bandwidth growth rates are slower. Check out Nielsen’s Law. Starting with a 1:1 ratio (no bottleneck between hardware and bandwidth), at 50% growth annually, 10 years of compound growth result’s in a ~1:2 ratio. This means bandwidth scales twice as slow in 10 years, 4 times slower in 20 years, 8 times in 40 years, and so on… (It actually compounds much worse than this, but I’m keeping it simple and it still looks really bad.)
  2. Network latency scales slower than bandwidth. This means that as the average bandwidth speeds increase among nodes on the network, block & data propagation speeds do not scale at the same rate.
  3. Larger blocks demand better data propagation (latency) to counter node centralization.

Remember this because it’s going to get very important later in this article:

  • You can put invalid transactions into a block and still create a valid block header.
  • If the network is controlled by 10 FULL-nodes, you only need half of them to ignore/approve invalid transactions so long as the header is valid.

My Prediction: Ethereum will implement a blocksize cap and it will race BCash to both of their deaths. ←No longer updating statistics, chart is edited & extrapolated using REAL current data.
  • The amount of data an Ethereum node is required to process per second is through the roof and climbing. (Unideal)
  • If Ethereum on-chain demand freezes where it is now, blockchain growth will continue the linear trend highlighted by that dotted line. (Very bad)
  • If Ethereum on-chain demand continues to grow exponentially the amount of people complaining about their node going out of sync will reach a tipping point. (There’s only one option when this occurs.)
  • Transaction times on the other hand have slowly gone up but seem to be stabilizing. They’ve been “intentionally” allowed to go up as a result of privacy improvements in the software, but that’s a worthy tradeoff because blocks are 10 minutes apart on average anyway, so a delay of 16 seconds is acceptable. I’d imagine that once blocks are consistently full this growth will level off because transaction fees from the blocksize cap will self-regulate the incoming flow of transactions, assuming no other protocol changes are made.

These Dapps are crippling your blockchain because it’s unregulated:
Find a good peer.
I’m not linking to a BCash propaganda site.

There are 115,000 Bitcoin nodes and they all fully validate:

The takeaway from all of this:

  1. Ethereum’s blocksize growth is bad because of node processing requirements, not how much they need to store on a hard-drive.
  2. To prevent complete collapse of the network, Ethereum will need to implement a reasonable blocksize cap.
  3. Implementing a blocksize cap will raise fees and in return prevent many Dapps from functioning, or severely slow down. Future Dapps won’t work.
  4. If Dapps don’t work, Ethereum’s entire proposition for existing is moot.

Where does BCash fit in?

  1. BCash just increased their blocksize from 8MB to 32MB, and is adding new OP_CODES soon to allow “features” like ICOs and BCash Birdies.
  2. BCash has “room to grow” coming from a completely understressed blockchain, while Ethereum is a completely overstressed blockchain.

My Suggestion: Stop using centralized blockchains.

This section has been extensively expanded on in the follow-up article. The diagrams have been completely redone. Reading that is a must after this.

  • An SPV Client that does nothing, is just tethered to a full-node, syncs just the block headers, and shares nothing. They are not part of the network. They shouldn’t even be mentioned here but I’m doing it to avoid confusion.
  • Nodes that try to do everything but can’t sync up because of peer issues so they skip the line and use warp/fast sync, and then “fully”-validate new transactions/blocks.
  • Light-“nodes” that are permanently syncing just the block headers, and I guess they are sharing the headers with other similar nodes, so let’s call these “SPV Nodes”. They don’t exist in Bitcoin, again SPV clients in Bitcoin don’t propagate information around, they aren’t nodes.

Part 2


Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface.

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox.

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic.

Get the Medium app