5 ms·
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
by homakov 9y ago
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)
- jameskegel 9y agoThis brief comment intrigues me; can you provide more detail?
- homakov 9y agoWrote this piece for you https://medium.com/@homakov/weekly-sync-friction-the-most-important-blockchain-security-metric-1042c0c172b7 https://medium.com/@homakov/weekly-sync-friction-the-most-im...
- jameskegel 9y agoThank you
- shawabawa3 9y ago9GB/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
- homakov 9y ago>9GB/week is not huge at all It's a lot on average. https://medium.com/@homakov/weekly-sync-friction-the-most-important-blockchain-security-metric-1042c0c172b7 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.
- komaromy 9y ago> Try critical thinking, highly recommended. This seems unnecessarily combative.
- homakov 9y agoSorry, I got very annoyed hearing price arguments. We need to stop caring about price and see what's underneath.
- MichaelGG 9y agoYou 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.
- homakov 9y agoI said specifically as a resistant blockchain, and gave a clear metric why. And not vs Bitcoin, which also isn't in great shape.
- kolinko 9y agoPeople ignore the metric because for most use cases you don’t need to set up a full node.
- homakov 9y agoYou need to be _able_ to become one easily and quickly. That's called censorship resistance.
- zaarn 9y ago3 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)
- homakov 9y ago> 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.
- zaarn 9y ago> 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?
- homakov 9y agoCertificate 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.
- zeven7 9y agoLast I saw there were more Ethereum nodes than Bitcoin nodes, almost twice as many.
- homakov 9y agoThat'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.
- CryptoPunk 9y agoIt 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_days_as_a_bitcoiner_serious_question/dmuglq3/ https://www.reddit.com/r/ethereum/comments/6zcoja/10_gb_in_2...
- homakov 9y agoYou seem to be right! That doesn't dramatically change the problem, but with avg blocksize 13Kb https://etherscan.io/chart/blocksize 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!
- CryptoPunk 9y agoThat'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.
- homakov 9y ago78MB 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.
- CryptoPunk 9y agoApologies, 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.