Having trouble synchronizing your Ethereum node in 2018? Well you are not alone and here are few tips that might help you getting this increasingly difficult task done. Let’s start with quick overview on types of Ethereum nodes that you may run from your Ethereum-Go (geth) Installation
- Full node: This is the most heaviest and may take several days or even weeks depending on your hardware and internet uplink. A full Ethereum node stores and validates entire transaction history, which means you will be able to request information via console/RPC for any block or transaction or retrieve any receipt starting from the very first/early ones.
- Fast: This is now the default sync mode. Your node will not store any blocks/transactions/receipts history however it will still download millions of state trie before finishing this sync. You will only be able retrieve blocks/transactions from past few blocks or transactions.
- Light: This is the recommended sync mode for personal use with minimum hardware and bandwidth requirements. You will be only downloading current state trie but relying on other full nodes for validations.
Which node should you be using?
Deploying a full node for different projects/platform is now a days nearly out of equation as it is increasingly becoming impossible because of increasing number of known/reported cases where database is corrupted right in middle of sync forcing users to restart entire process again only to waste several days and hours. (i.e. Issue # 14381 and several others…)
Business use (combination of “fast” and “full” sync)
For the projects where you have to run a node so you can retrieve transactions and balances for your users, downloading entire blockchain using full sync is mostly unnecessary therefore it is recommended to do a FAST sync and as it completes, terminate geth process and restart by replacing --syncmode "fast" flag to --syncmode "full"
This way you will start storing block headers, blocks, transactions, transaction receipts (all the requirements) to be able to retrieve and process transactions performed by your project users. You still require a server with decent server configuration, a SSD and decent internet uplink to be able to finish fast sync.
Are you facing a race condition? (Constantly staying 50-100 blocks behind while known/pulled state entries count keeps rapidly increasing?)
A lot of users have complained about this as their “fast” sync never completes even after several days and they are constantly behind 50-100 blocks.
The problem is that state trie needs to be fully downloaded first and it is absolutely MASSIVE; But good news is that IT WILL EVENTUALLY FINISH depending on your server resources. I was able to complete “fast” sync with in 16-20 hours on one of my very recent nodes and switching to “full” mode afterwards was instantaneous and my node is fully operational. Here are the few things you should note down before you start:
Successfully performing a “fast” sync
- Yes! You need a SSD: While it is now widely known and understood that it is impossible to do a “full” sync on a HDD, from my experience you now also need SSD to be able to successfully do a “fast” sync on Ethereum mainnet.
- Feed it with more RAM: I recommend allocating at least 8GB of RAM to geth synchronization process using --cache 8192 flag. On my very recent node deployment, and based on recommendation by other users I tried allocating as much as 24GB of RAM ( --cache 24567) but for some reason cache value never exceeded value of 8010 which I think is recommended maximum for geth process.
- Server configuration matters: You literally need better configuration with your server, DDR3 which is still widely available on data centers is obviously not comparable to DDR4 memory, so allocating 8GB of DDR3 is obviously not as good as 8GB DDR4. Same logic applies to CPUs and other components, the newer hardware the better it is.
- Cloud servers: It is of course possible to successfully complete “fast” sync in virtualized environment but make sure your service provider utilizes SSD (i.e. DigitalOcean) and you have more of those high priority vCPU cores.
- Let peers connect: Simply enabling connections to port 30303 on your server will shoot peers count from 5 or 6 to up to 25 with in a couple of minutes!
- Enable time synchronization via NTP: This is also helpful, you should enable NTP (network time protocol) time sync for better performance with peers. (i.e. on Debian/Ubuntu sudo timedatectl set-ntp true )
I hope this helped!