geth v1.8 無法下載主網的最後 65 個區塊

目前在 SSD 上的 Ubuntu 17.10 上執行 geth 1.8。每當我開始 geth 時，它都會一直同步，直到它到達最後 65 個塊，它剛剛掛起，看起來它一直停留在下載鏈結構。

像這樣開始geth：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

“最後 65 個塊”部分是正常的。當“快速同步”模式首次引入時eth/63，它甚至更多。

我建議您查看該 PR 以了解有關 實際作用的一般geth描述--syncmode=fast。

簡而言之：沒有將所有塊下載到頭部，以便可以優雅地處理鏈重組 - 特別是因為如果重組**確實發生在你的時間，節點將沒有任何更早的“狀態快照”來恢復。重新同步，早於您快速同步到的樞軸塊。

正如評論中提到的，在將塊同步到樞軸之後，節點還必須同步樞軸處的狀態——這幾天需要一段時間，甚至可能比同步塊更長。

---

略OT：

在慢速機器（網路或儲存 IO 方面）上，如果同步塊花費的時間太長，當節點開始同步狀態時，可能沒有任何對等節點實際上仍然擁有它的快照。（請記住，網路不僅僅是geth對等點；一些節點可能對歷史狀態保留有完全不同的看法——以及什麼被認為是“歷史性的”。）

此時的一個常見錯誤是清除數據庫後重新啟動同步。嘗試不先這樣做！否則，您將不得不再次下載這些塊，可能會遇到相同的問題（一遍又一遍）。

引用自：https://ethereum.stackexchange.com/questions/40070