Solana ha ajustado su cadencia de producción de bloques, activando el 18 de septiembre de 2026 una reducción del tiempo objetivo de slot de 300 milisegundos a 250 milisegundos, coincidiendo con el inicio del epoch 1037. El cambio eleva la producción de bloques a cuatro slots por segundo, frente a unos 3.3 slots por segundo anteriormente — un recorte de alrededor del 17% en el tiempo de slot. El tiempo de slot es el intervalo que tiene cada validador para producir un bloque, lo que lo convierte en la medida más directa de la rapidez con la que el estado fresco de la red se hace disponible.

La activación marca la cuarta etapa de SIMD-0525, una propuesta por fases para ajustar progresivamente la cadencia de bloques de Solana, con un objetivo final de 200 milisegundos por slot.

Bloques más rápidos, no más capacidad

Contraintuitivamente, los bloques más rápidos no se traducen en más transacciones por segundo. Para mantener la red estable, Solana redujo proporcionalmente los límites de cómputo y datos por slot junto con el cambio de tiempos. El máximo de unidades de cómputo por slot cayó a 37.5 millones desde una base de 60 millones, y los límites de data shred se ajustaron en la misma dirección.

El tiempo de bloque y el throughput suelen confundirse en las comparaciones de la industria, pero miden cosas distintas — con qué frecuencia llegan bloques nuevos frente a cuánto puede llevar cada uno. El beneficio práctico aquí no radica en el throughput bruto, sino en la frescura de los datos. Los precios, los estados de las cuentas y las ventanas de blockhash se actualizan con mayor frecuencia — un cambio que importa enormemente para las aplicaciones que dependen de información actual, ya que se pasa menos tiempo operando sobre estado obsoleto.

La duración del epoch también se contrajo. Dado que los epochs se definen por recuentos de slots y no por tiempo de reloj, el slot más corto comprime todo lo ligado a los límites del epoch. A 250 milisegundos por slot, el epoch de Solana ahora dura aproximadamente 30 horas, frente a unas 36 horas. Eso afecta a los validadores, a la distribución de recompensas de st y a cualquier protocolo que ancle sus tiempos a los límites del epoch.

Un despliegue por etapas con una hoja de ruta clara

SIMD-0525 ha avanzado en pasos deliberados en lugar de un solo salto. La primera reducción en mainnet llevó los tiempos de slot a 350 milisegundos el 19 de agosto de 2026. La segunda los bajó a 300 milisegundos el 25 de agosto de 2026. La activación del 18 de septiembre es la cuarta etapa, lo que significa que hubo un tercer paso entre finales de agosto y mediados de septiembre.

El objetivo final de 200 milisegundos ya se probó tanto en devnet como en testnet. Lo que separa ese hito de la activación en mainnet es la tasa de bloques omitidos: los validadores de Solana ocasionalmente pierden su slot asignado, y las ventanas de tiempo más ajustadas reducen la tolerancia a esos fallos. La comunidad central de desarrolladores quiere confirmar que la tasa de omisión se mantenga dentro de límites aceptables antes de activar la reducción final.

Las ventanas de control del líder también se redujeron con este cambio, de 1.2 a 1 segundo — cuatro slots consecutivos por líder con la nueva cadencia. Los validadores ahora tienen menos tiempo para difundir sus bloques — una de las variables que influyen en la tasa de omisión. Con las ventanas más ajustadas ya en vigor, el comportamiento de la tasa de omisión en mainnet es la métrica a observar mientras la comunidad evalúa el paso final hacia los 200 milisegundos.