geth v1.8无法下载主网网的最后65个块

Question

目前在SSD上运行Ubuntu17.10上的geth 1.8。每当我启动geth，它总是同步，直到它到达最后65个街区，它只是挂起来，看起来它仍然停留在下载链式结构。

像这样开始：geth --cache=4192

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

启动日志：

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

Answer 1

“最后65个街区”部分是正常的。当“快速同步”模式是第一次引进eth/63时，它甚至更多。

我建议你看一下公关，了解一下geth's --syncmode=fast到底做了什么。

简而言之:没有下载到头上的所有块，这样就可以很好地处理链重操作--特别是因为如果在同步时确实发生了reorg，则节点不会有任何更早的“状态快照”，而不是快速同步的枢轴块。

正如注释中提到的，在同步块到枢轴之后，节点还必须同步支点的状态--这需要一段时间，甚至可能比同步块还要长。

略为不：

在慢速机器(网络或存储IO方面)上，如果同步块花费的时间太长，到节点开始同步状态时，可能没有任何对等节点仍然拥有状态快照。(请记住，网络不仅仅是geth对等点；一些节点在历史状态保持方面可能有着截然不同的观点--以及什么是“历史的”。)

此时一个常见的错误是清除数据库后重新启动同步。先别那么做！否则，您将不得不再次下载这些块，可能会遇到相同的问题(一次又一次)。