Solana lista para reducir a la mitad los tiempos de bloque con la actualización final de 200 milisegundos
Puntos clave
- •El tiempo objetivo de bloque de Solana bajará de 250 a 200 milisegundos en el epoch 1053 el viernes, previsto alrededor de las 15:00 UTC, completando un esfuerzo de actualización que comenzó en agosto.
- •El despliegue había movido previamente la red de 400 a 350 milisegundos el 21 de agosto, luego a 300 milisegundos el 28 de agosto y a 250 milisegundos el 18 de septiembre.
- •La nueva configuración apunta a cinco oportunidades de producción de bloques por segundo, con un límite de 30 millones de unidades de cómputo por bloque, frente a 37.5 millones, dejando la capacidad total de procesamiento de la red prácticamente sin cambios.
- •Los validadores votarán aproximadamente el doble de frecuente que bajo la configuración original, lo que eleva los costos, mientras su ventana de ordenamiento de transacciones se reduce de 1.6 segundos a 800 milisegundos y la ventana de validez de los blockhash se acorta.
- •Datos de Solana Compass muestran que el objetivo anterior de 250 milisegundos produjo tiempos promedio de slot de unos 266 a 269 milisegundos, y los desarrolladores han indicado que la activación en la mainnet depende de condiciones de la red como las tasas de slots perdidos.

Solana lista para reducir a la mitad los tiempos de bloque con la actualización final de 200 milisegundos
Solana se prepara para reducir el tiempo entre bloques a 200 milisegundos el viernes, completando un esfuerzo de actualización de siete semanas que habrá reducido a la mitad el tiempo objetivo de producción de bloques de la red desde agosto. La reducción final, desde 250 milisegundos, está programada para entrar en vigor en el epoch 1053, previsto alrededor de las 15:00 UTC, según Anza, el desarrollador del software de validación Agave, ampliamente utilizado en Solana.
El cambio aporta cinco oportunidades de producción de bloques por segundo, lo que podría acelerar las actualizaciones de transacciones, mientras se reduce el límite de cómputo de cada bloque para mantener la capacidad total de procesamiento de la red prácticamente sin cambios. También conlleva contrapartidas: los validadores enfrentan costos más altos y ventanas operativas más ajustadas.
La actualización se detalla en la propuesta técnica SIMD-0525, uno de los Solana Improvement Documents numerados mediante los cuales se especifican los cambios del protocolo central antes de que los validadores los adopten en el software cliente, y se sigue en la página oficial de actualizaciones de Solana. Completa un despliegue escalonado que comenzó el 21 de agosto, cuando la red pasó de su configuración original de 400 milisegundos a 350 milisegundos, seguido de reducciones a 300 milisegundos el 28 de agosto y a 250 milisegundos el 18 de septiembre.
Cinco oportunidades de producción de bloques por segundo
A 200 milisegundos, la cadena de bloques apuntará a cinco oportunidades de producción de bloques por segundo, en comparación con 2.5 bajo la configuración original de 400 milisegundos. Un slot es la breve ventana en la que un validador designado puede añadir transacciones a la cadena de bloques. Slots más cortos significan que las aplicaciones de trading, las billeteras y los intercambios pueden recibir información actualizada con mayor frecuencia, reduciendo el tiempo que una transacción enviada puede pasar esperando ser procesada. Dado que los usuarios finalmente experimentan el rendimiento de la red como tiempo de confirmación, el ritmo de producción de bloques determina la respuesta de la cadena para aplicaciones sensibles a la latencia, como el trading.
Los bloques más rápidos podrían reducir los retrasos en las transacciones y las prácticas de explotación comercial, pero también aumentarán las demandas de votación de los validadores, presionarán las conexiones de red y acortarán la ventana de validez de las transacciones.
La propuesta también limita cuánto trabajo de cómputo pueden empaquetar los validadores en cada bloque. A 200 milisegundos, cada bloque puede llevar un máximo de 30 millones de unidades de cómputo, frente a 37.5 millones a 250 milisegundos. Los bloques llegan con más frecuencia, pero cada uno transporta proporcionalmente menos trabajo, manteniendo la capacidad teórica de procesamiento de la red prácticamente sin cambios.
Ventanas de ordenamiento más ajustadas mayores costos para los validadores
Los validadores seguirán produciendo bloques en grupos de cuatro slots consecutivos. Su ventana ininterrumpida para ordenar transacciones se reducirá, en consecuencia, de 1.6 segundos bajo la configuración original a 800 milisegundos. Eso podría reducir las oportunidades de retrasar transacciones o explotar precios que ya se han movido en otros intercambios antes de que Solana se ponga al día.
El reloj más rápido también tiene costos. Los validadores que presentan votos en cada slot deberán hacerlo aproximadamente el doble de frecuentemente que bajo la configuración original, lo que aumenta los gastos de votación y ejerce mayor presión sobre las conexiones de red.
Las billeteras y otras aplicaciones también tendrán menos tiempo para usar un blockhash reciente, una referencia incluida en las transacciones para evitar que se reenvíen. La ventana de validez más corta podría complicar las transacciones que requieren aprobación manual o firmas fuera de línea.
El rendimiento real de la red sigue siendo una prueba
Datos de Solana Compass muestran que la configuración anterior de 250 milisegundos arrojó tiempos promedio de slot de aproximadamente 266 a 269 milisegundos en los epochs recientes, ligeramente más lento que su objetivo.
La reducción final ya se ha implementado en la testnet y la devnet de Solana antes de la activación en la mainnet. Los desarrolladores han señalado que el despliegue en la mainnet depende de las condiciones de la red, en particular de la tasa a la que los validadores pierden sus oportunidades asignadas de producción de bloques. Una vez que el cambio entre en vigor, el punto de referencia a observar será si los tiempos promedio de slot convergen hacia el nuevo objetivo de 200 milisegundos en los epochs posteriores.
Se espera que la transición ocurra en el límite del epoch 1053 el viernes.
Fuente: CoinDesk