Los desarrolladores de Bitcoin Core han llevado la versión 32.0 a pruebas de candidato a lanzamiento, con el software estable programado para un posible lanzamiento el 10 de octubre tras semanas de comprobaciones públicas.
Resumen
- Bitcoin Core 32 entró en pruebas de candidato a lanzamiento el 14 de septiembre tras una congelación de funciones en agosto.
- Las lecturas paralelas de la base de datos podrían reducir los tiempos de validación de bloques sin cambiar la tasa de producción de bloques de Bitcoin.
- Cuatro comandos de billetera usarán PSBT versión 2 por defecto mientras conservan el formato anterior.
- Las correcciones de seguridad abordan nombres de billetera inseguros y solicitudes HTTP no autenticadas que causaban un uso intensivo de memoria.
Bitcoin Core 32 apunta a un lanzamiento el 10 de octubre
El calendario de lanzamiento oficial de Bitcoin Core muestra que los desarrolladores crearon la rama de la versión 32 y comenzaron el ciclo de candidato a lanzamiento el 14 de septiembre. El primer candidato, conocido como v32.0rc1, ya está disponible para pruebas antes de que los desarrolladores decidan si etiquetar el lanzamiento estable.
El proyecto fijó el 10 de octubre como la fecha prevista para la versión 32.0, aunque el calendario lo describe como un objetivo en lugar de una fecha límite confirmada. Los problemas encontrados durante las pruebas del candidato podrían requerir lanzamientos adicionales y retrasar la versión final.
Los preparativos comenzaron meses antes. Los desarrolladores abrieron las traducciones e introdujeron una congelación suave de los cambios de traducción el 6 de agosto, seguida de una congelación de funciones el 20 de agosto. A partir de esa fecha, la rama de la versión 32 aceptó correcciones de errores pero no nuevas funciones antes de las pruebas finales.
Cuando la rama se separó del código base principal el 14 de septiembre, también comenzó el desarrollo de Bitcoin Core 33 en la rama principal. La separación permite a los contribuyentes probar y reparar el próximo lanzamiento sin detener el trabajo en la siguiente versión.
Los candidatos a lanzamiento dan a los operadores de nodos, desarrolladores de billeteras y otros usuarios tiempo para encontrar errores en diferentes condiciones de hardware y software. El proceso de pruebas de Bitcoin Core cubre funciones que incluyen validación de bloques, comunicación entre pares, operaciones de billetera y llamadas a procedimientos remotos utilizadas por aplicaciones conectadas a un nodo.
Las lecturas paralelas de la base de datos aceleran las comprobaciones de bloques
Uno de los principales cambios de rendimiento permite a Bitcoin Core leer datos de su base de datos en paralelo mientras verifica bloques. El método puede acortar el tiempo de validación porque el software ya no tiene que completar cada lectura relevante de la base de datos una tras otra.
Una validación más rápida no significa que Bitcoin producirá bloques más rápidamente. Los mineros siguen compitiendo para agregar bloques bajo las reglas de prueba de trabajo de Bitcoin, que apuntan a un intervalo promedio de aproximadamente 10 minutos. La versión 32 cambia cómo un nodo procesa la información requerida en lugar del calendario de emisión o el tiempo de bloques de la red.
La distinción importa porque Bitcoin Core es software de nodo, no una actualización gestionada centralmente de la red Bitcoin. Los operadores deciden qué versión instalar, y el lanzamiento no reemplaza automáticamente el software que se ejecuta en cada nodo.
La versión 32 tampoco introduce una nueva regla de consenso ni requiere un soft fork. Su proceso de lanzamiento difiere de los cambios de protocolo que necesitan coordinación entre mineros, operadores de nodos y otros participantes de la red.
Como informó previamente crypto.news, el CEO de LayerTwo Labs, Paul Sztorc, dijo que cada soft fork propuesto de Bitcoin desde Taproot ha fallado en activarse. BIP-110, una propuesta disputada vinculada a la política de retransmisión de transacciones, recibió un 2.53% de apoyo de mineros antes de que su rama de aplicación se estancara después de dos bloques.
Bitcoin Core 32 puede por lo tanto mejorar el rendimiento del software sin depender del proceso de activación requerido para un cambio de consenso. Los operadores de nodos siguen siendo libres de probar el candidato, continuar usando una versión anterior o instalar la versión estable después de su publicación.
Los comandos de billetera adoptan el formato PSBT más reciente
Las funciones de billetera representan otro conjunto de cambios en la versión 32. Cuatro comandos crearán transacciones de Bitcoin parcialmente firmadas usando PSBT versión 2 por defecto, según los detalles compartidos por Bitcoin News.
Un PSBT permite a billeteras, dispositivos o participantes separados intercambiar la información necesaria para construir y firmar una transacción de Bitcoin sin exponer claves privadas. El formato se usa comúnmente con billeteras de hardware, configuraciones de firma fuera de línea y transacciones que requieren más de una firma.
La versión 2 de PSBT cambia cómo se organiza la información de la transacción y permite a los participantes actualizar partes de una transacción sin crear primero una transacción sin firmar completa. El formato PSBT anterior seguirá disponible cuando los usuarios o las aplicaciones conectadas lo requieran.
Mantener ambas versiones reduce la posibilidad de romper abruptamente carteras y servicios que no han adoptado el formato más nuevo. Los desarrolladores que integren Bitcoin Core con otro software aún tendrán que verificar si sus sistemas esperan el valor predeterminado anterior.
Para los tenedores individuales, el cambio no altera los saldos de Bitcoin, las claves privadas ni las reglas que rigen las transacciones válidas. Su efecto práctico recae en los flujos de trabajo de las carteras y las aplicaciones que llaman a los comandos afectados.
Las correcciones de seguridad reducen los riesgos de comandos y memoria
La versión 32 también incluye un parche para nombres de cartera personalizados que podrían provocar que los comandos se ejecuten en nodos que no son Windows. El problema concernía a cómo interactuaban los nombres especialmente construidos con la ejecución de comandos, en lugar de un cambio en la criptografía subyacente de Bitcoin.
Una corrección separada aborda el crecimiento de memoria causado por actividad HTTP no autenticada. En una prueba citada por Bitcoin News, el uso de memoria alcanzó aproximadamente 3,2 gigabytes antes del parche, en comparación con aproximadamente 3 megabytes después de que los desarrolladores aplicaran el cambio.
Las interfaces remotas permiten que otros programas se comuniquen con Bitcoin Core, lo que hace que los controles de memoria sean relevantes para los operadores que exponen servicios de nodo a aplicaciones conectadas. La configuración de acceso, los firewalls y la autenticación siguen siendo partes separadas de la seguridad de una implementación.
Para los usuarios estadounidenses, el candidato es más relevante para los operadores de nodos, proveedores de carteras, exchanges, mineros y empresas de infraestructura que ejecutan Bitcoin Core en sus sistemas. El lanzamiento no cambia el tratamiento de la SEC de los productos cotizados en bolsa de Bitcoin al contado, las reglas fiscales para inversores ni el estatus legal de BTC.
Las empresas financieras estadounidenses también han aumentado su apoyo al trabajo de seguridad de código abierto de Bitcoin. En julio, Anchorage Digital, ARK Invest, BlackRock, Block, Blockstream, Coinbase, Fidelity Digital Assets, Galaxy y Strategy formaron el Bitcoin Security Consortium con 15 millones de dólares en promesas durante tres años.
Según el anuncio del consorcio, cada miembro dirigirá su financiación de forma independiente en lugar de depositar el dinero en un fondo común. El grupo dijo que no controlará el desarrollo de Bitcoin, no tomará posiciones sobre propuestas de protocolo específicas ni hablará en nombre de los contribuyentes del proyecto.
Mike Schmidt, director ejecutivo de la organización sin fines de lucro de financiación de desarrolladores de Bitcoin, Brink, coordina el trabajo diario del consorcio en un rol voluntario. Su enfoque inicial es la investigación sobre problemas de seguridad a largo plazo, incluidas las protecciones contra futuros riesgos de computación cuántica.
