Thread by @librehash

2/ The reason for this is rooted in archival nodes.

For those that don't know, a full node in blockchain is *required* for *trustless* validation of the blockchain.

Without one, you will inevitably be forced to trust the word of some 3rd-party intermediary

3/ The problem the $ETH ecosystem is facing (beyond gas fees) is the growing burden of running an $ETH archival node (full node).

Right now, a full archival node requires approx. 7 TB of space.

That's 1 TB of growth in just 4.5 months. +3 TB < 1 year

etherscan.io/chartsync/chai…

4a/ The burden of running an archival node was made painfully clear in a bombshell post by @BlockCypher back in May 2019 following the Constantinople hard fork

blog.blockcypher.com/ethereum-woes-…

4b/ Here, we see it took over 2+ weeks to sync a full node (when it was less than 1/3rd the size it is now), and that not even @VitalikButerin was aware of how to launch one, claiming that even the @ethereum foundation had a full node (and that he didn't know anyone with one)

4c/ Another prominent member of the community attempted a full sync of @ethereum in 2019 (again when it was <1/3rd the size it is now)

Their start date = 8/27/2019 ; end date = 09/15/2019 (18-19 days) overwriting data on the disk multiple times

https://twitter.com/mskvsk/status/1166325983227654151?s=20

4d/ The takeaway here is that running an @ethereum full node is untenable for most of the ecosystem.

@Ethereum incorrectly calls their *pruned* nodes "full nodes", but the reality is that this is only done to give the impression that an archival node is unnecessary.

4e/ Essentially, Ethereum is reliant on the idea that the *hash* of data that exists beyond the 128-block prune time frame is accurate. At roughly 15-ish seconds / block [giving ETH some benefit here], 128-blocks amounts to approx. 30 minutes.

4f/ For those dependent upon "oracles", DeFi protocols, etc., it is critical that the API be in a functional state.

Otherwise, the consequence will be as @BlockCypher told us - *no access to the @ethereum blockchain

5/ Know what all these entities have in common? @MetaMask, @myetherwallet, @binance, @gnosisPM, @AragonProject @OpenZeppelin @compoundfinance @MakerDAO @coinbase @0xProject @AugurProject @KyberNetwork @blockchair or @CryptoKitties ?

They all use @infura_io as their API endpoint

6a/ If you're reading this thinking, "Wow, if something ever happened to @infura_io does that mean all those other services cease to function?"

The answer is 'Yes'.

In fact, it happened just 4 months ago

The fallout was so bad it caused a momentary HARD FORK.

6b/ As we can see in the attached picture here from ethernodes.io , over 80% of the network is running the same client (GETH); and most of those individuals are running

7/ All of this brings us to @Consensys , which is owned by @ethereumJoseph a co-founder of @ethereum ; they notably *own* and run @infura_io and @MetaMask , which - as we now know - is responsible for almost all of the @ethereum ecosystem functioning properly.

8/ When you pan out a bit, it becomes clear that the entire @ethereum ecosystem is reliant on essentially one provider...which is owned & managed by a co-founder of @ethereum

Can someone explain what's decentralized, distributed or trustless about this?

9a/ Some reading this may be thinking, 'What about archivenode.io?'

The site, 'archivenode.io' was set up a few weeks ago, purporting to provide access to their archival node "for free" as a gift to the @ethereum ecosystem.

@ArchiveNode

9b/ @ArchiveNode , which is ran by @defidude and @mysticryuujin received over $35k in grants from Gitcoin.

This is being mentioned, because there's a high chance that this archival node does not exist and is not in operation *at all*.

9c/ Back in November 2020, Librehash stated its intentions publicly to acquire access to the @ethereum @ArchiveNode being ran at archivenode.io

Several months later, I was told my request was *denied* (despite this being free & for community use)

9d/ This tweet contains my responses to the denial that I received from archivenode.io @ArchiveNode @defidude <--- specifically.

In @defidude's final response he doesn't address why *I* specifically was denied access, then erroneously states "anyone" can "sync" one

9e/ His answer is incredibly dishonest and deceptive because he claims that anyone can sync an *archival node* from a "full node" (pruned), which is patently false.

How would one be able to perform this sync w full nodes if the full nodes themselves don't have the req. data?