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.
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.
There is no difference between BTC’s UTXO model and Ethereum’s account model in this sense - both are aggregate structures and to have full certainty the aggregate you’re looking at is correct you have to run through all the transactions.
To speedup sync in BTC it is assumed that blocks older than some amount of YEARS are valid but you still have to go through their transactions to build up the aggregate UTXO set.
In ETH instead it is common to just download the result and trust it’s valid. And since it’s now impossible to sync from origin you can never tell if some account doesn’t have ether created from nothing.
The information is in the block headers.
> In ETH instead it is common to just download the result and trust it’s valid
Nope. You still have to download all the block headers from block 0 and check if they are valid, including the PoW and other hashes.. The blocks are basically tamper proof as in Bitcoin (but can also be vulnerable to a 51% attack)
Then that's where it all diverges from Bitcoin: in Ethereum, there are three merkle trees: one for the state, one for transactions and one for the transaction results (receipts). The roots of these trees are in the blocks, once you have these, you can verify a particular value of, say, a state value, without the need to verify each and every other value, by walking through the tree and doing a merkle proof. There's plenty of info on the web explaining how it works if you look it up, eg. Search for "ethereum state trie"
As for syncing, recently it improved a lot. I did it a few times last month with Geth on an old machine just to test it out. Synced within 2 days, a big improvement over the previous versions of Geth. And yes, it got all the blocks from 0 to current. Blocks by themselves are very light.
> You still have to download all the block headers from block 0 and check if they are valid, including the PoW and other hashes..
and unless you validate those blocks you don't know if the chain you're looking at is valid. headers don't help with that.
> The blocks are basically tamper proof as in Bitcoin (but can also be vulnerable to a 51% attack)
vulnerability to 51% attack depends on cost of such attack. if it is "normal" in ethereum to trust third parties with state of just couple hundred blocks old - the attack becomes very cheap. and if i understand correctly that's the case with majority of ethereum nodes as they aren't fully validating and are in fast sync or light mode.
in BTC `--assumevalid` points to a block that is more than year and a half old.
> The roots of these trees are in the blocks, once you have these, you can verify a particular value of, say, a state value, without the need to verify each and every other value, by walking through the tree and doing a merkle proof.
except when the state you downloaded from third parties and assumed was valid, was actually forged. since you're not executing transactions you can't know what transaction receipts would have been created.
> And yes, it got all the blocks from 0 to current. Blocks by themselves are very light.
nah, i call bs. it might have downloaded them but didn't validate anything beyond headers and some recent transactions. admittedly i haven't checked for like half a year, but full sync was literally freezing and not completing at all on powerful laptops and aws instances. it's quite possible the wonder kids of javascript cryptocurrency finally fixed their shit but i wouldn't bet my money on it.
An archival node in Ethereum goes beyond a full node, and stores data not needed to do full validation.
A full node in Ethereum needs to download about 80 GB I believe, which is a tenth of what an archival node needs to download and store.
https://ethereum.stackexchange.com/questions/37348/parity-fu...
There's a lot of misinformation, some originating due to genuine problems (trying to use a hdd or geth with barely working garbage collector) and misunderstandings, some from intentional lies (especially two r/bitcoin moderators - thieflar and stopanddecrypt).
The SSD vs. hard disk distinction is key. I ran into the "it will literally never complete" issue trying to sync to an external HD on my home MBP - I ran it for about a week and it didn't work. Tried parity as well, same result. Once I decided I'd just rent a big SSD from Amazon I had no problem.
Here's an example: https://github.com/ethereum/go-ethereum/issues/16237
,,Seems like it does indeed proceed but very slowly. After 12 days on the 96gig ram machine I am finally at block 4732597... I will report back how long it takes to finish.''
You can run a full node that verifies everything on an ongoing basis without doing a full sync from the genesis block - just start it in fast sync, let the chain catch up, and then run it again in full mode. Unless you believe the Ethereum blockchain has already been compromised, there's no reason why your personal node has to verify everything from the genesis block.
Geth CLI options: https://github.com/ethereum/go-ethereum/wiki/Command-Line-Op...
Understand the differences between syncing, validating, and pruning, then it becomes simpler... https://github.com/ethereum/go-ethereum/pull/1889 https://github.com/ethereum/go-ethereum/wiki/Tracing:-Introd...
This is simply untrue. I recently synced an Ethereum node on a 2 year old desktop computer. Took ~1 day.
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.
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).
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".
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.
https://medium.com/@VitalikButerin/because-of-ethereums-expo...
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.