Solana se actualiza con Agave 3.1: 2x más rápido, reinicio en 1 minuto y SIMD-0339 activado

La nueva versión del cliente validador, mantenido por Anza, reduce las lecturas de disco en un 93% durante el replay. Además, acerca el límite de cuentas en CPI de 64 a 255, una bendición para los desarrolladores.

Solana ha encendido Agave 3.1, la nueva versión de su cliente validador principal. Y los números que trae consigo merecen una parada: duplica el procesamiento de transacciones, reduce los reinicios del nodo a menos de un minuto y, durante el replay (la reproducción del estado de la cadena), la actividad de disco cae un 93%. Para los desarrolladores que construyen aplicaciones sobre la red, el límite de cuentas en invocaciones entre programas pasa de 64 a 255, un respiro que se esperaba desde hace años.

La actualización la ha publicado Anza, el equipo de ingeniería que mantiene el cliente Agave (el software que ejecutan los validadores para mantener la red en consenso). Y aunque cada nueva versión trae mejoras, esta entrega se siente distinta: acelera el presente y prepara el terreno para el futuro consenso Alpenglow, el gran salto que reorganizará cómo se validan y distribuyen las recompensas en Solana.

Publicidad

Agave 3.1: qué cambia para usuarios y desarrolladores

El cambio más visible para quien opera un validador es la velocidad de reinicio. Con Agave 1.*, un reinicio podía superar los 30 minutos; con Agave 2.* bajó de los 10. Ahora, con la 3.1, el proceso se completa en menos de 60 segundos. Dicho de otro modo: si un validador necesita mantenimiento o sufre un fallo, vuelve a estar en línea casi tan rápido como un router doméstico.

A esa ganancia se suma una reescritura profunda de la lectura de disco durante el replay. Según los datos del equipo de Helius, las operaciones de I/O en una ventana de 10 segundos pasan de más de 1.100 eventos a menos de 80, una reducción del 93%. Menos lecturas de disco significan menos desgaste físico y, sobre todo, menos latencia en el momento crítico en que el nodo se sincroniza con la cadena.

Pero la joya para los constructores es SIMD-0339: el límite de cuentas que se pueden pasar en una invocación entre programas (CPI) salta de 64 a 255. Hasta ahora, cualquier aplicación que necesitara manejar listas largas de cuentas — como los wrappers de agregadores de intercambio (Jupiter, DFlow) — se veía obligada a trocear y recomponer las llamadas. Con el nuevo límite, esos cuellos de botella se alivian, aunque la actualización introduce costes de cómputo escalables para que los programas sigan teniendo incentivos para no abusar.

Además, se activa SIMD-0194, que simplifica el cálculo del rent (el coste de almacenar datos en la cadena) eliminando operaciones con decimales que consumían 256 unidades de cómputo y las reduce a apenas 8. Esto es solo el primer paso para abaratar el estado, un requisito imprescindible para que los airdrops masivos de tokens o los pagos con stablecoins dejen de ser prohibitivos cuando se escalan a millones de usuarios.

Reducir el tiempo de reinicio de un validador de media hora a menos de un minuto es como cambiar un motor diésel por uno eléctrico: el tiempo de parada se evapora y la red respira más estable.

Por qué importa esta mejora para la seguridad y el rendimiento de Solana

Detrás de las cifras de rendimiento hay un trabajo de blindaje que Anza ha decidido hacer público. Un equipo dedicado de invalidadores ataca la testnet de Solana con nuevos escenarios cada hora. Prueban denegaciones de servicio a nivel de red, inyectan transacciones adversariales y modelan ataques realistas: lo que podría intentar un validador malicioso con un stake razonable o un desarrollador externo bien financiado.

Que una red descentralizada resista un ataque DDoS de hasta 6 Tbps — como el que sufrió Solana en diciembre y que apenas afectó a las confirmaciones — no es casualidad. Agave 3.1 recoge ese aprendizaje y lo traduce en una gestión de transacciones mucho más eficiente. Antes, los hilos del banking stage pasaban el 61% del tiempo sin procesar transacciones, ocupados en sincronizarse con el Proof of History. Ahora, con los ajustes de código, más del 91% del tiempo se dedica a ejecutar operaciones, lo que explica la duplicación de la velocidad.

Para los validadores, la actualización incorpora además la Vote Account V4 y la activación programada de SIMD-0249. La primera prepara el terreno para la distribución de recompensas de bloque dentro del protocolo (algo que hoy ocurre fuera de la cadena) y permite que cada validador separe la cuenta donde recibe ingresos por inflación de la de ingresos por tasas, un detalle que resuelve dolores de cabeza operativos con carteras frías. La segunda introduce un retardo obligatorio de una época completa antes de que un cambio en la comisión del validador se haga efectivo, lo que corta de raíz la práctica de subir la comisión al 100% justo antes del corte de época para capturar recompensas y luego bajarla.

Análisis: Solana se endurece antes del consenso Alpenglow

Visto con perspectiva, Agave 3.1 no es un simple parche. Es la actualización que cierra los flecos que quedaban abiertos tras la madurez alcanzada con la serie 2.* y que prepara el terreno para Alpenglow, la próxima gran revisión del consenso. Mejorar los reinicios a menos de un minuto, reescribir la lectura de disco y duplicar la velocidad de procesamiento son, en realidad, condiciones previas para que una red que aspira a liquidar millones de operaciones al día pueda absorber un rediseño del reparto de recompensas sin tropezar.

Conviene no olvidar de dónde viene Solana. Las paradas de red de 2021 y 2022, la crisis reputacional tras el colapso de FTX y la dependencia de un solo cliente validador durante años son cicatrices que forman parte del relato de cualquier inversor institucional que mira el activo. Cada línea de código que se endurece, cada test adversarial que se publica, es un ladrillo que reconstruye la confianza.

Dicho esto, el riesgo no ha desaparecido. Aunque Firedancer (el cliente alternativo de Jump Crypto) avanza hacia mainnet, hoy Agave sigue siendo el cliente dominante. Que la red dependa de un único equipo de desarrollo para el software de validación mayoritario es una concentración que ningún protocolo verdaderamente descentralizado debería normalizar. La buena noticia es que, con Agave 3.1, ese cliente único es ahora mucho más rápido, más robusto y más predecible.

La hoja de ruta que dibuja Anza — con un Agave 4.0 que promete reinicios por debajo de 30 segundos y el despliegue completo de Alpenglow — da sentido a esta actualización. El capital que fluye hacia Solana necesita ver que la red no solo corre más, sino que tropieza menos. Y Agave 3.1, con sus cifras sobre la mesa, es un argumento sólido para esa conversación.


Publicidad