Guy Takes One Week to Sync an Ethereum Full Node

4

Syncing eth full node, September 2019

Alex Moskovski, who describes himself as an “expert internet entrepreneur,” had to wait one week to download and sync the entire ethereum history in a non-archival full node.

The journey began on August 27th when he said: “the playground is an 8 CPU / 32 GB DO droplet ($160/mo) + 500 GB volume ($50/mo).”

Once he “geth –syncmode=”full” –cache=28672,” the node went off executing all transactions of every block starting from the genesis block.

At first, the full node went fast towards the 2017-18 bull market. Then:

“Things have slowed down considerably as we’re syncing Jan 2018. Memory footprint is surprisingly small at 16.5 GB (why did I bought that expensive droplet again?). CPU are working hard though.”

This was on August 29th. It took about a day to get from January 2018 to March 2018. Then transactions fall in eth, but the node took another three days to get to current history.

All was happy to run just as it should, with no glitches or problems, just chugging along through in the end 169 gigabyte of data. Once finished, a celebratory poem:

“His node is sweaty, SSD weak, blocks are heavy
There are kitties on the blockchain already: fucking beasties
Maxis troll him but his geth goes smooth and steady
To be synced already.”

A bitcoiner is doing the same with a bitcoin node, but he has just started and his “diary” isn’t as detailed.

The bitcoiner was thinking this would be over in hours, but it is probable there too it will take a week or 4-5 days.

Both networks are running at the equivalent of 1MB per ten minutes, with both currently having about the same capacity of circa 1 million eth transactions and about 1 million bitcoin outputs, which are the equivalent of an eth transaction.

Both are trying to figure out how to scale this 3 days to sync one year of full 1MB blocks history because if we extrapolate, then it would take a month to sync the full node when bitcoin turns 20.

This process of syncing is necessary to join the network in a trustless way. There can be fast syncs which don’t require as much history, or SPV wallets which rely on block headers for verification, thus do not need any history at all.

Both fast and light, however, rely on a set of full nodes, with eth and bitcoin both having about 10,000 publicly accessible.

To make it easier to join the network as a full node, eth and bitcoin devs are working on all sorts of compressions both vertical and horizontal to fit more transactions in the same amount of bytes.

Compressed or otherwise, history will continue, with one potential option being pruning after setting up some sort of decentralized checkpoints system, so allowing for the archiving of history in a way that doesn’t affect full nodes in regards to their trustless and permissionless qualities as well as in regards to full verification.

In ethereum such decentralized checkpoints system is planned for next year. While how to achieve that in bitcoin is not very clear.

Copyrights Trustnodes.com

4
Comment

100000
3 Comment threads
1 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
4 Comment authors
  Subscribe  
newest oldest most voted
Notify of
Chris Harvey

Please hire someone who has a college degree to pen your articles. How do you run a news site with authors that DON’T have an 8th grade reading comprehension level. How EMBARRASSING.

Corey Jessen

That was a frustrating read, for sure.

PureDigitalBTC

Have tried the Bitcoin Core 0.18.1 using ARM Linux using a Raspberry Pi 4 4GB! I was so close to downloading the Bitcoin blockchain until I crashed & ran out of Virtual Memory! It wasn’t kidding when blockchain is 200GB for Bitcoin!

Miauu

Try with BSV 🙂