(TL;DR: It has nothing to do with storage space limits)
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.
Index
-
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.
Source/More: The Ethereum-blockchain size has exceeded 1TB, and yes, it’s an issue