8 ms·

By now the Ethereum bloat is so bad that cheaply running an individual node is practically impossible for a lay person. This is an important yet under-apprecia

by apo 8y ago

By now the Ethereum bloat is so bad that cheaply running an individual node is practically impossible for a lay person. This is an important yet under-appreciated point. It's now extremely difficult to sync an Ethereum node from scratch. If the processes ever completes on commodity hardware, it takes weeks. And that difficulty will only climb as more and more stuff gets dropped onto the Turing-Complete "world computer." This situation drives users in ever greater numbers to services that tell them which transactions are valid or not. Verification with a full node, the bedrock of censorship resistance, dies a death of 1,000 cuts as a result.

xur17 8y ago
> This is an important yet under-appreciated point. It's now extremely difficult to sync an Ethereum node from scratch. If the processes ever completes on commodity hardware, it takes weeks. And that difficulty will only climb as more and more stuff gets dropped onto the Turing-Complete "world computer." This is simply untrue. I recently synced an Ethereum node on a 2 year old desktop computer. Took ~1 day.
- xiphias2 8y ago
  You did a fast sync, not a real full sync (which verifies the transactions since the genesys block).
  - erulabs 8y ago
    Right, but re-verifying every txn (a "full sync") isn't exactly the topic. You do not need to re-verify every txn to run an Ethereum node, which is what the article suggests is extremely difficult. And that's not a "light" node, it's a full node, you're just trusting the network initially (additional "trust" is "built" as transactions are processed by the node, which is the beauty of the merkle tree structure). It certainly makes plenty of sense that single handedly reverifying the entire chain will become increasingly difficult with respect time and energy. It becomes a very complex argument about network trust at that point, but the point still stands that "It's now extremely difficult to sync an Ethereum node from scratch" is a very dubious statement (for admittedly varying definitions of 'extremely difficult')
    - xiphias2 8y ago
      I'm not saying that it's completely bad, but with Bitcoin the devs work really hard to improve the software to make sure that the time for full resync doesn't grow too much, and that it can run on an average laptop that has SSD. The biggest problem with the fast sync is that sometimes when Ethereum node gets stuck, the devs just suggest to do a new fast sync, which - in my opinion - requires enourmous amount of trust in the developers. Hard forks also require a lot of trust, as old software can't be run side-by-side with new software to validate the blockchain.
    - keymone 8y ago
      > you're just trusting the network initially Yeah, let’s “just” trust random strangers’ computers to tell us the state of financial system. What could possibly go wrong. If you don’t understand importance of “don’t trust, verify” than you shouldn’t have anything to do with cryptocurrencies (or cryptography for that matter).
      - man-and-laptop 8y ago
        Forgive me if I'm misunderstanding, but I disagree with you. A merkle tree is a recursive structure. If you trust a substructure of it, then you don't need to repeatedly re-evaluate that substructure. What that means in practical terms is if the merkle-tree entry summarising the state of the chain as it was a year ago is assumed correct, then you don't need to keep any of the transaction data from before that point. But this can only work if you don't have to look back. In Bitcoin, every transaction references an arbitrary previous transaction to prove that it has sufficient funds. You would therefore need "checkpoint" transactions that say "This is the amount of money everybody's got now; we can now forget the past".
        keymone 8y ago
        you are misunderstanding. you're given a state of accounts and it has "correct" signature (according to a third party) - without verifying every transaction that contributed to building that state you cannot be certain it doesn't contain invalid records. merkle has nothing to do with it, you either verify or you trust a third party. checkpointing ethereum state or checkpointing bitcoin utxo set is a way to trade away security, decentralization and trustlessness for faster bootstrap. and ethereum folk have become way to relaxed about that fact.
snissn 8y ago
It takes me about a day to sync parity on a consumer desktop with an ssd and a 7 year old i5 Intel cpu
- just_one_time_ 8y ago
  I worry that disk space will stop increasing and manufacturers will stop producing hard drives one day, what will Ethereum do then?
