Estrellarse

La ventana de señalización del hard fork V24 de Dash en la red principal comenzó a las 7 p. m. ET del domingo 8 de noviembre (00:00 UTC del 9 de noviembre). Las notas de la versión v24.0.0 habían indicado a todos los operadores de masternodes y evonodes que debían ejecutar Dash Core v24.0.0 antes de ese momento. Los masternodes que continúen usando versiones anteriores dejarán de contar para el quórum del 85% que debe aprobar la activación. Además, las notas señalan que serán votados como defectuosos durante la generación distribuida de claves y recibirán sanciones de Proof of Service (PoSe). Los desarrolladores proyectan que la activación podría producirse, como muy pronto, en el bloque 2.580.480, alrededor del 28 de noviembre.

La distinción es importante porque el umbral decreciente que permite a V24 recuperarse de una adopción lenta se aplica a los mineros. La señalización de los masternodes es un filtro separado: el documento de diseño DIP-0023 describe el umbral decreciente únicamente para los ciclos de señalización de los mineros, mientras que la señal de los masternodes proviene de un quórum que se forma cuando aproximadamente el 85% de ellos se ha actualizado.

Los masternodes sin V24 salen del quórum del 85% y arriesgan sanciones

Dash opera con una red de dos niveles: los mineros producen los bloques, mientras que los masternodes —con una garantía de 1.000 DASH— y los evonodes —con 4.000 DASH y encargados también de alojar Dash Platform— prestan servicios como InstantSend y ChainLocks, según la documentación de masternodes de Dash. V24 utiliza ese segundo nivel como filtro. La señal de activación es una transacción especial firmada por un quórum de masternodes de larga duración denominado LLMQ_400_85, y el 85% de sus integrantes debe ejecutar v24, es decir, 340 de los 400 miembros. Un masternode que no se haya actualizado deja de contar para ese umbral.

Las notas de la versión describen también las sanciones: los masternodes antiguos son votados como defectuosos durante la generación distribuida de claves y reciben penalizaciones PoSe. Según la documentación de Dash, un masternode que alcanza el límite de sanciones queda bloqueado hasta que el operador lo repare y lo registre nuevamente. En la práctica, la actualización se hace cumplir desde el interior de la red: los masternodes rezagados son sancionados y solo los actualizados cuentan para el umbral que activa el fork.

El umbral decreciente de los mineros baja del 80% al 60%, mientras se mantiene el filtro de los masternodes

El esquema de bits de versión de Bitcoin, BIP 9, activa un cambio cuando el 95% de los bloques de un periodo de 2.016 bloques señala su respaldo. El mecanismo de hard fork mejorado de Dash, especificado en el DIP-0023, modifica ese diseño de dos maneras. Primero, añade la señal de los masternodes descrita anteriormente, que debe existir antes de que comience la etapa de los mineros. Segundo, la señalización de los mineros se desarrolla en ventanas de 4.032 bloques —unos siete días con el tiempo de bloque de 2,5 minutos de Dash— y la proporción exigida baja en cada ventana.

Para V24, la solicitud de cambios fija el umbral inicial en 80% (3.226 de 4.032 bloques) y establece que descenderá hasta 60% (2.420 bloques) a lo largo de 10 ventanas. La solicitud indica que cada ventana que no se cumpla retrasa la activación aproximadamente siete días. En ese sentido, una adopción lenta retrasa la actualización en lugar de hacerla fracasar, pero esto solo aplica a los mineros. La falta de masternodes actualizados no está cubierta por esa reducción, porque el requisito del 85% pertenece al quórum, no a las ventanas de los mineros. Esa interpretación se desprende de la descripción de la reducción en el DIP, que se limita a la etapa de los mineros; ni el DIP ni las notas de la versión lo dicen expresamente.

La solicitud de cambios asigna el bit 13 a v24 y el bit 14 a un segundo despliegue denominado evo_shares, ambos con las mismas fechas de inicio y vencimiento. La versión v24.0.0 no señala a favor de evo_shares. The Merkle informó que la garantía compartida de los EvoNode y los pagos divididos se esperan en una versión v24.1 posterior. El despliegue vence el 9 de noviembre de 2028, lo que da a esa versión posterior dos años para participar.

