-
La mejora surge de delegar a la GPU el 99,5% de las firmas de la red.
-
Antes de este salto, la validación completa de Libbitcoin tomaba 99 minutos (1,66 horas).
El equipo detrás de Libbitcoin Server, un software de nodo completo de Bitcoin, redujo a 55 minutos el tiempo que le toma a un nodo descargar y validar por completo la cadena de bloques.
Fue el desarrollador Eric Voskuil, quien integra ese equipo, quien reportó los avances en su cuenta de X el 21 de julio de 2026, y precisó que la marca reduce en 20 minutos al mejor tiempo que logran usando solo el procesador (CPU), sin apoyo de la tarjeta gráfica (GPU).
Horas más tarde, ese mismo día, llegó un segundo anuncio: una sincronización de tipo «assume valid» hasta el bloque 950.000 en apenas 14 minutos.
Para entender por qué estas dos cifras conviven —y por qué una es tan distinta de la otra— hay que empezar por lo que hace, en el fondo, un nodo cuando se enciende por primera vez.
Dos formas de sincronizar un nodo de Bitcoin
Cuando un nodo de Bitcoin arranca desde cero, debe descargar y procesar toda la cadena de bloques, un proceso que se conoce como IBD (Initial Block Download).
Ese proceso admite dos caminos. La validación completa revisa una por una las firmas criptográficas de cada transacción desde el bloque génesis: es el método más sólido en términos de seguridad, pero también el más lento.
El modo «assume valid«, en cambio, asume que los bloques anteriores a un punto de la cadena ya fueron validados por el resto de la red, y se salta esa revisión exhaustiva para sincronizar mucho más rápido.
Esa diferencia explica por qué, a lo largo de la semana que documentó Voskuil, los tiempos de «assume valid» (14, 23,5 o 27,9 minutos, según el anuncio) fueron siempre más cortos que los de validación completa (55, 59 u 87,5 minutos): son dos procesos distintos, no la misma medición con nombres diferentes.
El punto de partida: una comparación con Bitcoin Core
La seguidilla de anuncios que terminó en los 55 minutos arrancó, en realidad, a partir de un comentario ajeno. El 16 de julio, el desarrollador Jameson Lopp señaló en X que la próxima versión de Bitcoin Core, la v32, sincronizará entre un 30% y un 40% más rápido gracias a mejoras de paralelización en el procesamiento. Otro usuario le preguntó a Voskuil qué opinaba de esos números.
Vale aclarar que sincronizar un nodo de Bitcoin Core desde cero implica hoy procesar más de 700 GB de datos de bloques y verificar cientos de millones de transacciones, y el tiempo total puede ir de menos de una hora a más de dos semanas según el hardware, la configuración de software y el método de sincronización elegido.
Voskuil le respondió a Lopp, con la salvedad de que era su interpretación («si entiendo bien»), que esas cifras correspondían a pruebas de laboratorio en red local y no a condiciones reales de Internet, y agregó que limitar las pruebas a hardware de una década de antigüedad favorece al código secuencial al ocultar sus límites.
Según él, Libbitcoin ya alcanzaba de forma consistente 34 minutos para el modo «assume valid» y 1,9 horas para validación completa, en ambos casos por Internet. Ese mismo día actualizó esa segunda marca: la validación completa había bajado a 1,66 horas.
Una seguidilla de récords en cinco días
A partir de ahí, los anuncios se sucedieron casi a diario. El 17 de julio, con el índice completo de direcciones de Electrum habilitado (además de los de transacciones y gastadores, que de acuerdo a Voskuil ya venían incluidos), reportó una nueva marca de sincronización de 44,8 minutos. Al día siguiente, 18 de julio, con una conexión de 2,5 Gbps, el tiempo de «assume valid» bajó a 27,9 minutos. Un día después, el 19 de julio, con esa misma conexión, la validación completa llegó a 88,4 minutos.
La madrugada del 20 de julio trajo un nuevo salto: usando dos conexiones combinadas de 2,3 Gbps, el «assume valid» cayó a 23,5 minutos, una cifra que el propio Voskuil calificó como cercana al límite teórico de esas conexiones que es de unos 22 minutos, contando los 30 segundos que toma sincronizar los encabezados.
Esa misma madrugada, Voskuil sumó otro anuncio, esta vez sobre el diseño interno del software: aseguró que el aspecto de sincronización del nodo (equiparable al modo «assume valid«) quedó completamente libre de contención de bloqueos, lo que en teoría permitiría escalarlo sin límite hasta 100 Gbps, lo que significa una velocidad con la que la cadena actual se sincronizaría en apenas 60 segundos. Todo esto, según dijo, usando el mismo hardware que ya tienen.
El motor detrás de los récords: firmas verificadas por GPU
Para entender de dónde sale la mejora, hay que saber qué es lo que más tiempo consume durante la validación completa: revisar, una por una, todas las firmas criptográficas de la cadena de bloques.
Ese trabajo normalmente lo hace el procesador (CPU). Lo que cambió esta semana es que Libbitcoin empezó a delegar ese trabajo, por lotes, a la tarjeta gráfica (GPU), que puede procesar muchas firmas al mismo tiempo en lugar de una por una.
El 20 de julio, Voskuil dijo que el software ya logra derivar a la GPU el 99,5% de las firmas de toda la red (unas 4.000 millones en la cadena principal). Aun así, aclaró algo importante: en ese momento, ese método todavía no era más rápido que las computadoras con CPU más potentes que tiene el equipo. Su valor, explicó, era otro: permitiría lograr validaciones rápidas también en equipos con GPU más modestas y económicas, sin necesitar una CPU de gama alta.
Horas más tarde, ese mismo día, llegó un nuevo récord usando solo CPU (sin GPU): 87,5 minutos para completar la validación total.
Pero la ventaja de la CPU no duró mucho. Tras ajustar cómo el sistema captura y evalúa las firmas, la validación completa con ayuda de la GPU bajó a 59 minutos, superando ya al método tradicional.
Tal resultado fue el paso previo al anuncio del 21 de julio, con el que arranca esta noticia: los 55 minutos que Voskuil describió como 20 minutos más rápidos que el mejor tiempo que logra el equipo usando solo CPU.
