Solana acaba de recortar 50 milisegundos del tiempo que tardan los validadores en producir un bloque, y es la primera vez que la red lo hace. La actualización del tiempo de slot de Solana se activó en la mainnet el viernes, reduciendo el tiempo objetivo de slot de 400 milisegundos a 350 milisegundos y dando inicio a lo que los desarrolladores describen como una marcha escalonada, época por época, hacia un objetivo mucho más rápido de 200 milisegundos.
Summary
Puntos clave
- El tiempo de slot de la mainnet de Solana cayó de 400 milisegundos a 350 milisegundos, la primera reducción de este tipo desde el lanzamiento de la red.
- El cambio se activó como la función SIMD-0525 en el slot 440.208.000 de la época 1019, después de haberse fusionado en la base de código el 14 de mayo.
- Se planean tres recortes adicionales de 50 milisegundos, a 300, 250 y finalmente 200 milisegundos, mediante compuertas de funciones separadas, cada una supeditada a tasas saludables de bloques omitidos.
- La actualización está etiquetada como un cambio incompatible, y Solana afirma que los ajustes de indexación para herramientas de terceros aún se están definiendo.
- Jacob Creech, vicepresidente de tecnología de la Fundación Solana, confirmó que 300 milisegundos es el siguiente objetivo en la hoja de ruta.
Solana reduce por primera vez el tiempo de slot en mainnet
La respuesta central es simple: Solana acaba de hacer que los bloques lleguen más rápido, sin cambiar la estructura subyacente de la red. Esta es la primera reducción del tiempo de slot desde la creación de Solana, y acorta directamente la ventana que cada validador tiene para ensamblar y difundir un bloque de transacciones.
Detalles de activación y efectos inmediatos
La función, identificada como SIMD-0525, se activó en Mainnet Beta en el slot 440.208.000 de la época 1019, según el propio explorador de Solana. La propuesta en sí se fusionó en los documentos de mejora de la red el 14 de mayo, dando a los desarrolladores un margen de varios meses para preparar el software de los validadores antes de accionar el interruptor.
El efecto práctico se refleja casi de inmediato en la velocidad de confirmación. Una comprobación puntual reportada por The Block encontró que un tramo de 1.000 slots poco antes del cambio tardó 415 segundos en completarse, en comparación con 368 segundos para un tramo similar después de que la actualización se activara en la época 1020, una caída en el mundo real coherente con el nuevo objetivo de 350 milisegundos.
Dado que cada época en Solana sigue conteniendo 432.000 slots, los slots más rápidos se traducen directamente en épocas más rápidas. Lo que antes tardaba aproximadamente 48 horas en completarse ahora termina en unas 42 horas, aunque nada en el conteo interno de la época haya cambiado.
Fundamentos técnicos que permiten la actualización
Nada de esto habría sido posible sin el trabajo en el lado del cliente validador. Solana atribuyó a las mejoras en Turbine, la capa de propagación de bloques de la red, y en Replay, el proceso que usan los validadores para verificar y votar los bloques entrantes, el papel de habilitadores técnicos que hicieron viable a escala un tiempo de slot más corto.
Estos dos sistemas tuvieron que volverse más rápidos antes de que la red pudiera comprimir de forma segura el tiempo disponible para que un líder termine un bloque, lo entregue a través de Gulf Stream al siguiente líder y permita que el resto del conjunto de validadores lo reproduzca y vote sobre él. Reducir esa ventana sin esas mejoras probablemente habría elevado las tasas de omisión y desestabilizado la producción de bloques.
Enfoque por fases para nuevas reducciones del tiempo de slot
Solana no está saltando directamente a su punto final. En su lugar, la red avanza a través de cuatro etapas separadas, de 400 milisegundos a 200 milisegundos, y cada paso requiere su propia activación y su propia verificación de salud antes de que se permita el siguiente.
Mecanismo de compuertas de funciones para futuras actualizaciones
Cada recorte adicional de 50 milisegundos, ya sea a 300, 250 o 200 milisegundos, se activará mediante una compuerta de función separada en una época posterior, en lugar de mediante un único interruptor general. Esa estructura da a la Fundación Solana y a los operadores de validadores margen para observar cómo se comporta la red a cada nueva velocidad antes de comprometerse con la siguiente reducción.
Anza, el equipo de desarrollo del cliente validador que se escindió del Solana Labs original, ha presentado un calendario tentativo de Agave v4.2 que apunta a la activación eventual en mainnet de las cuatro reducciones escalonadas. Aún no se ha fijado una fecha en el calendario ni una época específica para el paso a 300 milisegundos, que es el siguiente en la lista.
Controles de riesgo basados en las tasas de bloques omitidos
Aquí es donde la cautela realmente se hace evidente. La Fundación Solana ha sido explícita en que la red no avanzará a la siguiente reducción del tiempo de slot si las tasas de bloques omitidos suben demasiado, es decir, si demasiados validadores no logran producir sus bloques asignados a tiempo. Ese freno incorporado es importante porque los slots más cortos comprimen todos los procesos posteriores: la finalización de bloques, la propagación de transacciones y la votación de los validadores disponen de menos tiempo de reloj para ejecutarse correctamente.
Por qué esto importa: un despliegue escalonado con un disparador basado en la tasa de omisión convierte efectivamente la velocidad en una variable monitorizada en lugar de una promesa fija. Si el hardware o el software de los validadores no puede seguir el ritmo a 300 milisegundos, la red puede simplemente hacer una pausa en ese punto en lugar de seguir adelante y arriesgarse a la inestabilidad.
Implicaciones más amplias e impacto en la red
Los slots más rápidos no significan automáticamente una red más rápida en todos los sentidos, y esa distinción es importante para cualquiera que siga las afirmaciones de rendimiento de Solana. Los validadores manejan los slots con mayor frecuencia, pero cada slot individual lleva menos trabajo, por lo que el cambio mejora principalmente la latencia y la velocidad de confirmación en lugar de la capacidad bruta de transacciones. Solana elevó por separado su límite de unidades de cómputo a 100 millones en julio de 2025, una actualización distinta destinada a ampliar la cantidad de trabajo que cabe en cada bloque.
Estado de cambio incompatible e impacto en la indexación
La propia Solana califica la actualización del tiempo de slot de Solana como un cambio incompatible, y los ajustes de indexación necesarios para herramientas y servicios de terceros aún están por determinarse. Esa es una brecha notable: la documentación de Solana todavía describe la duración predeterminada del slot como 400 milisegundos, aunque el explorador de la red confirma que la primera compuerta de función de 350 milisegundos ya está activa. Los desarrolladores que construyen sobre indexadores, paneles de análisis o exploradores de bloques deberían prever cierta fricción a corto plazo mientras las herramientas se ponen al día con el nuevo temporizado de la red.
Declaraciones oficiales y visión de la ruta de actualización
Jacob Creech, vicepresidente de tecnología de la Fundación Solana, describió el movimiento como la primera reducción del tiempo de slot de la red y confirmó que 300 milisegundos es el siguiente objetivo en la hoja de ruta. Ni Creech ni la página pública de actualizaciones de la Fundación han asociado una fecha firme a ese siguiente paso, y el plan depende explícitamente de cómo se desempeñe la red primero a 350 milisegundos.
También hay un horizonte más amplio. El tiempo de slot y la finalidad completa no son lo mismo: los bloques de Solana todavía tardan aproximadamente 12,8 segundos en volverse totalmente irreversibles hoy, incluso con la nueva cadencia de slots de 350 milisegundos. Una revisión separada y aún en desarrollo llamada Alpenglow pretende eventualmente reducir esa ventana de finalidad a unos 150 milisegundos, lo que sería un cambio estructural mucho mayor que las actuales reducciones escalonadas del tiempo de slot. La red también ha incorporado recientemente el cliente Firedancer de Jump Crypto, construido en un lenguaje de programación diferente al dominante stack Agave, mejorando la diversidad de clientes validadores a medida que continúa el impulso general hacia una mayor velocidad.
Preguntas frecuentes
¿Qué cambio hizo recientemente Solana en su temporización de slots?
Solana redujo su tiempo de slot en mainnet de 400 milisegundos a 350 milisegundos, lo que representa la primera reducción desde la creación de la red.
¿Cómo se gestionarán las futuras reducciones del tiempo de slot?
Las futuras reducciones a 300, 250 y 200 milisegundos se activarán por separado mediante compuertas de funciones y dependerán de que las tasas de bloques omitidos no se vuelvan demasiado altas.
¿La reducción del tiempo de slot afecta la estructura de las épocas de Solana o los ticks por slot?
No, la actualización no cambia el número de ticks por slot, el intervalo del líder ni el número de slots en una época.
¿Por qué se considera la actualización un cambio incompatible?
La actualización es incompatible porque requiere cambios de indexación para herramientas e infraestructuras de terceros, aunque esos ajustes aún están por determinarse.
{«@context»:»https://schema.org»,»@type»:»FAQPage»,»mainEntity»:[{«@type»:»Question»,»name»:»¿Qué cambio hizo recientemente Solana en su temporización de slots?»,»acceptedAnswer»:{«@type»:»Answer»,»text»:»Solana redujo su tiempo de slot en mainnet de 400 milisegundos a 350 milisegundos, lo que representa la primera reducción desde la creación de la red.»}},{«@type»:»Question»,»name»:»¿Cómo se gestionarán las futuras reducciones del tiempo de slot?»,»acceptedAnswer»:{«@type»:»Answer»,»text»:»Las futuras reducciones a 300, 250 y 200 milisegundos se activarán por separado mediante compuertas de funciones y dependerán de que las tasas de bloques omitidos no se vuelvan demasiado altas.»}},{«@type»:»Question»,»name»:»¿La reducción del tiempo de slot afecta la estructura de las épocas de Solana o los ticks por slot?»,»acceptedAnswer»:{«@type»:»Answer»,»text»:»No, la actualización no cambia el número de ticks por slot, el intervalo del líder ni el número de slots en una época.»}},{«@type»:»Question»,»name»:»¿Por qué se considera la actualización un cambio incompatible?»,»acceptedAnswer»:{«@type»:»Answer»,»text»:»La actualización es incompatible porque requiere cambios de indexación para herramientas e infraestructuras de terceros, aunque esos ajustes aún están por determinarse.»}}]}
Artículo producido con la asistencia de inteligencia artificial y revisado por el equipo editorial.
