The Ethereum-blockchain size has exceeded 1TB, and yes, it’s an issue
Tags: Blockchain, Ethereum, Scaling, Bitcoin, Decentralization

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

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

Introduction

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:

I want to make it clear that I have respect for almost all of the developers in this space, and this is not intended to attack anyone. It’s meant to elaborate on what the real concerns are and explain how the original article does nothing to address those real concerns. I would actually love to see something that does, because then we can throw it into Bitcoin. That being said, there are some developers who mislead, obscure, ignore, and attack via protocol confusion like what occurred with 2X and the replay protection drama, but most aren’t like that. You can’t watch something like this or read something like this and hate these developers. They’re genuinely trying to fight the same fight as us, and I believe Afri is part of the latter group, not the former.

If you’ve read my other articles you’re going to see some small bits of that information repeated. Up until now I wrote primarily about Bitcoin from a “maximalist” perspective (still am) and focused on conflicts within that community. What you may find interesting if you only watch from the corner of your eye, is that the reason for “conflict” here is exactly the same. I’ll even use Proof-of-Stake as further leverage for my argument without criticizing it.

Edit: It seems like people are not reading the subtitle and misunderstanding something. This is not about archival nodes. This is about fully validating nodes. I don’t care if you prune the history or skip the line to catch-up with everyone else. This is about about staying in sync, after the fact. Light nodes aren’t nodes.

This has become a 2-part article. When you’re done with this article you can read the follow-up one:

Index

My Argument: Ethereum’s runaway data directory size is just the tip.

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

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.)

That article is written by Josh Stark. He gets it. His company even announced a project that’s meant to mirror the Lightning Network on Ethereum. (Which is oddly coincidental given Elizabeth Stark’s company is helping build Lightning.)

The problem? Putting everything about Proof of Stake completely to the side, the incentive structure of the base layer is completely broken because there is no cap on Ethereum’s blocksize, and even if one was put in place it would have to be reasonable, and then these Dapps wouldn’t even work because they’re barely working now with no cap. It doesn’t even matter what that cap is set at for this argument to hold because right now there is none in place.

Let’s backtrack a bit. I’m going to briefly define a blockchain and upset people.

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:

Distribute my ledger — Validate

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.

A blockchain is just a tool for a network. It’s actually a very specific tool that can only be used by a very specific kind of network. So much so that they require each other to exist and fall apart when they don’t co-operate, given enough time. You can build on top of this network, but quite frankly anything else built into the base layer (L1) that negatively affects the network’s ability to do its job is going to bring the entire network to its knees…given enough time.

Here’s an example of an L1 feature that doesn’t effect the network: Multisig.

It does require the node to do a bit of extra work, but it’s “marginal”. The important thing to note is hardware is not the bottleneck for these (properly designed) networks, network latency is. Something as simple as paying to a multi-signature address won’t tax the network any more than paying to a normal address does because you’re paying on a per-byte basis for every transaction. It’s a blockchain feature that doesn’t harm the network’s ability to continue doing its job because the data being sent over the network is (1)paid for per-byte, and (2)regulated via the blocksize cap. Regulated, not “artificially capped”. The blocksize doesn’t restrict transaction flow, it regulates the amount of broadcast-to-all data being sent over the network. Herein lies the problem.

When we talk about the “data directory” size, it’s a direct reference to the size of the entire chain of blocks from the original genesis block, but taking this at face value results in the standard responses:

Disk space is cheap, also see Moore’s Law.

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.

What these completely ignore is the data per-second a node must process.

You can read my entire article about Moore’s Law if you want, but I’ll excerpt the important part below. Over in Oz they try and argue “you don’t need to run a node, only miners should decide what code is run”. It’s borderline absurd, but I won’t have to worry about that here because Proof of Stake completely removes miners and puts everything on the nodes. (They always were, but now there aren’t miners to divert the argument.)

Moore’s Law is a measure of integrated circuit growth rates, which averages to 60% annually. It’s not a measure of the average available bandwidth (which is more important). 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.) 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. Larger blocks demand better data propagation (latency) to counter node centralization.

