Solana ha reducido su tiempo de slot objetivo de 300 milisegundos a 250 milisegundos, aumentando la tasa a la que la red produce slots en casi un 17% sin elevar su techo de procesamiento general en la misma cantidad.
Resumen
- Solana ha reducido su tiempo de slot objetivo de 300 ms a 250 ms, llevando la red a cuatro slots objetivo por segundo.
- El reloj más rápido reduce la ventana de líder de cuatro slots de cada validador de 1,2 segundos a un segundo.
- La capacidad de procesamiento general permanece aproximadamente sin cambios porque los límites de cómputo y datos disminuyen a medida que se reduce la duración del slot.
- La configuración de 250 ms acorta una época esperada de Solana de aproximadamente 36 horas a 30 horas.
- Una reducción final a 200 ms llevaría a Solana a cinco slots por segundo, pero no se ha fijado una fecha para la mainnet.
Según datos de la blockchain, la nueva configuración entró en vigor el 18 de septiembre y lleva a Solana a cuatro slots objetivo por segundo, en comparación con aproximadamente 3,3 bajo la configuración anterior de 300 ms. El cambio es la tercera etapa de SIMD-0525, que está diseñado para reducir gradualmente los tiempos de slot desde la configuración original de la red de 400 ms hasta un objetivo final de 200 ms.
Un slot es el período en el que un validador designado puede producir un bloque. Acortar ese período brinda a las billeteras, los exchanges y las aplicaciones de trading actualizaciones más frecuentes sobre el estado de la red.
Los validadores continúan sirviendo como líderes durante cuatro slots consecutivos. Con cada slot ahora apuntando a 250 ms, la ventana de liderazgo nominal de un validador ha caído de 1,2 segundos en la configuración anterior a un segundo.
El tiempo de slot de Solana alcanza los 250 ms
Solana comenzó el despliegue actual en agosto cuando redujo su tiempo de slot de 400 ms a 350 ms por primera vez desde el lanzamiento de la red, como informó anteriormente crypto.news.
SIMD-0525 dividió el proceso en cuatro etapas a 350 ms, 300 ms, 250 ms y 200 ms en lugar de pasar directamente al objetivo final. Cada reducción requiere una activación de característica separada, lo que permite a los desarrolladores y operadores de validadores evaluar el rendimiento de la red antes de avanzar.
A 250 ms, llegan cuatro oportunidades de slot cada segundo. Los intervalos más cortos pueden dar a las aplicaciones una visión más actual de las transacciones y el estado de la red mientras se pasa la producción de bloques de un validador a otro más pronto.
Los mercados basados en oráculos y los creadores de mercado automatizados se encuentran entre las aplicaciones cubiertas por la propuesta porque sus operaciones pueden depender de la antigüedad de los datos onchain. Un intervalo más corto reduce la cantidad de tiempo entre actualizaciones de la red, mientras que los usuarios pueden ver los cambios de estado de las transacciones antes.
Para los swaps, el tiempo más corto puede reducir el período entre el envío de una transacción y su llegada a la red. La propuesta subyacente identifica confirmaciones más rápidas y actualizaciones más frecuentes como beneficios de reducir la duración del slot.
El cambio no aumenta la capacidad de transacciones brutas de Solana en casi un 17%.
Bajo SIMD-0525, los límites de recursos se reducen en proporción a la duración del slot. Se producen más slots en un período determinado, pero cada slot puede llevar menos cómputo y datos, manteniendo la cantidad de trabajo que la red puede procesar en tiempo real aproximadamente al mismo nivel.
En la línea base de 60 millones de unidades de cómputo utilizada por la propuesta, el límite por slot disminuye a medida que el reloj se acelera. La configuración de 250 ms corresponde a un límite de 37,5 millones de unidades de cómputo, mientras que la etapa planificada de 200 ms lo reduciría a 30 millones.
Los bloques más rápidos cambian los requisitos de infraestructura de Solana
Los proveedores de infraestructura ahora tienen más bloques individuales para procesar y almacenar, aunque el techo de procesamiento en tiempo real permanece en gran medida sin cambios.
Las aplicaciones que calculan el tiempo transcurrido multiplicando los números de slot por una duración de slot fija pueden necesitar tener en cuenta el reloj más rápido. Los blockhashes expiran antes en tiempo real a medida que los slots avanzan más rápido, dejando menos tiempo para procesos de transacción que involucran firma offline o aprobaciones humanas retrasadas.
El tiempo de época cambia por la misma razón. Solana mantiene cada época fija en 432.000 slots, lo que significa que una época se vuelve más corta a medida que disminuye la duración de cada slot.
En el objetivo anterior de 300 ms, una época duraba aproximadamente 36 horas. La configuración de 250 ms reduce la duración esperada a alrededor de 30 horas. Un movimiento al objetivo final de 200 ms la reduciría a aproximadamente 24 horas.
Las reducciones escalonadas de slots de Solana forman parte del despliegue de Agave 4.2. El lanzamiento del cliente comenzó a activar varios cambios de red en agosto, incluida una renta de almacenamiento en cadena más baja, transacciones más grandes y el camino hacia slots de 200 ms.
El diseño escalonado incluye una salvaguarda vinculada a las tasas de omisión de bloques. El avance hacia la siguiente configuración de slots puede detenerse si las tasas de omisión aumentan más allá del nivel que los desarrolladores consideran aceptable, dando a los validadores tiempo para operar bajo cada configuración antes de que se active otra reducción.
No se ha fijado ninguna fecha para la mainnet para la etapa de 200 ms.
Las actualizaciones de Solana van más allá de slots más rápidos
La sincronización de slots es solo una parte de los cambios de red que se están desplegando a través de Agave.
Solana introdujo por separado Transaction V1, que eleva el tamaño máximo de transacción serializada de 1.232 bytes a 4.096 bytes. El formato de transacción más grande puede acomodar operaciones con gran carga de datos, como pruebas de conocimiento cero e instrucciones complejas de multifirma dentro de una sola transacción.
Transaction V1 es opcional, mientras que las transacciones heredadas y de versión cero siguen siendo compatibles. Las aplicaciones que leen bloques necesitan admitir el formato más nuevo para manejar correctamente las transacciones V1.
El aumento del tamaño de las transacciones es independiente de SIMD-0525. Por lo tanto, las transacciones individuales más grandes no determinan el reloj de slots, mientras que los slots más cortos no aumentan automáticamente el tamaño máximo de una transacción.
Solana ha estado activando los cambios de forma independiente mediante feature gates. La estructura permite que una actualización avance sin requerir que las otras características incluidas en Agave 4.2 se activen al mismo tiempo.
Solana sigue apuntando a slots de 200 ms
La etapa final bajo SIMD-0525 reduciría el tiempo objetivo de slot de 250 ms a 200 ms, llevando la red a cinco slots objetivo por segundo.
En consecuencia, una ventana de líder de validador de cuatro slots caería a aproximadamente 800 ms. La duración de la época disminuiría de alrededor de 30 horas bajo la configuración actual de 250 ms a aproximadamente 24 horas.
Los desarrolladores de Solana no han proporcionado una fecha de activación en mainnet para la reducción final. El progreso depende del comportamiento de la red bajo la configuración actual, incluido si los validadores pueden mantener tasas aceptables de omisión de bloques.
Las reducciones de slots son independientes de Alpenglow, el rediseño de consenso planificado de Solana. Alpenglow tiene como objetivo reemplazar TowerBFT con un sistema de votación llamado Votor y eliminar las transacciones de voto en cadena del proceso de consenso central de la red.
La actualización de consenso Alpenglow apunta a una finalidad de aproximadamente 150 ms. Su código se ha incluido para pruebas, mientras que el despliegue en mainnet se ha vinculado a Agave 4.3 en lugar de a los feature gates de tiempo de slot utilizados para SIMD-0525.
Alpenglow entró en pruebas comunitarias de validadores a principios de 2026, permitiendo a los operadores ejecutar el diseño de consenso en un clúster de prueba antes del despliegue en mainnet. Anza ha descrito el sistema como el mayor cambio de consenso en la historia de Solana.
Para SIMD-0525, la red permanece en la etapa de 250 ms hasta que los desarrolladores activen el feature gate final. La configuración de 200 ms completaría un despliegue que comenzó a 400 ms y pasó por 350 ms, 300 ms y 250 ms mientras reducía los límites de recursos en cada paso.
