Estoy tratando de configurar un nodo Ethereum. Lo he intentado tanto con geth como con Parity y parece que ambos tardan varios días. Estoy en un sistema de gama alta con Internet de fibra, por lo que me pregunto si esto es de esperar.
Las especificaciones de mi sistema son las siguientes:
Estoy ejecutando Ubuntu 16.06 con la versión Parity v1.10.2-beta-f4ae813-20180423/x86_64-linux-gnu/rustc1.25.0. El reloj está sincronizado.
Lancé Parity en primer lugar sin argumentos, esperé un par de días, luego ~/.local/share/io.parity.ethereumeliminé (alrededor de 70 GB iirc) e intenté nuevamente con:
parity --mode active --tracing off --pruning fast --db-compaction ssd --cache-size 1024
Esta vez ha estado funcionando durante unos 4 días y, según un cálculo rápido al dorso del sobre, tardará unos días más.
Con geth, sincronizaría rápidamente solo con los últimos 100 bloques (~ 70 GB) después de solo unas pocas horas, pero no alcanzaría los últimos 100 bloques en otras 24 horas. ¿Esto es normal?
Más de un día definitivamente no es habitual con su configuración. Le aconsejaría que use la bandera --warp-barrier NUM para especificar un bloque mínimo con el que desea sincronizar warp
Tenga en cuenta que algunos indicadores que utiliza para la paridad son los predeterminados y, por lo tanto, no son necesarios --mode active --tracing off --pruning fast.
~/.local/share/io.parity.ethereumy he reiniciado conparity --db-compaction ssd --cache-size 1024 --warp-barrier 5520000--db-compaction ssd --cache-size 1024 --warp-barrier 5520000y todavía estoy solo para bloquear 2,965,730 ... ¿alguna idea?--warp-barrierno debería volver a la sincronización normal. Le aconsejo que no deje que continúe con la sincronización normal tan pronto como vea que la sincronización warp está fallando, sino que intente nuevamente.
pulmónj