- erulabs 8y ago
  For me, just about 18 hours with parity on a fairly new i7 and fairly fast (200mbps) net and NVMe disks. Haven't repeated enough to be sure, but I can't figure out how to replicate the "weeks" argument I keep hearing. I suppose on average American broadband (~15mbps) and spinning HDDs the week-long numbers start to seem reasonable?
  - erulabs 8y ago
    Edit: It seems (based on the conversations in this thread) the argument is versus "full", "fast" and "light" sync methods. Full implies personally reverifying the entire chain and every transaction, which takes a week or more. Fast pulls down the entire chain (and all of its data), and takes ~18 hours (what I mentioned above), but still results in a complete Ethereum node. It becomes a philosophical argument if the "fast" sync method implies "enough trust", or if everyone should be expected to reprocess every transaction ever. Personally (and i'm not a mathematician) from what I understand of merkle trees, as additional transactions are verified, the "trust in the past" grows, as it would be increasingly difficult to have lied about (or rather, to change) a previous transaction. Philosophy aside, it's really painless and takes less than a day to get a Ethereum node up and running and chugging away, hard stop.
    - bouncycastle 8y ago
      My understanding that a full sync in Bitcoin means something different than a full sync on Ethereum. Bitcoin's database is modeled on UTXO (https://en.m.wikipedia.org/wiki/Unspent_transaction_output https://en.m.wikipedia.org/wiki/Unspent_transaction_output) therefore all clients need to validate all transactions from genesis to calculate final balances. Meanwhile, Ethereum is account based and state is global, and to determine the balances you only need to check the merkle proof, no need to store or re-validate each and every transaction, just the final result. Source: https://github.com/ethereum/wiki/wiki/Design-Rationale#accounts-and-not-utxos https://github.com/ethereum/wiki/wiki/Design-Rationale#accou... quote "The benefits of accounts are:Large space savings" In Ethereum, the closet to a Bitcoin full node would be an 'full archive' node, those are keeping all the transactions, down to the stack traces and events, without pruning. These are usually run by block explorers, but you certainly don't need to store that much detail if you just want to interact with a dapps.
apron1 8y ago
Vitalik Buterin disagrees with you specifically on the topic of endlessly increasing impractical eth blockchain: https://medium.com/@VitalikButerin/because-of-ethereums-exponentially-growing-blocksize-the-bottleneck-is-not-regulated-8c0acd77b3a2 https://medium.com/@VitalikButerin/because-of-ethereums-expo...

by apo 8y ago

xur17 8y ago

> This is an important yet under-appreciated point. It's now extremely difficult to sync an Ethereum node from scratch. If the processes ever completes on commodity hardware, it takes weeks. And that difficulty will only climb as more and more stuff gets dropped onto the Turing-Complete "world computer." This is simply untrue. I recently synced an Ethereum node on a 2 year old desktop computer. Took ~1 day.

xiphias2 8y ago
You did a fast sync, not a real full sync (which verifies the transactions since the genesys block).
- erulabs 8y ago
  Right, but re-verifying every txn (a "full sync") isn't exactly the topic. You do not need to re-verify every txn to run an Ethereum node, which is what the article suggests is extremely difficult. And that's not a "light" node, it's a full node, you're just trusting the network initially (additional "trust" is "built" as transactions are processed by the node, which is the beauty of the merkle tree structure). It certainly makes plenty of sense that single handedly reverifying the entire chain will become increasingly difficult with respect time and energy. It becomes a very complex argument about network trust at that point, but the point still stands that "It's now extremely difficult to sync an Ethereum node from scratch" is a very dubious statement (for admittedly varying definitions of 'extremely difficult')
  - xiphias2 8y ago
    I'm not saying that it's completely bad, but with Bitcoin the devs work really hard to improve the software to make sure that the time for full resync doesn't grow too much, and that it can run on an average laptop that has SSD. The biggest problem with the fast sync is that sometimes when Ethereum node gets stuck, the devs just suggest to do a new fast sync, which - in my opinion - requires enourmous amount of trust in the developers. Hard forks also require a lot of trust, as old software can't be run side-by-side with new software to validate the blockchain.
  - keymone 8y ago
    > you're just trusting the network initially Yeah, let’s “just” trust random strangers’ computers to tell us the state of financial system. What could possibly go wrong. If you don’t understand importance of “don’t trust, verify” than you shouldn’t have anything to do with cryptocurrencies (or cryptography for that matter).
    - man-and-laptop 8y ago
      Forgive me if I'm misunderstanding, but I disagree with you. A merkle tree is a recursive structure. If you trust a substructure of it, then you don't need to repeatedly re-evaluate that substructure. What that means in practical terms is if the merkle-tree entry summarising the state of the chain as it was a year ago is assumed correct, then you don't need to keep any of the transaction data from before that point. But this can only work if you don't have to look back. In Bitcoin, every transaction references an arbitrary previous transaction to prove that it has sufficient funds. You would therefore need "checkpoint" transactions that say "This is the amount of money everybody's got now; we can now forget the past".
      - keymone 8y ago
        you are misunderstanding. you're given a state of accounts and it has "correct" signature (according to a third party) - without verifying every transaction that contributed to building that state you cannot be certain it doesn't contain invalid records. merkle has nothing to do with it, you either verify or you trust a third party. checkpointing ethereum state or checkpointing bitcoin utxo set is a way to trade away security, decentralization and trustlessness for faster bootstrap. and ethereum folk have become way to relaxed about that fact.

snissn 8y ago

It takes me about a day to sync parity on a consumer desktop with an ssd and a 7 year old i5 Intel cpu

just_one_time_ 8y ago
I worry that disk space will stop increasing and manufacturers will stop producing hard drives one day, what will Ethereum do then?
erulabs 8y ago
For me, just about 18 hours with parity on a fairly new i7 and fairly fast (200mbps) net and NVMe disks. Haven't repeated enough to be sure, but I can't figure out how to replicate the "weeks" argument I keep hearing. I suppose on average American broadband (~15mbps) and spinning HDDs the week-long numbers start to seem reasonable?
- erulabs 8y ago
  Edit: It seems (based on the conversations in this thread) the argument is versus "full", "fast" and "light" sync methods. Full implies personally reverifying the entire chain and every transaction, which takes a week or more. Fast pulls down the entire chain (and all of its data), and takes ~18 hours (what I mentioned above), but still results in a complete Ethereum node. It becomes a philosophical argument if the "fast" sync method implies "enough trust", or if everyone should be expected to reprocess every transaction ever. Personally (and i'm not a mathematician) from what I understand of merkle trees, as additional transactions are verified, the "trust in the past" grows, as it would be increasingly difficult to have lied about (or rather, to change) a previous transaction. Philosophy aside, it's really painless and takes less than a day to get a Ethereum node up and running and chugging away, hard stop.
  - bouncycastle 8y ago
    My understanding that a full sync in Bitcoin means something different than a full sync on Ethereum. Bitcoin's database is modeled on UTXO (https://en.m.wikipedia.org/wiki/Unspent_transaction_output https://en.m.wikipedia.org/wiki/Unspent_transaction_output) therefore all clients need to validate all transactions from genesis to calculate final balances. Meanwhile, Ethereum is account based and state is global, and to determine the balances you only need to check the merkle proof, no need to store or re-validate each and every transaction, just the final result. Source: https://github.com/ethereum/wiki/wiki/Design-Rationale#accounts-and-not-utxos https://github.com/ethereum/wiki/wiki/Design-Rationale#accou... quote "The benefits of accounts are:Large space savings" In Ethereum, the closet to a Bitcoin full node would be an 'full archive' node, those are keeping all the transactions, down to the stack traces and events, without pruning. These are usually run by block explorers, but you certainly don't need to store that much detail if you just want to interact with a dapps.

apron1 8y ago

Vitalik Buterin disagrees with you specifically on the topic of endlessly increasing impractical eth blockchain: https://medium.com/@VitalikButerin/because-of-ethereums-exponentially-growing-blocksize-the-bottleneck-is-not-regulated-8c0acd77b3a2 https://medium.com/@VitalikButerin/because-of-ethereums-expo...