¿Algo que se pueda hacer con respecto a la sincronización de paridad lenta?

Intenté restablecer la sincronización y todavía se detiene alrededor del bloque número 2.4m. Sé sobre los ataques a Ethereum alrededor de esos bloques, pero esto es ridículo: súper lentohe estado sincronizando durante 4 días, el primer día pasé del #0 a alrededor de #2.2m, el segundo día llegué a ~#2.4m y el los últimos 2 días ni siquiera ha llegado a la mitad de #2.5m. ¿No se supone que Parity es significativamente más rápido que esto? Intenté sincronizar con Geth primero y se atascó permanentemente en 141 cuadras restantes en el mismo tiempo que tomó la paridad para reducir la velocidad a un estacionamiento de la autopista. Ahora ni siquiera puedo hacer que Geth vuelva a donde estaba, ya que lo restablecí de todos modos. ¿Hay alguna otra opción para sincronizar esto más rápido? ¿Como descargar la copia de la cadena de bloques de otra persona o algo así? Así es como ejecuto Parity:parity --min-peers=50 --max-peers=100 --cache 4096 --geth

Actualización: al final del sexto día, volvió a acelerar porque superó el rango problemático. Ahora está estancado nuevamente con menos de 200k bloques restantes. Me yay. ¿Algunas ideas?

Respuestas (3)

Hablo en serio cuando digo que lo mejor que puedes hacer es ser paciente. Mientras obtenga nuevos bloques, no hay mucho que hacer. Si, por otro lado, Parity continúa informando el mismo bloque, entonces puede eliminarlo y reiniciarlo.

Los bloques entre aproximadamente ~2286900 y ~271800 son muy, muy lentos debido al ataque DDOS en septiembre/octubre de 2016. Lo que sucede es que los bloques duran mucho tiempo, por lo que si mata repetidamente el nodo mientras procesa un bloque y lo reinicia, estás haciendo que tome mucho más tiempo porque tiene que empezar de nuevo en ese bloque. Una vez que pasa ~ 271800, debería acelerarse nuevamente.

Me quedan menos de 2k. Por cada 1 bloque sincronizado, se crean 2 más, hasta que me acerco a ~ 1600 bloques restantes y se reduce a ~ 1400. Se está volviendo ridículo ver el número subir y bajar entre 1400 y 1600. Estoy a punto de decir al diablo con Ethereum porque es muy lento. La última vez que usé BTC o LTC tardé unos 4 días en sincronizar el cliente de stock. ¿¡¿No hay electrum para ethereum?!?
es brutal Lo admito. Me acabo de dar cuenta de que Parity cerró un montón de problemas relacionados con la base de datos, así que tal vez haya esperanza con el próximo lanzamiento. Siento no poder ser de más ayuda.
¿Qué hace que esos bloques sean lentos hasta el día de hoy para sincronizarse? Un nuevo nodo de paridad de archivo en 2.1.4 se ralentiza en ese rango de bloques, pero solo procesa alrededor de 0,5 blk/s y 2,5tx/s. No es que haya mil millones de pequeñas transacciones que deban validarse... de hecho, la paridad apenas valida ningún txn...
Investigué un poco más, era un DDoS que creaba millones de cuentas y rastros falsos lo que causaba lentitud, no el número bruto de txns en sí. Más información aquí: medium.com/@tjayrush/… y aquí: ethereum.stackexchange.com/questions/9883/…

Parece que es este problema continuo . Antes de que se arregle por completo, probablemente pruebe algunas de las soluciones alternativas sugeridas en ese hilo (no necesariamente funcionará, ninguna funcionó para mí).

Estoy en la recta final en este momento sincronizando con Parity v1.7.3 y ha estado funcionando durante casi 24 horas. A su velocidad actual de alrededor de 2-5 blks/s, probablemente le queden otras 20 horas. Estoy de acuerdo con las respuestas actuales en que solo tienes que esperar. En mi investigación, he visto muchas respuestas centradas en la computadora, especialmente en el HDD, pero claramente me parece que esto es una limitación de los pares de la red Ethereum.

Cuando lo piensas, obtienes esos datos poco a poco de pares distribuidos. No es nada como descargar un archivo grande de un servidor. Mi sistema está conectado con unos 25 pares. Esos son nodos que probablemente estén muy ocupados tratando de minar Eth y no se van a enfocar en ponernos al día para que podamos competir con ellos. No digo que hayan alterado su código, pero una revisión del código podría ayudar a explicar la lentitud de la sincronización.

Escuché que puede encontrar archivos comprimidos de los bloques posteriores y descargar el archivo e instalarlo para sincronizarlo más rápidamente. Alguien sabe si eso funciona?

Si está utilizando un HDD, a la larga probablemente estará peleando una batalla perdida. También tenga en cuenta que el problema no es necesariamente escribir los datos sin procesar en el disco a medida que salen de la línea: es la E/S asociada con la reproducción/verificación de todo en los datos de estado, que es invariable con cualquier cosa relacionada con los pares o la descarga. Incluso si pudiera descargar los datos comprimidos de una sola fuente, aún verá cantidades masivas de E/S al verificar los datos de la transacción.
Estoy usando un SSD. El uso de recursos por administrador de tareas es prácticamente constante en aproximadamente un 50 % de uso del SSD y aproximadamente lo mismo para la memoria (8 GB de 16 GB). La CPU se mantiene alrededor del 20%. Pero los bloques varían con el tiempo y ahora están cayendo. Esta mañana, ahora que se está acercando, la tasa ha bajado a 1 o 2 blk/s. La tasa de procesamiento de bloques no parece correlacionarse con el uso de recursos locales. Mi conexión a Internet es FIOS a casi 1 gb/s. ¿El único otro factor que se me ocurre sería la red de pares?
¿Algo que se pueda hacer con respecto a la sincronización de paridad lenta?
RespuestasAquíPolítica de privacidad1y, 0v