Solana ha reducido su tiempo de slot objetivo de 300 milisegundos a 250 milisegundos, aumentando la velocidad a la que la red produce slots en casi un 17% sin elevar su límite general de procesamiento en la misma medida.
Según los datos de la blockchain, la nueva configuración se activó el 18 de septiembre y lleva a Solana a cuatro slots por segundo, en comparación con aproximadamente 3.3 bajo la configuración anterior de 300ms. El cambio es la tercera etapa de SIMD-0525, diseñado para reducir gradualmente los tiempos de slot desde la configuración original de 400ms de la red hasta un objetivo final de 200ms.
Un slot es el período en el que un validador designado puede producir un bloque. Acortar ese período proporciona a las billeteras, exchanges y 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 establecido en 250ms, la ventana de líder nominal de un validador ha disminuido de 1.2 segundos en la configuración anterior a un segundo.
Solana inició el despliegue actual en agosto cuando redujo su tiempo de slot de 400ms a 350ms por primera vez desde el lanzamiento de la red, como informó previamente crypto.news.
SIMD-0525 dividió el proceso en cuatro etapas de 350ms, 300ms, 250ms y 200ms 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 250ms, se presentan 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, al tiempo que pasan la producción de bloques de un validador a otro más rápidamente.
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 en cadena. Un intervalo más corto reduce el tiempo entre las actualizaciones de la red, mientras que los usuarios pueden ver los cambios de estado de las transacciones antes.
Para los swaps, la sincronización más corta puede reducir el período entre la presentación 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 bruta de transacciones 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 durante un período determinado, pero a cada slot se le permite llevar menos computación 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 250ms corresponde a un límite de 37.5 millones de unidades de cómputo, mientras que la etapa planificada de 200ms lo reduciría a 30 millones.
Los proveedores de infraestructura ahora tienen más bloques individuales que procesar y almacenar, aunque el límite de procesamiento del reloj de pared sigue siendo en gran medida el mismo.
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 hash de bloque expiran antes en tiempo real a medida que los slots avanzan más rápidamente, dejando menos tiempo para los procesos de transacción que implican firmas fuera de línea o aprobaciones humanas retrasadas.
Los tiempos de época cambian por la misma razón. Solana mantiene cada época fija en 432,000 slots, lo que significa que una época se acorta a medida que disminuye la duración de cada slot.
Con el objetivo anterior de 300ms, una época duraba aproximadamente 36 horas. La configuración de 250ms recorta la duración esperada a unas 30 horas. Un movimiento al objetivo final de 200ms 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 en la red en agosto, incluyendo un alquiler de almacenamiento en cadena más bajo, transacciones más grandes y el camino hacia slots de 200ms.
El diseño escalonado incluye una salvaguarda vinculada a las tasas de omisión de bloques. El progreso hacia la siguiente configuración de slot puede detenerse si las tasas de omisión superan el nivel que los desarrolladores consideran aceptable, dando tiempo a los validadores para operar bajo cada configuración antes de que se active otra reducción.
No se ha establecido una fecha de mainnet para la etapa de 200ms.
La temporización de los slots es solo una parte de los cambios de red que se están implementando a través de Agave.
Solana introdujo por separado la Transacción V1, que aumenta 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 cantidad de datos, como pruebas de conocimiento cero e instrucciones complejas de multifirma dentro de una sola transacción.
La Transacción V1 es opcional, mientras que las transacciones heredadas y de versión cero siguen siendo compatibles. Las aplicaciones que leen bloques necesitan ser compatibles con 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 del slot, 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 a través de "feature gates". La estructura permite que una actualización proceda sin requerir que las otras características incluidas en Agave 4.2 se activen al mismo tiempo.
La etapa final bajo SIMD-0525 reduciría el tiempo de slot objetivo de 250ms a 200ms, llevando la red a cinco slots por segundo.
Una ventana de líder de validador de cuatro slots, en consecuencia, caería a aproximadamente 800ms. La duración de la época disminuiría de alrededor de 30 horas bajo la configuración actual de 250ms 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, incluyendo si los validadores pueden mantener tasas de omisión de bloques aceptables.
Las reducciones de slot 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 central de consenso de la red.
La actualización de consenso de Alpenglow apunta a una finalidad de aproximadamente 150ms. Su código ha sido incluido para pruebas, mientras que el despliegue en mainnet se ha vinculado a Agave 4.3 en lugar de las "feature gates" de tiempo de slot utilizadas 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 cambio de consenso más grande en la historia de Solana.
Para SIMD-0525, la red permanece en la etapa de 250ms hasta que los desarrolladores activen la "feature gate" final. La configuración de 200ms completaría un despliegue que comenzó en 400ms y pasó por 350ms, 300ms y 250ms, reduciendo los límites de recursos en cada paso.
SOL