Solana se acerca a los slots de 200 ms tras su última mejora de velocidad

Según datos de la blockchain, la nueva configuración entró en funcionamiento el 18 de septiembre y lleva a Solana a cuatro slots objetivo por segundo, frente a los aproximadamente 3,3 de la configuración anterior de 300 ms. El cambio es la tercera etapa de SIMD-0525, diseñada para reducir gradualmente los tiempos de slot desde los 400 ms originales de la red hasta un objetivo final de 200 ms.

Un slot es el periodo en el que un validador designado puede producir un bloque. Acortar ese periodo ofrece a monederos, exchanges y aplicaciones de trading actualizaciones más frecuentes sobre el estado de la red.

Los validadores siguen actuando como líderes durante cuatro slots consecutivos. Con cada slot ahora fijado en 250 ms, la ventana nominal de líder de un validador ha pasado de 1,2 segundos con 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 de 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 función independiente, lo que permite a los desarrolladores y operadores de validadores evaluar el rendimiento de la red antes de continuar.

A 250 ms, llegan cuatro oportunidades de slot por segundo. Los intervalos más cortos pueden ofrecer a las aplicaciones una visión más actual de las transacciones y del estado de la red, al tiempo que se transfiere antes la producción de bloques de un validador a otro.

Los mercados basados en oráculos y los creadores de mercado automatizados se encuentran entre las aplicaciones cubiertas por la propuesta, porque su funcionamiento puede depender de la antigüedad de los datos on-chain. Un intervalo más corto reduce el tiempo entre actualizaciones de la red, mientras que los usuarios pueden ver antes los cambios de estado de las transacciones.

Para los swaps, el tiempo más corto puede reducir el periodo 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 bruta de transacciones de Solana en casi un 17%.

Con 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 periodo determinado, pero cada slot puede contener menos computación y datos, manteniendo la cantidad de trabajo que la red puede procesar en tiempo real aproximadamente al mismo nivel.

Con la base de 60 millones de unidades de cómputo utilizada en 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 prevista de 200 ms lo reduciría a 30 millones.

Bloques más rápidos cambian los requisitos de infraestructura de Solana

Los proveedores de infraestructura ahora tienen más bloques individuales que procesar y almacenar, aunque el techo de procesamiento en tiempo real permanece prácticamente sin cambios.

Las aplicaciones que calculan el tiempo transcurrido multiplicando los números de slot por una duración fija de slot pueden necesitar tener en cuenta el reloj más rápido. Los blockhashes caducan antes en tiempo real a medida que los slots avanzan más rápido, dejando menos tiempo para procesos de transacción que implican firma fuera de línea o aprobaciones humanas demoradas.

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 acorta a medida que disminuye la duración de cada slot.

Con el objetivo anterior de 300 ms, una época duraba aproximadamente 36 horas. La configuración de 250 ms reduce la duración esperada a unas 30 horas. Un paso 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, incluido un menor alquiler de almacenamiento on-chain, 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 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 fijado una fecha en la red principal para la etapa de 200 ms.

Las mejoras de Solana van más allá de slots más rápidos

El tiempo de slot 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 muchos datos, como pruebas de conocimiento cero e instrucciones multifirma complejas, 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 deben admitir el formato más nuevo para manejar correctamente las transacciones V1.

El aumento del tamaño de transacción es independiente de SIMD-0525. Por lo tanto, las transacciones individuales más grandes no determinan el reloj de 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 puertas de funciones. La estructura permite que una mejora avance sin requerir que las otras funciones incluidas en Agave 4.2 se activen al mismo tiempo.

Solana sigue apuntando a slots de 200 ms

La etapa final de SIMD-0525 reduciría el tiempo de slot objetivo de 250 ms a 200 ms, llevando a la red a cinco slots objetivo por segundo.

La ventana de líder de cuatro slots de un validador caería en consecuencia a aproximadamente 800 ms. La duración de la época disminuiría de unas 30 horas con la configuración actual de 250 ms a aproximadamente 24 horas.

Los desarrolladores de Solana no han proporcionado una fecha de activación en la red principal 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 de omisión de bloques aceptables.

Las reducciones de slots son independientes de Alpenglow, el rediseño de consenso planificado de Solana. Alpenglow pretende reemplazar TowerBFT con un sistema de votación llamado Votor y eliminar las transacciones de voto on-chain del proceso de consenso central de la red.

La mejora de consenso Alpenglow apunta a una finalidad de aproximadamente 150 ms. Su código se ha incluido para pruebas, mientras que el despliegue en la red principal se ha vinculado a Agave 4.3 en lugar de a las puertas de funciones 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 la red principal. 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 la puerta de función final. La configuración de 200 ms completaría un despliegue que comenzó en 400 ms y pasó por 350 ms, 300 ms y 250 ms, reduciendo los límites de recursos en cada paso.