Solana reduce el tiempo de slot de su red principal a 200 ms

Solana completó una actualización de cuatro etapas que reduce el objetivo de tiempo de slot de la red principal de 400 a 200 milisegundos. La última compuerta se activó al inicio de la época 1053 el 9 de octubre de 2026, aproximadamente a las 14:35 UTC, según la página oficial.

El cambio divide por dos el tiempo asignado a cada slot y acelera el avance entre ventanas de líder. No modifica el tramo de cuatro slots del líder ni la cantidad de slots por época, y se clasifica como no incompatible. Las cuatro reducciones también están activas en devnet y testnet.

El despliegue gradual hasta 200 ms

La red bajó el objetivo en cuatro pasos para observar el rendimiento: 350 ms el 21 de agosto, 300 ms el 28 de agosto, 250 ms el 18 de septiembre y 200 ms el 9 de octubre. La activación final ocurrió en el slot 454.896.000.

La actualización se apoya en mejoras de clientes validadores, especialmente Turbine y Replay. La ventana de vencimiento del blockhash pasa de unos 60 a 30 segundos. Las aplicaciones con supuestos antiguos deben revisar reintentos, vencimiento de transacciones e ingestión de datos.

Como contexto de mercado están disponibles el mercado al contado BTC/USDT y el mercado perpetuo BTC/USDT verificados en OrangeX.com. Estas páginas no forman parte de la actualización.

Cambios para usuarios y validadores

Los slots más cortos pueden reducir la espera hasta la siguiente oportunidad de inclusión, aunque la experiencia depende de la red, los validadores y la aplicación. La infraestructura debe procesar datos de bloques con mayor frecuencia.

La ventana más corta también puede limitar el control exclusivo de un líder, pero el efecto debe medirse con datos reales. Más novedades están en OrangeX.com Crypto News y las protecciones en el Centro de confianza de OrangeX.com.

OrangeX.com Analysis

Llegar a 200 ms es un hito medible. La prueba práctica será sostenerlo con alta demanda sin aumentar de forma material los slots omitidos, las transacciones fallidas o el retraso de la infraestructura.

La mejora reduce el límite de latencia, pero no garantiza que toda aplicación se sienta dos veces más rápida. Las políticas de confirmación, la calidad RPC, la congestión y la preparación del software siguen siendo decisivas.