Al volver a comprobar el registro más reciente de la actualización de red @Dusk , descubrí un cambio más importante que una simple actualización de versión habitual: después de la actualización de Boreas, la red principal de Dusk ya dejó de recibir y ejecutar nuevas transacciones de Phoenix.
Boreas se implementó junto con Rusk 1.7, y la red principal estableció como límite de reinicio el 10 de junio de 2026, con el bloque 4,414,095. Phoenix quedó deshabilitado en el reinicio de la red principal, mientras que en la red de pruebas se detuvo tras llegar a la altura de 4,000,000 el 7 de agosto. Las transacciones nuevas actuales utilizan principalmente el modelo Moonlight.
Pero “detener las nuevas transacciones” no significa eliminar Phoenix. Los nodos aún conservan la capacidad de decodificar las antiguas transacciones de Phoenix, ejecutar su historial y sincronizar el estado de la cadena, porque un Archive Node debe poder volver a reproducir bloques antiguos. En palabras sencillas: que el banco deje de abrir un tipo de cuentas antiguas no implica que el historial anterior pueda borrarse del libro contable.
Boreas también introduce el procesamiento de transacciones versionadas, reglas de tarificación de VM deterministas, una marca de evento Reverted, y ajusta el orden de ejecución del Slash para que ocurra antes que en las transacciones ordinarias. Esto indica que el foco de la actualización no es solo cambiar el modelo de transferencia, sino delimitar con mayor rigor cómo distintos nodos interpretan una misma transacción.
Lo que realmente vale la pena preguntar es: ¿qué seguirá sosteniendo la ruta de privacidad de Dusk a partir de ahora? Moonlight es un modelo de cuenta pública, y DuskEVM describe a Hedger como la futura ruta de privacidad. En adelante, conviene prestar atención a la entrega de Hedger, la migración de carteras, el tratamiento de los saldos antiguos de Phoenix y si la documentación se actualiza de manera uniforme.
La investigación de proyectos de privacidad es más peligrosa no por los cambios técnicos, sino por seguir explicando la nueva red con arquitecturas antiguas. #dusk $DUSK
Boreas se implementó junto con Rusk 1.7, y la red principal estableció como límite de reinicio el 10 de junio de 2026, con el bloque 4,414,095. Phoenix quedó deshabilitado en el reinicio de la red principal, mientras que en la red de pruebas se detuvo tras llegar a la altura de 4,000,000 el 7 de agosto. Las transacciones nuevas actuales utilizan principalmente el modelo Moonlight.
Pero “detener las nuevas transacciones” no significa eliminar Phoenix. Los nodos aún conservan la capacidad de decodificar las antiguas transacciones de Phoenix, ejecutar su historial y sincronizar el estado de la cadena, porque un Archive Node debe poder volver a reproducir bloques antiguos. En palabras sencillas: que el banco deje de abrir un tipo de cuentas antiguas no implica que el historial anterior pueda borrarse del libro contable.
Boreas también introduce el procesamiento de transacciones versionadas, reglas de tarificación de VM deterministas, una marca de evento Reverted, y ajusta el orden de ejecución del Slash para que ocurra antes que en las transacciones ordinarias. Esto indica que el foco de la actualización no es solo cambiar el modelo de transferencia, sino delimitar con mayor rigor cómo distintos nodos interpretan una misma transacción.
Lo que realmente vale la pena preguntar es: ¿qué seguirá sosteniendo la ruta de privacidad de Dusk a partir de ahora? Moonlight es un modelo de cuenta pública, y DuskEVM describe a Hedger como la futura ruta de privacidad. En adelante, conviene prestar atención a la entrega de Hedger, la migración de carteras, el tratamiento de los saldos antiguos de Phoenix y si la documentación se actualiza de manera uniforme.
La investigación de proyectos de privacidad es más peligrosa no por los cambios técnicos, sino por seguir explicando la nueva red con arquitecturas antiguas. #dusk $DUSK