Hacker News Reader

Comment by homakov | Hacker News Reader

FYI this is not the reason Ethereum failed as a blockchain. Security bugs are bad, but what's worse is 9GB/week bandwidth requirement = 3 hours sync on average world connection, if you're lucky.

No idea why everyone ignores this metric. And that's why Bitcoin is still somewhat blockchain (also poor sync, but doable)

View on HN

It is not 9GB/week. The 9 GB is the tx data plus the state at every block. You don't need the copy of the state at every block. The latest state is perfectly sufficient. More indepth explanation:

https://www.reddit.com/r/ethereum/comments/6zcoja/10_gb_in_2...

You seem to be right! That doesn't dramatically change the problem, but with avg blocksize 13Kb https://etherscan.io/chart/blocksize multiply 6000 blocks per day the data to download per week is just 700Mb, am I right? I wonder why the wallet syncs so slowly then.

Shouldn't believe random charts on the internet!

That's 78MB :)

Eventually other solutions will be needed, like sharding. One solution for the never ending growth of spent transaction and block header data is snapshots. Practically, you can safely not validate tx data older than X, if X is a sufficient length of time.

A solution for neverending state size growth is storage rent with pruning of entries that default on rent payment.

78MB per week recently? What's the math?

Isn't sharding major compromise on security? I thought snapshots mean you just download the exact state at block X and never bother about tx older than X. And you do that not because of time, but because at the point of installing of blockchains you already trust _someone_ with node software, so you should also trust with latest state (and treat it just like genesis block).

Speaking of storage tax, Ethereum should have implemented one like yesterday.

Apologies, I misread what you wrote. I thought it was 6,000 blocks a week. I also misread that as 13 KB per block header, though that mistake didn't change the calculation.

If the average block size is 13 KB, then there should be 546 MB added per week (13 KB / block * 6000 blocks / day * 7 days / week).

I don't know enough about sharding to offer an informed opinion on it, though I imagine the security compromises are tolerable.

With regard to a snapshot, yes that is one way they're used. I was suggesting that archival nodes could even rely on snapshots to cap their storage requirements.

It would be perfect to make a snapshot whenever a blockchain to last state is taking over 20% of state size. I.e. with 10 GB state do it every 2Gb (monthly). And IMO it's safe to discard any chain older than 3-6 months because only people who were offline for that long would ever need them (unrealistic)

Last I saw there were more Ethereum nodes than Bitcoin nodes, almost twice as many.

That's like counting a mentions in Google Trends. Number of non-mining nodes is quite irrelevant to security or usability of the network. People install it to play around somewhere in the cloud.

3 hours of sync per week is not as bad as you might think. A week has 168 hours, which means you'll spend a minute per hour syncing on average.

Additionally, Ethereum, unlike Bitcoin, does not want everyone to run a full node, you can certainly run Archival nodes, but most people should be using light clients or nodes which do not store the full history of the chain (only recent history)

> A week has 168 hours, which means you'll spend a minute per hour syncing on average.

Assuming, the user wants to have a daemon running full time. They just downloaded your thing and you're imposing your rules? Deleted.

> Additionally, Ethereum, unlike Bitcoin, does not want everyone to run a full node

To me a full node is the one that verified every single block since the install point. (Not from genesis, a snapshot is fine). I'm strongly against archiving the blocks for normal users, only the state should be stored.

> They just downloaded your thing and you're imposing your rules? Deleted.

When you run software you kinda accept that this software imposes rules on you.

Or do you delete Firefox or Chrome because they enforce Certificate Validation on HTTPS with HSTS?

Certificate validation don't involve UX friction. I need this friction to be justified, and it the sync is very slow new comers will never bother to be a full node. Give people instant sync, and they won't consider light wallets anymore = greater overall security, ready for any censorship.

9GB/week is not huge at all, and ethereum nodes are not designed to be run on "average world connection". The only people running full nodes realistically should be on extremely fast connections.

Bandwidth and storage are only getting cheaper

Also "Ethereum failed as a blockchain"? They're the 2nd largest coin after bitcoin, it can hardly be called failed

>9GB/week is not huge at all

It's a lot on average.

https://medium.com/@homakov/weekly-sync-friction-the-most-im...

>They're the 2nd largest coin after bitcoin, it can hardly be called failed

"caps" are short term hypes, they are not definition of blockchain. Say, Ripple is not a blockchain at all. Try critical thinking, highly recommended.

> Try critical thinking, highly recommended.

This seems unnecessarily combative.

Sorry, I got very annoyed hearing price arguments. We need to stop caring about price and see what's underneath.

Yes, saying "ethereum failed" without refutation, out of the blue, when plenty of evidence shows otherwise, is not annoying at all.

As a blockchain. As a Ponzi scheme (and platform to run them) it's wildly successful.

You may have a point about the space but don't resort to insults like the last sentence. I think you also have a lot to prove when saying Ethereum has failed v Bitcoin.

I said specifically as a resistant blockchain, and gave a clear metric why. And not vs Bitcoin, which also isn't in great shape.

This brief comment intrigues me; can you provide more detail?

Wrote this piece for you

https://medium.com/@homakov/weekly-sync-friction-the-most-im...

Thank you

People ignore the metric because for most use cases you don’t need to set up a full node.

You need to be _able_ to become one easily and quickly. That's called censorship resistance.

Reply on news.ycombinator.com