Bitcoin Core 32.0 afronta sus últimas pruebas con el 10 de octubre en el horizonte
Bitcoin Core 32.0 llega al final de un ciclo de desarrollo donde los cambios más visibles no son necesariamente los más interesantes. La versión candidata ya está disponible y los desarrolladores apuntan al 10 de octubre para la versión final. En el menú: validación mejor organizada, servidor HTTP revisado y varias correcciones de seguridad. Una auditoría asistida por IA también inició una secuencia de pruebas bastante instructiva: el primer diagnóstico aún no había contado toda la historia.
En breve
- Bitcoin Core 32.0 se acerca a su lanzamiento tras varios meses de desarrollo, con una versión candidata sometida a las últimas pruebas de los contribuyentes.
- La validación de bloques evoluciona bajo el capó gracias a la carga paralela de ciertos datos, especialmente útil para los operadores que ejecutan sus propios nodos.
- Kimi K3 ayudó a detectar una debilidad del servidor HTTP, antes de que un desarrollador descubriera que el escenario podía afectar a más conexiones.
- La corrección misma requirió varios ajustes, ya que su primera versión protegía la memoria pero introducía una latencia molesta en algunas conexiones persistentes.
- Para el usuario común, el cambio será mayormente invisible, mientras que desarrolladores y operadores se beneficiarán principalmente de una infraestructura mejor protegida y más organizada.
Más agilidad al validar bloques sin tocar el funcionamiento de Bitcoin
Bitcoin Core permite a una computadora verificar por sí misma las transacciones y los bloques de la red, sin tener que delegar esta tarea a un servicio externo. La versión 32.0 afecta principalmente a los operadores de nodos, a los desarrolladores y a los servicios construidos alrededor de esta infraestructura.
El cambio de rendimiento más significativo concierne a la validación de bloques. Para verificar una transacción, el software debe encontrar específicamente las salidas anteriores que consume, los famosos prevouts. Cuando se encuentran en disco, su lectura puede ralentizar el trabajo. La nueva versión permite precargar estos datos en paralelo desde la base chainstate.
Por defecto, ocho hilos trabajan, con un máximo fijado en dieciséis. Una máquina más modesta podrá reducir este número a cero y desactivar el mecanismo.
La ganancia no hará que la blockchain sea más rápida ni reducirá el intervalo entre dos bloques. Afecta el trabajo realizado localmente por el nodo. Una diferencia técnica, ciertamente discreta en pantalla, pero bastante concreta para quienes mantienen la infraestructura día tras día.
Una auditoría con IA da la pista y los desarrolladores tiran del hilo
La historia comienza con Matthew Zipkin, contribuyente conocido bajo el seudónimo pinheadmz. Al auditar el nuevo servidor HTTP con Kimi K3, un modelo de inteligencia artificial también utilizado por el Bitcoin Red Team, se topó con un escenario de agotamiento de memoria.
El servidor podía continuar leyendo los datos enviados por un cliente mientras ya procesaba una solicitud. Un cliente malintencionado tenía así la posibilidad de mantener esta solicitud ocupada y luego enviar cada vez más datos. Estos se acumulaban en la memoria.
Zipkin primero pensó que el ataque requería autenticación. Luego, la revisión del código cambió el panorama. El desarrollador jeanpablojp probó la interfaz REST y constató que 16 conexiones sin credenciales podían hacer que el consumo del nodo pasara de unos 46 MB a cerca de 3 GB en un minuto.
La IA había detectado un problema. No había cerrado la investigación. Un humano llevó la prueba más allá y descubrió un vector más amplio. Una colaboración hombre-máquina mucho más interesante que un simple duelo para ver quién encuentra más errores.
Corregir el problema de memoria abrió otro frente
La primera respuesta de Zipkin seguía una lógica bastante sencilla: cuando una solicitud ya está siendo procesada, no es necesario seguir cargando los datos siguientes en la memoria de la aplicación. Estos pueden esperar en el sistema hasta que la presión TCP frene naturalmente al emisor.
La solución de este parche consiste en no leer ni siquiera el socket cuando estamos ocupados procesando una solicitud.
Matthew Zipkin, GitHub PR #36123
Sin embargo, el primer parche tenía un defecto. En una conexión persistente, jeanpablojp midió una latencia mediana que pasó de aproximadamente 0,14 ms a 53 ms. La corrección protegía la memoria, pero hacía esperar innecesariamente ciertas solicitudes.
Nueva versión, nuevas pruebas. Tras revisión, 16 conexiones REST no autenticadas añadían sólo unos 3 MB en 90 segundos, frente a los 3,2 GB anteriores. La penalización de unos 50 ms también desaparece.
No todo es gratis, sin embargo. En un nodo inactivo sometido a un pipeline continuo, un revisor midió un flujo que bajó de 383 a 18,9 solicitudes por segundo. Un caso muy específico, que dice no encontrar en ningún cliente real. La seguridad gana claramente, con un compromiso medido en vez de oculto.
Lo que cambiará para los operadores de nodos en octubre
La versión 32.0 no se reduce a esta historia de memoria. Varios cambios menos espectaculares llegarán con ella si el calendario se cumple. Cuatro comandos relacionados con transacciones parcialmente firmadas usarán PSBT v2 por defecto. Las aplicaciones que lo necesiten aún podrán solicitar la versión anterior.
El servidor HTTP fue reescrito para reemplazar libevent. Aplica reglas más estrictas y limita por defecto a dieciséis el número de clientes HTTP conectados simultáneamente. Otra optimización apreciable: tras la reconstrucción, el índice de transacciones txindex ocupará menos de la mitad de su espacio de disco anterior.
En cuanto a la cartera, exportwatchonlywallet permitirá exportar la información necesaria para una cartera de observación sin llevar las claves privadas.
Una corrección también cierra la falla walletnotify. En sistemas distintos a Windows, un usuario RPC autenticado con los permisos requeridos podía fabricar ciertos nombres de carteras para provocar la ejecución de comandos. Ahora estos nombres se tratan literalmente.
Para el usuario de una aplicación ligera, nada de esto cambiará su día. Para quienes ejecutan los nodos de la blockchain, los detalles importan más.
Para recordar antes del 10 de octubre
- El lanzamiento de Bitcoin Core 32.0 apunta al 10 de octubre de 2026, una fecha que puede cambiar durante las últimas pruebas de la versión candidata.
- La validación podrá precargar ciertos datos con ocho hilos por defecto y dieciséis como máximo, sin modificar el ritmo de producción de bloques.
- Tras la corrección, 16 conexiones REST no autenticadas añadían unos 3 MB de memoria en 90 segundos, frente a los 3,2 GB antes de la revisión.
- Cuatro comandos de cartera adoptarán PSBT v2 por defecto, mientras que las aplicaciones conservarán la opción de solicitar la versión anterior.
- Un txindex completamente reconstruido ocupará menos de la mitad del espacio en disco, mientras el nuevo servidor HTTP recibe varias salvaguardas adicionales.
El calendario ofrece además un cruce interesante. Mientras Bitcoin Core apunta a octubre, Ethereum prepara Glamsterdam, la próxima evolución importante de su blockchain. Sepolia debe acoger una prueba el 6 de octubre, si se corrigen los errores aún presentes en los devnets. El mainnet sigue esperado en el cuarto trimestre, con diciembre aún posible. Dos proyectos diferentes, un mismo método: probar, romper a veces, corregir mucho y sólo luego lanzar.
¡Maximiza tu experiencia en Cointribune con nuestro programa "Read to Earn"! Por cada artículo que leas, gana puntos y accede a recompensas exclusivas. Regístrate ahora y comienza a acumular beneficios.
¡La revolución blockchain y cripto está en marcha! Y el día en que los impactos se sientan en la economía más vulnerable del mundo, contra toda esperanza, diré que fui parte de ella
Las ideas y opiniones expresadas en este artículo pertenecen al autor y no deben tomarse como consejo de inversión. Haz tu propia investigación antes de tomar cualquier decisión de inversión.