¿Cuándo se activa Dash V24? El 28 de noviembre es la fecha proyectada más temprana, no un plazo fijo

La solicitud de cambios enumera tres alturas de bloque, todas múltiplos exactos de 4.032: 2.572.416 para el estado STARTED, 2.576.448 para LOCKED_IN y 2.580.480 para ACTIVE. Tomando como referencia una punta de la cadena cercana al bloque 2.569.170 el 8 de noviembre, una cadencia de bloques de 2,5 minutos sitúa STARTED alrededor del sábado 14 de noviembre, LOCKED_IN alrededor del 21 de noviembre y ACTIVE alrededor del 28 de noviembre. Son proyecciones: los tiempos reales de los bloques pueden variar y cada ventana que no alcance el umbral decreciente aplazará el calendario.

Queda una tensión sin resolver. El texto estable del DIP-0023 establece una altura mínima de activación seis ventanas de mineros después de la altura de activación de los masternodes. Si la señal de los masternodes se minara antes del bloque 2.572.416, esa regla situaría la activación más temprana en el bloque 2.596.608, casi siete semanas después de la punta de la cadena del 8 de noviembre. La solicitud de cambios y las notas de la versión no mencionan esa regla y señalan el 28 de noviembre como la primera fecha posible. El DIP-0023 tiene el estado "Propuesto", y una modificación propuesta del DIP en el repositorio dashpay/dips lleva un título que indica que elimina las menciones a una altura mínima de activación inexistente; la página no mostraba si había sido incorporada. Esto sugiere que la implementación podría no incluir la regla, pero ninguna de las fuentes resuelve la discrepancia. El 28 de noviembre debe considerarse la primera proyección de los desarrolladores.

Los críticos de los activadores de fecha y hora tienen una objeción conocida. Los autores del BIP 8 de Bitcoin sostuvieron que las marcas de tiempo son activadores poco confiables y que una pérdida repentina de potencia de cómputo puede alterar una activación tardía. V24 comienza con una marca de tiempo, por lo que ese argumento también aplica a su calendario.

Actualizaciones anteriores de Dash atascaron la cadena: v19 en mayo de 2023 y v18.2.0 en enero de 2023

Los problemas con las actualizaciones forman parte del historial de Dash. Cointelegraph informó que el hard fork v19 atascó la cadena en mayo de 2023; el último bloque tenía unas 16 horas de antigüedad cuando se publicó el reporte, y una corrección v19.1.0 llegó aproximadamente 13 horas después del anuncio. Binance suspendió temporalmente la distribución de recompensas de minería de Dash durante el incidente, y los desarrolladores advirtieron que las transacciones sin bloqueo de ChainLock o InstantSend no debían considerarse definitivas. Un aviso de Dash de enero de 2023 también se refirió a una detención de la cadena causada por v18.2.0, versión que fue publicada y luego retirada.

Ninguno de esos episodios demuestra que V24 vaya a fallar. Sí muestran por qué los detalles de la señalización, la participación del quórum y las actualizaciones de los nodos son más importantes que la fecha del calendario.

El calendario de V24 se incorporó junto con la divulgación del uso de Claude Code y sin aprobaciones registradas

La solicitud de cambios 7973 reemplazó los marcadores que nunca habían estado activos en los parámetros de despliegue de la red principal de Dash Core y fue incorporada el 29 de octubre. Su autor, PastaPastaPasta, afirma que fue generada con Claude Code, y el mensaje del commit atribuye el trabajo a Claude Opus 5.5. Al 8 de noviembre, la página de la solicitud no mostraba aprobaciones, señalaba a los responsables del código UdjinM6 y knst como revisores solicitados y pendientes, y mostraba una revisión automatizada de Codex que había fallado el 29 de octubre.

