Currently running geth 1.8 on Ubuntu 17.10 on an SSD. Anytime I start geth, it will always sync until it hits the last 65 blocks where it just hangs and looks like it stays stuck at downloading the chain structure.

Started geth like so: geth --cache=4192

> eth.syncing
  currentBlock: 5111107,
  highestBlock: 5111172,
  knownStates: 334023,
  pulledStates: 319685,
  startingBlock: 5105310

startup logs:

INFO [02-17|22:47:12] Maximum peer count                       ETH=50 LES=0 total=50
INFO [02-17|22:47:12] Starting peer-to-peer node               instance=Geth/v1.8.0-stable/linux-amd64/go1.8.3
INFO [02-17|22:47:12] Allocated cache and file handles         database=/media/solidity/Data/mainnet/geth/chaindata cache=3144 handles=512
INFO [02-17|22:47:22] Initialised chain configuration          config="{ChainID: 1 Homestead: 1150000 DAO: 1920000 DAOSupport: true EIP150: 2463000 EIP155: 2675000 EIP158: 2675000 Byzantium: 4370000 Engine: ethash}"
INFO [02-17|22:47:22] Disk storage enabled for ethash caches   dir=/media/solidity/Data/mainnet/geth/geth/ethash count=3
INFO [02-17|22:47:22] Disk storage enabled for ethash DAGs     dir=/home/solidity/.ethash                        count=2
INFO [02-17|22:47:22] Initialising Ethereum protocol           versions="[63 62]" network=1
  • Geth after downloading blocks will start downloading 'states' until that is complete it will not be finished.
    – Ismael
    Commented Feb 19, 2018 at 1:08
  • Even though it doesn't download the final 65 blocks before it starts downloading? Will it download the final blocks after it finishes downloading the states?
    – hextet
    Commented Feb 19, 2018 at 5:50

1 Answer 1


The "last 65 blocks" part is normal. When the "fast sync" mode was first introduced in eth/63, it was even more.

I suggest you take a look at that PR for a general description on what geth's --syncmode=fast actually does.

In short: not downloading all the blocks up to the head is done so that chain reorgs can be handled gracefully - especially since the node won't have any earlier "state snapshot" to revert to if a reorg does happen in the time you're syncing, earlier than the pivot block that you're fast-syncing to.

As is mentioned in the comments, after syncing blocks up to the pivot, the node has to also sync the state at the pivot, - which these days takes a while, perhaps even longer than syncing the blocks.

Slightly OT:

On slow machines (network or storage IO-wise), if syncing blocks takes too long, by the time a node would start syncing the state, there might not be any peers that actually still have a snapshot of it. (Remember, the network is not just geth peers; some nodes might have a radically different outlook on historic state retention - and what's to be considered "historic".)

A common mistake at this point is restarting the sync after clearing the database. Try without doing that first! Otherwise, you'll have to download the blocks again, likely running into the same issue (over and over).

  • Awesome thanks this makes perfect sense, i'll take a look at the PR.
    – hextet
    Commented Feb 20, 2018 at 6:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.