Solana ha reducido el tiempo objetivo de su ranura en la red principal de 400 milisegundos a 350 milisegundos, el primer paso de un plan gradual para reducirlo finalmente a 200 ms.
El cambio entró en vigor al comienzo de la época 1020 el viernes y marca la primera vez que Solana reduce la duración de su ranura objetivo desde el lanzamiento de la red. Es una cifra que parece pequeña, pero que implica un trabajo de ingeniería considerable.
Un slot es el intervalo de tiempo en el que un validador líder puede generar un bloque. Los slots más cortos permiten generar bloques con mayor frecuencia, lo que reduce el tiempo de espera para las confirmaciones de usuarios y aplicaciones. La clave está en la latencia. Esta actualización no está diseñada para duplicar mágicamente el rendimiento de las transacciones de Solana.
La red está avanzando rápidamente hacia los 200 ms.
El plan proviene de SIMD-0525, una propuesta de mejora de Solana elaborada por el ingeniero de Anza, Brennan Watt. En lugar de pasar directamente de 400 ms a 200 ms, la red utiliza cuatro etapas separadas con compuertas de características: 350 ms, 300 ms, 250 ms y, finalmente, 200 ms.
La propuesta oficial de Solana mantiene 64 ticks por ranura, cuatro ranuras por ventana de líder y 432 000 ranuras por época. El número de ranuras permanece igual. La cantidad de tiempo real que representan se reduce.
- Ranuras de 400 ms: épocas de aproximadamente 48 horas y ventanas de líder de 1.6 segundos.
- Ranuras de 350 ms: épocas de aproximadamente 42 horas y ventanas de líder de 1.4 segundos.
- Ranuras de 300 ms: épocas de aproximadamente 36 horas y ventanas de líder de 1.2 segundos.
- Ranuras de 250 ms: épocas de aproximadamente 30 horas y ventanas de líder de 1.0 segundos.
- Ranuras de 200 ms: épocas de aproximadamente 24 horas y ventanas de líder de 0.8 segundos.
El despliegue se está realizando con cautela intencionada. Cada fase tiene su propio umbral de funcionalidades, y los desarrolladores pueden detenerse antes de la siguiente reducción si el rendimiento de los validadores o las tasas de omisión de bloques empiezan a ir en la dirección equivocada. Reducir la latencia es útil. Convertir la red principal en una prueba de estrés involuntaria es menos útil.
350ms ya se está mostrando en Mainnet
Las primeras mediciones en tiempo real sugieren que la red se movió en la dirección prevista. El bloque comparó dos periodos de 1,000 ranuras alrededor de la transición. Un periodo anterior al cambio duró aproximadamente 415 segundos, mientras que una muestra posterior en la época 1020 duró aproximadamente 368 segundos.
Estas cifras variarán naturalmente, ya que un objetivo de 350 ms no significa que cada ranura se ejecute exactamente a los 350 ms. Aun así, demuestran que el cambio en la red principal es más que un simple archivo de configuración. La reducción de la latencia se refleja en la producción real de bloques.
El mismo informe señala que los desarrolladores aún no han fijado una fecha de activación de la red principal para la próxima etapa de 300 ms. Planean observar primero cómo se comporta la red a 350 ms.
Esta no es una actualización de rendimiento gratuita.
Una de las maneras más fáciles de malinterpretar el cambio es suponer que ranuras un 12.5 % más cortas implican automáticamente un 12.5 % más de capacidad de red. SIMD-0525 reduce deliberadamente la cantidad de trabajo permitida en cada ranura a medida que estas se acortan.
Solana aumentó recientemente su límite de bloques en la red principal a 100 millones de unidades de cómputo. Según la propuesta de intervalos más cortos, ese límite por intervalo se reduce a 87.5 millones de unidades de cómputo a 350 ms, 75 millones a 300 ms, 62.5 millones a 250 ms y 50 millones a 200 ms.
El objetivo es mantener la tasa de procesamiento del reloj prácticamente estable, a la vez que se reduce el tiempo de espera de los usuarios entre franjas horarias. Los validadores disponen de menos tiempo para procesar cada franja horaria, pero también se les asigna proporcionalmente menos trabajo dentro de ella.
Esto convierte la mejora en algo principalmente relacionado con la capacidad de respuesta. Los aumentos de capacidad bruta se deben a cambios independientes en los límites de cómputo, el software de validación y el procesamiento de transacciones.
Los periodos de liderazgo más cortos ofrecen una ventaja en la estructura del mercado.
Existe otra razón por la que los desarrolladores prefieren ranuras más cortas que tiene poco que ver con la rapidez con la que una billetera muestra "confirmado".
Actualmente, un líder de Solana controla cuatro ranuras consecutivas. Con el antiguo objetivo de 400 ms, esto le otorgaba a un líder una ventana nominal de 1.6 segundos. Con 350 ms, se reduce a 1.4 segundos, y con el punto final propuesto de 200 ms, sería de 0.8 segundos.
Esto reduce el tiempo máximo que un líder puede retrasar, reordenar o incluir selectivamente transacciones antes de que otro validador tenga su turno. Para los operadores, los creadores de mercado y las aplicaciones sensibles a la latencia, reducir ese margen puede mejorar la estructura del mercado y la experiencia del usuario.
Los intervalos de tiempo más cortos también permiten una medición más precisa del tiempo en la cadena para los sistemas que evalúan la actualidad de los datos, como los consumidores de oráculos y las aplicaciones automatizadas de creación de mercado. La propia documentación de actualización de Solana indica que los creadores de mercado podrían ofrecer diferenciales más ajustados a medida que disminuye la latencia.
Finalidad es un proyecto aparte
Solana puede generar ranuras cada pocos cientos de milisegundos sin alcanzar la finalidad irreversible tan rápidamente. La finalidad completa actual todavía tarda aproximadamente 12.8 segundos.
Ahí es donde entra en juego Alpenglow. La revisión del consenso, que se encuentra en desarrollo, busca reducir el tiempo de finalización a unos 150 ms. Si este trabajo llega a la red principal según lo previsto, representaría un cambio mucho mayor en el tiempo que tarda la red en considerar un bloque como definitivo.
Ambos esfuerzos comparten el objetivo general de reducir la latencia, pero no deben confundirse. SIMD-0525 acorta los intervalos de tiempo según la progresión actual. Alpenglow modifica el propio sistema de consenso y finalidad.
Por qué los comerciantes deberían preocuparse
Para los titulares de SOL comunes, una reducción de 50 ms en el tiempo de espera no les generará un cambio radical de la noche a la mañana. El beneficio de la inversión es más acumulativo.
Solana lleva años compitiendo en velocidad, bajas comisiones y alta frecuencia de actividad en la cadena de bloques. Reducir los tiempos de espera sin desestabilizar a los validadores fortalecería la posición de la red en el comercio, los pagos y las aplicaciones donde la latencia es crucial. Alcanzar los 200 ms reduciría a la mitad la duración objetivo de la ranura, respecto a la configuración original de 400 ms de la red.
El riesgo de ingeniería también aumenta a medida que se acerca el momento oportuno, por lo que la implementación por fases es importante. Los próximos hitos no están garantizados simplemente porque se haya implementado la velocidad de 350 ms. Los desarrolladores tienen previsto pasar a 300 ms, luego a 250 ms y finalmente a 200 ms solo si el rendimiento de la red se mantiene óptimo.
Por ahora, Solana ha completado el primer paso real en la red principal. Es más rápida, el cambio es medible y el camino hacia los 200 ms ya no es solo una propuesta en GitHub. La prueba más interesante comienza ahora: si los validadores pueden seguir reduciendo el tiempo de respuesta sin sacrificar la fiabilidad a cambio.
---------------
Escrito por Sebastián Marrow
Sala de prensa europea
Rompiendo Noticias Crypto
