MultiversX lanza Supernova en testnet, busca bloques de…
La actualización desacopla el consenso de la ejecución y afirma una finalización en fragmentos de 100 a 250 ms para DeFi sensible a la latencia.
MultiversX ha lanzado su actualización "Supernova" en testnet, rediseñando la producción de bloques para que los validadores puedan acordar los bloques antes de que se ejecuten las transacciones. El equipo está apuntando a bloques de ~600 milisegundos y 100–250 milisegundos de finalización en la shard, con la activación de mainnet esperada para el 10 de septiembre de 2026.
Supernova llega a Testnet con un cambio esperado a Mainnet el 10 de septiembre
Supernova ya está activa en el testnet de MultiversX, con la misma arquitectura también funcionando en devnet, mientras la red avanza hacia un pipeline de ejecución asíncrona que está diseñado explícitamente para mantener el consenso en movimiento incluso cuando la ejecución de transacciones aún está poniéndose al día.
La línea de tiempo declarada es ajustada y específica. Supernova ha estado produciendo bloques de ~600 milisegundos en el testnet en vivo y en devnet desde el 20 de agosto, y la red está trabajando hacia una fecha de activación de mainnet esperada para el 10 de septiembre de 2026.
La actualización se enmarca como una respuesta a un techo de escalabilidad familiar para cadenas de alto rendimiento: cuando la ejecución de transacciones se encuentra en la ruta crítica del consenso, el cálculo más lento se convierte en el coche de ritmo del sistema. La apuesta de MultiversX es que el próximo cambio radical en la latencia proviene de cambiar el orden de las operaciones, no solo de optimizar la propagación y la finalización.
Consenso y Ejecución Desacoplados: Los Objetivos de Latencia y el Nuevo Problema de Validez
El cambio central de Supernova es mecánico: "desacopla el consenso de la ejecución para que la red pueda acordar bloques antes de procesar sus transacciones", trasladando la ejecución fuera de la ruta crítica del consenso y a una etapa asíncrona que se ejecuta después de que los validadores ya han votado.
Antes de la actualización, el flujo era secuencial. Un proponente seleccionaba transacciones, las ejecutaba localmente y proponía un bloque con las transiciones de estado resultantes, luego los validadores reejecutaban esas transacciones antes de votar.
Bajo Supernova, "El proponente selecciona transacciones y propone el bloque sin ejecutarlas primero", y "Los validadores verifican que la propuesta siga las reglas del protocolo y pueden votar de inmediato, mientras la ejecución continúa asíncronamente en segundo plano."
Ese reordenamiento es lo que hace que los objetivos de latencia sean plausibles en teoría. La salida de la ejecución se "referencia y se notifica normalmente en el siguiente encabezado de bloque", lo que significa que la ejecución sigue al consenso por aproximadamente un bloque, o alrededor de 600 milisegundos.
En la práctica, la arquitectura está apuntando a una cadencia en tubería donde el consenso puede seguir produciendo bloques de ~600 ms incluso si la ejecución está un bloque detrás, en lugar de forzar a cada validador a terminar el mismo cálculo antes de que el siguiente bloque pueda ser finalizado.
Para los constructores, la afirmación principal es que "la finalización en shard llega tan pronto como la prueba está disponible, generalmente dentro de la misma ronda en alrededor de 100–250 milisegundos", emparejada con "condiciones de ejecución más predecibles."
Los casos de uso objetivo son aquellos que se degradan rápidamente cuando la latencia se vuelve visible para el usuario, incluidos los primitivos de DeFi de alta frecuencia y los libros de órdenes en cadena.
El problema es la validez que introduce la ejecución asíncrona. Si la red vota sobre un bloque antes de la ejecución, una transacción que parecía válida en el momento de la propuesta puede volverse inválida para cuando la ejecución la alcance, porque los nonces y saldos de las cuentas pueden haber sido consumidos por otra actividad pendiente.
Estado del Mempool Virtual, EIE y Presión de Retroceso: Cómo Supernova Intenta Mantener los Bloques Seguros y los Nodos Sincronizados
La primera línea de defensa de Supernova está en la capa de propuestas, a través de un "estado de mempool virtual" que mira más allá del último estado ejecutado y rastrea nonces pendientes, consumo de saldo esperado y transacciones ya propuestas pero aún no ejecutadas o finalizadas a través del consenso.
El objetivo es dar a los proponentes una visión prospectiva de la actividad de la cuenta para que puedan evitar incluir transacciones que probablemente fallarán una vez que la ejecución se ponga al día.
El diseño también agrega dos limitadores explícitos destinados a evitar que la larga cola de hardware de la red se quede atrás.
El Estimador de Inclusión de Resultados de Ejecución (EIE) limita cuántos resultados de ejecución pueden ser referenciados en un bloque basado en lo que "los nodos de especificaciones mínimas pueden procesar de manera segura", y la presión de retroceso automática reduce la capacidad del bloque si la ejecución se retrasa demasiado, dando al sistema tiempo para ponerse al día.
Esos mecanismos son también donde hoy se encuentra la incertidumbre relevante para el mercado. El material describe el pipeline y sus salvaguardias, pero no proporciona métricas independientes, cifras de rendimiento o datos de pruebas de estrés que mostrarían si los bloques de ~600 ms persisten bajo mezclas de transacciones más pesadas y complejas.
Tampoco detalla, más allá del estado de mempool virtual y los limitadores, cómo se manejan operativamente los fallos de ejecución post-consenso y las transacciones inválidas en casos extremos.
Los próximos hitos concretos son procedimentales más que narrativos: confirmación o revisión de la fecha esperada de activación de mainnet del 10 de septiembre de 2026, producción sostenida de bloques de ~600 ms en testnet/devnet a medida que aumentan la carga y la complejidad de las transacciones, y cualquier métrica divulgada que muestre con qué frecuencia se activan los límites de EIE o las reducciones de presión de retroceso bajo estrés.
Mi Lectura: Esta Es una Apuesta de UX/Constructor—Pero los Comerciantes Deben Tratar los Números como Provisionales Hasta Mainnet
La parte que la mayoría de las personas malinterpretará es la afirmación de latencia como una garantía de rendimiento terminada.
Lo que realmente se ha enviado es un cambio arquitectónico que elimina la ejecución del camino crítico de consenso, y esa es una verdadera elección de diseño con un precedente claro en cadenas de alto rendimiento: obtienes una cadencia de bloques más predecible a medida que aumenta la complejidad de las transacciones, pero heredas una nueva clase de problemas de validez y acumulación que solo aparecen bajo carga desordenada y adversarial.
El umbral que importa es si el testnet/devnet puede mantener bloques de ~600 ms mientras los limitadores permanecen mayormente en segundo plano, porque si EIE y la presión de retroceso están constantemente activándose, el pipeline sigue siendo "rápido" en papel pero limitado en la práctica.
Esto se vuelve relevante para el mercado cuando se confirma la fecha de mainnet y la red puede demostrar un comportamiento sostenido de baja latencia sin que el retraso de ejecución rutinario se convierta en el limitador dominante.
