Solana ha reducido su tiempo objetivo de slot de 400 milisegundos a 350 ms por primera vez desde el lanzamiento de la red, iniciando un plan de cuatro etapas que podría eventualmente reducir los slots a 200 ms.
Resumen
- Solana ha reducido su tiempo objetivo de slot de 400 ms a 350 ms por primera vez desde el lanzamiento de la red.
- El cambio es la primera etapa de SIMD-0525, que planea reducciones adicionales a 300 ms, 250 ms y 200 ms.
- Los slots más cortos están diseñados para reducir la latencia de confirmación mientras los límites de recursos de la red se ajustan proporcionalmente.
- Las etapas restantes están dirigidas a Agave v4.2, aunque el calendario de activación sigue siendo tentativo.
El vicepresidente de tecnología de la Fundación Solana, Jacob Creech, anunció el cambio el 21 de agosto, diciendo que la red había entrado en "una nueva era de 350 ms" antes de agregar: "Próxima parada, 300 ms".
Los tiempos promedio de slot estaban alrededor de 360 ms al momento de escribir esto, según el explorador de tiempo de slot de Solana, en comparación con el objetivo original de 400 ms de la red.
El cambio es el primer paso bajo SIMD-0525, una propuesta de mejora de Solana que introduce cuatro configuraciones de slot progresivamente más cortas a 350 ms, 300 ms, 250 ms y 200 ms. La propuesta fue aprobada y fusionada el 14 de mayo.
En lugar de moverse inmediatamente al objetivo final, Solana planea activar cada reducción por separado, dando a los operadores de validadores y a los desarrolladores de clientes la oportunidad de probar el comportamiento de la red a medida que la producción de bloques se vuelve más rápida.
El tiempo de slot de Solana comienza su movimiento hacia 200 ms
La Fundación Solana dijo en junio que reducir los slots de 400 ms a 200 ms reduciría la latencia y permitiría que las confirmaciones llegaran a los usuarios más rápido.
Bajo SIMD-0525, la primera puerta de características cambia el objetivo de slot a 350 ms. Activaciones posteriores lo llevarían a 300 ms, luego a 250 ms y finalmente a 200 ms.
Las cuatro etapas están actualmente dirigidas a Agave v4.2, el cliente validador desarrollado por Anza, aunque el calendario de implementación sigue siendo tentativo y puede cambiar dependiendo de las pruebas.
Los slots más cortos significan que las oportunidades de producción de bloques pasan entre validadores con más frecuencia. SIMD-0525 mantiene los 64 ticks por slot de la red y su ventana de líder de cuatro slots, pero la cantidad de tiempo real representada por cada ventana de líder disminuye con cada reducción.
En el objetivo anterior de 400 ms, cuatro slots daban a un líder una ventana nominal de 1.6 segundos. Un slot de 350 ms reduce esa cifra a 1.4 segundos, mientras que 300 ms la reduciría a 1.2 segundos. En el objetivo final de 200 ms, una ventana de cuatro slots duraría alrededor de 800 ms.
La propuesta dice que reducir la cantidad de tiempo controlado por un líder también puede reducir el período durante el cual las transacciones podrían retrasarse o reordenarse antes de que otro validador reciba la oportunidad de producir bloques.
SIMD-0525 no simplemente permite que la red realice el doble de trabajo después de pasar de 400 ms a 200 ms. Los límites de recursos se ajustan proporcionalmente a medida que disminuye la duración del slot, de modo que las demandas de procesamiento durante un período dado no aumenten solo porque se producen más slots.
En la línea base original de 60 millones de unidades de cómputo utilizada en la propuesta, el límite por slot caería a 52.5 millones de CUs a 350 ms, 45 millones a 300 ms, 37.5 millones a 250 ms y 30 millones a 200 ms.
Los slots más rápidos cambian las confirmaciones y el tiempo de época
La latencia de confirmación es una de las principales áreas objetivo del cambio porque Solana mide varias partes de la operación de la red en slots.
Con los validadores moviéndose a través de los slots más rápidamente, los umbrales de confirmación basados en slots pueden alcanzarse en menos tiempo real. Las aplicaciones que usan números de slot para determinar qué tan reciente es la información de la cadena de bloques también pueden recibir intervalos de tiempo más finos.
SIMD-0525 identifica a los usuarios de oráculos y a los creadores de mercado automatizados entre las aplicaciones que podrían beneficiarse de los intervalos más cortos, particularmente cuando las decisiones dependen de la antigüedad de los datos en cadena.
La duración de la época también disminuirá porque Solana planea mantener 432,000 ranuras por época.
Una época con ranuras de 400 ms tiene una duración nominal de aproximadamente 48 horas. El cambio a 350 ms la reduce a unas 42 horas, mientras que 300 ms llevaría una época a unas 36 horas. A 250 ms, la cifra cae a alrededor de 30 horas, antes de alcanzar aproximadamente 24 horas si se activan ranuras de 200 ms.
Los cálculos anuales de ranuras de Solana se ajustan junto con el cambio para que la emisión del protocolo siga basándose en el tiempo del mundo real en lugar de aumentar simplemente porque ocurren más ranuras cada año.
El Boleto de Admisión de Validadores propuesto bajo el sistema de consenso Alpenglow de Solana también está diseñado para escalar a medida que las épocas se acortan. SIMD-0525 especifica que un costo de 1.6 SOL por época a 400 ms disminuiría a 1.4 SOL a 350 ms, seguido de 1.2 SOL, 1 SOL y 0.8 SOL en las etapas posteriores.
La propuesta dice que los ajustes están destinados a mantener el costo del validador en aproximadamente 0.8 SOL por día a pesar de las épocas más cortas.
Las mejoras de rendimiento de Solana se extienden más allá de los tiempos de ranura
El despliegue del tiempo de ranura ocurre mientras los desarrolladores de Solana trabajan en varios cambios en la infraestructura de validadores y consenso de la red.
Como informó anteriormente crypto.news, Alpenglow entró en pruebas comunitarias de validadores en mayo después de que Anza implementara el diseño de consenso en un clúster de prueba.
Alpenglow está diseñado para llevar los tiempos de confirmación a aproximadamente 150 ms mientras elimina la Prueba de Historia y las transacciones de votación en cadena del proceso central de consenso de Solana. Anza ha llamado a la actualización planificada el mayor cambio de consenso en la historia de Solana.
El sistema introduce un diseño de votación llamado Votor, que utiliza comunicación de validadores fuera de la cadena y agregación de firmas para alcanzar consenso. Su desarrollo es separado de SIMD-0525, aunque ambos proyectos se centran en reducir la cantidad de tiempo requerida para las operaciones de red.
El software de validadores también se ha vuelto más diverso durante 2026. El despliegue en mainnet de Firedancer de Jump Crypto comenzó a producir bloques en mayo después de años de desarrollo, proporcionando una alternativa construida de forma independiente a las implementaciones existentes de validadores de Solana.
Jump Crypto aconsejó a los validadores en ese momento no migrar a Firedancer a gran escala hasta que se completaran las auditorías de seguridad. El cliente ha sido desarrollado tanto para mejorar el rendimiento como para reducir el riesgo creado cuando una cadena de bloques depende en gran medida de una implementación de software de validador.
Más tarde ese mes, Coinbase reveló una configuración de múltiples clientes usando Jito y Firedancer en su infraestructura de validadores de Solana. Su arquitectura de validadores soportaba aproximadamente 40.48 millones de SOL en staking en ese momento, o alrededor del 9.52% del suministro en staking de la red, según el informe de rendimiento de validadores del primer trimestre del exchange.
Solana introdujo otro cambio a nivel de red en julio cuando lanzó un marco de gobernanza en cadena que permite a los validadores tomar votos ponderados por participación en Propuestas de Gobernanza de Solana. Bajo el nuevo proceso de gobernanza, las propuestas que reciben un 15% de apoyo inicial proceden a través de un proceso de 11 épocas que contiene discusión, una instantánea de participación y votación formal.
Una propuesta se aprueba cuando los votos a favor representan al menos el 66.67% de la participación "A favor" y "En contra" participante, mientras que los cambios técnicos aún pueden pasar por el proceso SIMD existente sin recibir primero una votación de propuesta de gobernanza.
La próxima reducción de ranura llevaría a Solana a 300 ms
Con el ajuste de 350 ms ahora activo, SIMD-0525 identifica 300 ms como la siguiente etapa en la secuencia.
El cambio reduciría la ventana nominal de líder de cuatro ranuras de 1.4 segundos a 1.2 segundos y llevaría una época de aproximadamente 42 horas a 36 horas.
Activaciones de características adicionales moverían entonces a Solana a 250 ms y 200 ms. Cada configuración se calcula a partir de los valores base de la red en lugar de usar los límites redondeados de la etapa anterior, un diseño destinado a evitar que las diferencias de redondeo se acumulen a través de reducciones sucesivas.
Las pruebas de la infraestructura de Solana han continuado mientras se preparan esas etapas. Durante julio, la actividad de la red también alcanzó niveles récord a medida que los activos tokenizados se expandieron en Solana, con actividad de acciones tokenizadas contribuyendo al aumento del uso en toda la cadena.
Para SIMD-0525, sin embargo, cada reducción de ranura restante aún requiere su correspondiente activación de función. Tras la recién activada configuración de 350 ms, Creech identificó 300 ms como el próximo objetivo de la red.
