Hechos clave:
-
El proceso de sincronización del nodo de Bitcoin Core demoró 5 horas y 11 minutos.
-
El desarrollador también probó clientes de Ethereum y Monero, aunque descartó Ripple.
El desarrollador y especialista en Bitcoin, Jameson Lopp, publicó los resultados sobre una serie de pruebas que realizó a diferentes clientes de un nodo completo de Bitcoin y el tiempo que cada uno demora en sincronizarse con la cadena de bloques de esta criptomoneda, determinando que Bitcoin Core es el cliente en sincronizarse más rápidamente entre los evaluados. El desarrollador también examinó implementaciones de nodos completos de otras criptomonedas.
En total, Lopp realizó pruebas a 5 versiones de nodo completo de Bitcoin: Bitcoin Core, Libbitcoin Node, Bcoin, Parity Bitcoin y BTCD; además de tres pruebas en nodos de altcoins, concretamente con Parity y Geth, para Ethereum y monerod para Monero. Según su reporte, publicado este 1 de diciembre, consideró probar un nodo de Ripple pero descartó la posibilidad debido a la cantidad de espacio de disco que consume la data de esta cadena de bloques.
Según estas pruebas, el cliente de mejor rendimiento en cuanto a tiempo de sincronización es Bitcoin Core, con un tiempo de 5 horas y 11 minutos, casi cuatro veces más eficiente que su más cercano competidor, Libbitcoin Node, con un tiempo de sincronización de 20 horas y 24 minutos.
No obstante, Lopp señaló que pareciera que los desarrolladores no se han esforzado en crear versiones que aprovechen mejor las máquinas de alta potencia para la sincronización de la red, como en su caso. “En general, mi opinión es que no muchas implementaciones han puesto mucho esfuerzo en optimizar su código para aprovechar las máquinas de mayor nivel al ser más codiciosas con el uso de recursos”, señaló.
Lopp señaló que a pesar de haber ejecutado los clientes en los mismos equipos de hardware, para mantener el rendimiento estable de la sincronización, otros factores que afectan el desempeño de esta actividad entran en juego. Así mencionó que no hay forma de saber si su servicio de internet fue constante en todo momento durante la sincronización; que algunos clientes pueden tener usuarios con mayor ancho de banda que otros clientes; que no todos los clientes utilizan caché (recuperación rápida de la información utilizada con frecuencia); así como también menciona las diferencias en la indexación de información y los formatos de archivo, que pueden influir en ordenamiento de la data.
Pero el desarrollador no solo probó nodos de Bitcoin, sino que también realizó pruebas en las versiones de cliente de otras criptomonedas como Ethereum o Monero. Para todos estos exámenes, Lopp utilizó una PC Core i7 8700, de 3.2GHz 6 core CPU, 32 GB DDR4-2666 de RAM, con un procesador Samsung 960 EVO 1TB M.2 SSD.
¿Los resultados? De acuerdo con Lopp, la velocidad en la que se agregan datos a la cadena de bloques Ethereum supera significativamente la rapidez con la que se están mejorando las implementaciones de cliente de Parity y Geth para Ethereum.
La sincronización del nodo de Parity se demoró más de 3 días, mientras que la versión de Geth no puedo completarse, y además, “parece tener un error de consenso”, que parece haber pasado desapercibido porque muy pocas personas intentan ejecutarlo en modo de validación completa.
En cuanto a Monero, Lopp probó el cliente monerod, el cual debió ejecutar dos veces para poder configurarlo correctamente, incluso a pesar de tener el conocimiento técnico. En este caso, la sincronización tomó 20 horas y 16 minutos, destacando que parece que una “mejor lógica de red” podría producir una aceleración de casi 1.000% por ciento.
Además, Lopp destacó que esta implementación de nodo completo cuenta con un modo interactivo que se puede utilizar para cambiar la configuración del nodo mientras se está ejecutando, asegurando que se trata de un elemento “realmente útil” para estas pruebas de rendimiento.
El desarrollador enfatizó que si bien la data de las cadenas irá aumentando con el tiempo, así como la información necesaria para correr un nodo completo, los desarrolladores deben esforzarse en garantizar que estos recursos estén disponibles y que sean sencillos de manejar, asegurando que este es un gran desafío para una adopción mayor.
“La parte difícil es garantizar que estos requisitos de recursos no superen los avances en tecnología. Si lo hacen, entonces franjas cada vez más grandes de la población quedarán privados de la oportunidad de auto soberanía en estos sistemas”, sentenció.
Imagen destacada por sdecoret / stock.adobe.com