La descripción afirma que el autor revisó la cadena mediante un escaneo de bloques desde la activación de V20 hasta la punta y no encontró señales existentes en los bits 13 o 14, porque el comando de estado del despliegue del candidato de lanzamiento omite los despliegues que nunca han estado activos. El texto de la solicitud de retrocompatibilidad 7969 todavía muestra como pendiente una comprobación del estado del despliegue frente a la punta activa de la cadena. La solicitud informa que 13 verificaciones de integración continua fueron aprobadas.

V24 incorpora garantías compartidas, billeteras de tipo descriptor y pruebas compactas de quórum

El resumen de TokenPost sobre v24.0.0 enumera compatibilidad con pagos multipartitos DIP-0026, un manejo ampliado de las direcciones de masternodes, bloqueos de activos de Dash Platform v2, límites relativos de retiro, un ajuste de las denominaciones adyacentes durante la mezcla, billeteras de tipo descriptor activadas por defecto y pruebas compactas de quórum. Las notas de la versión hacen énfasis en cambios operativos: la actualización es obligatoria para todos los nodos, las migraciones de índices pueden tardar entre 20 y 40 minutos o más, y los masternodes configurados para operar únicamente con bloques se niegan a iniciar.

La propiedad compartida de masternodes sigue siendo una especificación, no una función incorporada al producto. Un borrador de la propuesta Decentralized Masternode Shares en el repositorio dashpay/dips describe garantías compartidas para entre dos y ocho participantes y señala que, sin soporte del protocolo, la propiedad compartida requiere un custodio externo que controle la garantía. La biblioteca Java dashj incorporó su compatibilidad con Core v24 el 8 de noviembre.

Los exchanges y proveedores de billeteras deben actualizarse antes de la activación

Los nodos que no se actualicen antes de la activación terminarán en la cadena de reglas antiguas, porque V24 es un hard fork y no un soft fork. La solicitud de cambios indica que los nodos v23.x ven el nuevo bit como desconocido y se separan únicamente en el momento de la activación, mientras que las notas de la versión califican la actualización de obligatoria para todos los nodos. Esto convierte el momento de la actualización en un asunto de custodia además de una responsabilidad de los operadores: los exchanges, proveedores de billeteras y grupos de minería que operen sus propios nodos de Dash necesitan tener V24 instalado antes de la activación para evitar seguir la cadena de reglas antiguas.

Los usuarios que mantienen sus DASH en un proveedor custodio no pueden actualizar nada por sí mismos. El paso práctico es preguntar al proveedor si programó su actualización a v24 antes de la fecha proyectada del 28 de noviembre y considerar esa fecha como la primera posible, no como una fecha garantizada.

Preguntas frecuentes

¿Qué ocurre con los masternodes de Dash que no se actualicen a V24?

Dejarán de contar para el quórum del 85% que firma la activación, y las notas de la versión indican que los masternodes antiguos serán votados como defectuosos durante la generación de claves y recibirán sanciones PoSe. Según la documentación de Dash, alcanzar el límite de sanciones provoca el bloqueo hasta que el operador repare y vuelva a registrar el nodo.

¿Qué ocurre si no actualiza su nodo antes de un hard fork?

Un hard fork no es compatible con versiones anteriores, por lo que los nodos que no se actualicen no pueden seguir las nuevas reglas y permanecen en la versión de la cadena que aplica las reglas antiguas. En el caso de V24, la solicitud de cambios indica que los nodos v23.x se separan en la activación después de detectar un bit de versión desconocido.

¿Cuándo se activa el hard fork V24 de Dash?

La activación más temprana proyectada es el bloque 2.580.480, alrededor del 28 de noviembre, y puede retrasarse aproximadamente siete días por cada ventana de mineros que no alcance el umbral. El texto estable del DIP-0023 describe un retraso mínimo más largo que no aparece reflejado en la solicitud de cambios.

¿Puede Dash activar el hard fork si pocos mineros lo señalan?

El umbral de los mineros comienza en 80% y baja gradualmente hasta 60% a lo largo de 10 ventanas de aproximadamente siete días cada una. Por eso, un inicio lento de la señalización de los mineros retrasa la activación hasta que el despliegue venza el 9 de noviembre de 2028, en lugar de terminarlo de inmediato. El quórum separado de masternodes exige 85%.