Actualmente ejecuta geth 1.8 en Ubuntu 17.10 en un SSD. Cada vez que empiezo geth, siempre se sincronizará hasta que llegue a los últimos 65 bloques, donde simplemente se cuelga y parece que se queda atascado en la descarga de la estructura de la cadena.
Comenzó geth así:geth --cache=4192
> eth.syncing
{
currentBlock: 5111107,
highestBlock: 5111172,
knownStates: 334023,
pulledStates: 319685,
startingBlock: 5105310
}
registros de inicio:
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
La parte de los "últimos 65 bloques" es normal. Cuando se introdujo por primera vezeth/63 el modo de "sincronización rápida" , fue aún más.
Le sugiero que eche un vistazo a ese PR para obtener una descripción general de lo que gethrealmente --syncmode=fasthace.
En resumen: no se descargan todos los bloques hasta la cabeza para que las reorganizaciones en cadena se puedan manejar con gracia, especialmente porque el nodo no tendrá ninguna "instantánea de estado" anterior a la que volver si ocurre una reorganización en el tiempo que usted volver a sincronizar, antes que el bloque pivote con el que está sincronizando rápidamente.
Como se menciona en los comentarios, después de sincronizar los bloques con el pivote, el nodo también debe sincronizar el estado en el pivote, lo que en estos días lleva un tiempo, tal vez incluso más que sincronizar los bloques.
Ligeramente OT:
En máquinas lentas (red o almacenamiento en cuanto a E/S), si la sincronización de bloques lleva demasiado tiempo, en el momento en que un nodo comience a sincronizar el estado, es posible que no haya pares que aún tengan una instantánea de él. (Recuerde, la red no es solo gethpares; algunos nodos pueden tener una perspectiva radicalmente diferente sobre la retención del estado histórico, y lo que debe considerarse "histórico").
Un error común en este punto es reiniciar la sincronización después de borrar la base de datos . ¡Prueba sin hacer eso primero! De lo contrario, tendrás que descargar los bloques nuevamente, probablemente te encuentres con el mismo problema (una y otra vez).
ismael
hexteto