Strictly from an Ethereum perspective with a future network of just nodes after the switch to Proof of Stake, you’d generally want to ensure node centralization is not an issue. The bottleneck for Bitcoin’s network is its blocksize (as it should be), because it ensures the growth rate of network demands never exceed the growth rate of external (and in some cases indeterminable) limitations like computational performance or network performance. Because of Ethereum’s exponentially growing blocksize, the bottleneck is not regulated below these external factors and as such results in a shrinking and more centralized network due to network demands that increasingly exceed the average users hardware and bandwidth.

Bitcoin SPV clients aren’t nodes. They don’t propagate blocks or transactions around the network, they leech, and all that they leech are the block headers.

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.

block and still create a 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.

This is why validating the transactions matter from a network perspective, and why you need a large decentralized network. It doesn’t matter from my grandmas perspective and that’s fine, but we aren’t talking about my grandma. We’re talking about ensuring the network of working and actively participating nodes grows, not shrinks.

This node was participating until it got cut off due to network demand growth:

It’s not uncommon and it continues to happen:

Notice how the solution is to “find a good peer” or “upgrade your hardware”? Good peers shouldn’t be the bottleneck. Hardware shouldn’t be either. When all of your peers are hosed up by so many others leeching from them (because the good peers are the ones doing the real work), you create a network of masters and slaves that gradually trend towards only one master and all slaves. (If you don’t agree with that statement you need to make a case for how this trend won’t subside in the future because currently that’s the direction this is going towards and it won’t stop unless a cap is put in place. If your answer is sharding, I address that fairy dust at the end.) It’s the definition of centralizing. Unregulated blocks centralize networks. Large (but capped) blocks are only marginally better, but set a precedent for an ever increasing block size, which is equally as bad because it sets a precedent of increasing the size “in times of need”, which mirrors the results of unregulated blocksizes. This is why we won’t budge on the Bitcoin blocksize.

I tweeted about it a few times but clearly I didn’t think that was enough. My Twitter reach doesn’t really extend much into the Ethereum space.

That chart is symbolic and not representative of any actual numbers. It only serves to visually express the point I’m trying to make. To clarify, the green curve represents an aggregated average of the various demands of the Ethereum Network. At some point your node will fall out of sync because of this or a blocksize cap will be put in place. It could happen now, or it could happen in 10 years, or in 50 but your node will fall out of sync at some point at this rate. It will never happen in Bitcoin. You can deny it now all you want, but this article will be here for when it happens, and when it does asinine Dapps like CryptoKitties, Shrimp Farm, Pepe Farm, and whatever comes next will cease to function. This is exactly what happened to Ryan Charles’ service Yours.org that he originally built on Bitcoin. The only difference being Bitcoin already had the cap in place and Ryan either didn’t foresee this from a lack of understanding, or for some reason he expected the blocksize to keep getting raised. Instead of reassessing he doubled down on BCash, meanwhile Yalls.org took his concept and implemented the same exact thing on top of Bitcoin’s Lightning Network.

My Prediction: Ethereum will implement a blocksize cap and it will race BCash to both of their deaths.

http://bc.daniel.net.nz/ ←No longer updating statistics, chart is edited & extrapolated using REAL current data.

The chart above isn’t even a prediction. This is me filling in the blanks (in yellow) on what was the last remaining graph that compared both chains data directories, and then extrapolating from it. Here’s what we know:

Bitcoin’s future is predictable. The blockchain growth & network demands will always be linear. (Ideal)

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.)

That graph above? The owner stopped trying to maintain the node. Physical demands are an issue as well, like time constraints in your personal life. Servicing requirements need to be low, not high, not reasonable…low.

Do you know what I do to service my Bitcoin/Lightning node? I leave my laptop on. That’s it. If I have to reboot I shut down the services, reboot, and start them back up again. Day to day I use my laptop for an assortment of other tasks, none of which inhibit its ability to run the node software. With all due respect if a change was implemented and forced on me that resulted in my node no longer being compatible with the network and unable to maintain a sync, I would flip out over the idiocy that allowed that, if I was a misinformed individual. Fortunately I’m not and I signed up for a blockchain with foresight (Bitcoin).

The problem? I don’t think most of the people running Ethereum nodes are informed enough to know what they signed up for. I don’t think they understand the fundamental incentive models, and I don’t think they fully realize where and why they break down with something as simple as not having a blocksize cap. Hopefully this article will succeed at teaching that.