Downloading all the blocks is a straightforward and fast procedure and will relatively quickly reassemble the entire chain. Instead of starting from the genesis block and reprocessing all the transactions that ever occurred (which could take weeks), fast sync downloads the blocks, and only verifies the associated proof-of-works. The current default mode of sync for Geth is called fast sync. Syncing Ethereum is a pain point for many people, so I'll try to detail what's happening behind the scenes so there might be a bit less confusion. Therefore, you need to have a lot of patience (or use light node) and you shouldn't get distracted by these 64/65 blocks left (the blocks themself are normally not the actual problem!).
but after your node synced all the state tries up to this 64/65 blocks left, it will basically change to a full node and will act like a full node without the -fast sync option (as far as I understood).
Your node won't know how many state tries exist (because the protocol doesn't broadcast this information) unless it is fully synced and doesn't receive any further state tries (which in theory will basically never happen because the network will always receive new transactions/contracts and therefore it will always try to catch up).
So yeah, if you want to have a "full node" (with fast sync instead of a light node) you basically need to wait very, very, very long for your node to download and verify all state tries. This will in general take significantly much longer than just downloading few blocks :(Īgain, you can read the whole details here: ethereum/go-ethereum#16251 (comment) So basically the problem is that the ethereum network protocol doesn't really have a clear overall picture of the maximum number of state tries.ĭownloading the few blocks normally will be finished pretty quickly with the fast sync mode (and it doesn't really matter too much for the initial sync if it is 0 blocks behind or if there are "just" 64 blocks left, that's just a tiny number of bytes, that's not the problem at all in general), but this is just the very beginning of the syncing phase.Īfter having "almost all" the blocks, the node needs to basically (very oversimplified!) know the balances of the different addresses and therefore need to download the state tries to verify all the state tries/transactions/balances. (within that post there is even a question for the 64/65 block misconception: "I'm stuck at 64 blocks behind mainnet?!") See: ethereum/go-ethereum#16251 (comment) go-ethereum (geth) for which mist is basically a GUI for has exactly the same problems! Well, first of all this is not really a mist (or ethereum wallet) problem, but an overall network protocol problem when using -fast sync.