Solana acaba de recibir una actualización silenciosa pero de gran calado. El cliente validador Agave 4.1, desarrollado por el equipo de Anza, no añade nuevas funcionalidades vistosas, pero reduce el consumo de memoria RAM, recorta hasta en un 95% las unidades de computación (Compute Units o CUs, la medida del esfuerzo que realiza la red para procesar una transacción) en varios programas esenciales, y deja todo listo para la llegada de Alpenglow, el futuro mecanismo de consenso que reemplazará al actual Tower BFT.
La actualización, que marca una cadencia de lanzamientos cada seis semanas, incorpora la reescritura de varios programas con la librería Pinocchio —una optimización que reduce drásticamente el uso de recursos—, la adopción masiva de XDP para acelerar la transmisión de bloques, y los preparativos para una transición de consenso que busca hacer la red más rápida y eficiente.
Las mejoras clave de Agave 4.1: menos RAM, menos CUs y XDP por defecto
Uno de los cambios más inmediatos es la reducción del uso de memoria RAM de los validadores. Aunque Anza no ha detallado la cifra exacta, la optimización libera recursos que permitirán manejar bloques más grandes y alcanzar los ansiados tiempos de slot de 200 milisegundos (la mitad del actual).
El frente donde más se nota el avance, sin embargo, es en la poda de las unidades de computación. Gracias a Pinocchio, el programa p-token (ya activo) ahorra un 95% de CUs en las transacciones más comunes. El nuevo p-memo, ya en mainnet, reduce el consumo de 2.022 a 287 CUs sin firmas, y de 13.525 a apenas 513 CUs con un único firmante. En casos con varios firmantes la diferencia es aún mayor: con tres firmantes, el memo original consume 36.406 CUs y p-memo solo 743. Son ahorros de entre el 96% y el 98%.
En desarrollo se encuentra p-ATA, la reescritura del programa de cuentas de token asociadas. Este programa interviene en casi el 12% de todas las transacciones y acapara alrededor del 13% del consumo total de CUs de la red. Las estimaciones de Anza apuntan a que p-ATA podría reducir ese consumo en más de un 80%, liberando unos 2,78 millones de CUs por bloque, lo que se traduciría en un ahorro global del 10% en toda la red principal.
Otra mejora relevante es la consolidación del XDP (eXpress Data Path), la vía rápida que permite a Agave saltarse parte del procesamiento de paquetes del sistema operativo y enviar los datos directamente desde la tarjeta de red. La adopción de XDP ha superado el punto de inflexión: más de dos tercios de los líderes validadores ya lo ejecutan, y en Agave 4.1 ha dejado de ser experimental para convertirse en la opción recomendada. Con XDP se allana el camino hacia los bloques de 100 millones de CUs, un objetivo que la red persigue desde hace años.
La poda silenciosa de Agave 4.1 no es un cambio cosmético, sino el trabajo de fontanería que garantiza que Solana pueda mover bloques el doble de rápido sin ahogarse en costes.
Alpenglow: el nuevo consenso empieza a tomar forma
El verdadero hito a largo plazo es Alpenglow, el mecanismo de consenso que sustituirá al actual Tower BFT (el protocolo que los validadores usan hoy para ponerse de acuerdo sobre el orden de las transacciones). Alpenglow promete votaciones más baratas y rápidas, y Agave 4.1 incluye tres habilitadores fundamentales.
El primero es la gestión de claves BLS, necesarias para las firmas agregadas que usará Alpenglow. Los validadores ya pueden registrar sus claves públicas BLS en sus cuentas de voto, un paso imprescindible para participar en el nuevo proceso una vez que se active el consenso. Quien no lo haga quedará fuera.
El segundo es el Validator Admission Ticket (VAT), un tique de admisión por época. Con Tower BFT los validadores pagan comisiones por cada voto, algo así como 2,1 SOL por época. Alpenglow elimina esos votos, así que el VAT introduce un coste fijo de 1,6 SOL por época que se descuenta automáticamente de la cuenta de voto. Así se mantiene una barrera económica similar y se evita una explosión incontrolada del número de validadores.
El tercer habilitador son los marcadores de traspaso rápido de líder. Estos marcadores permitirán al líder de Alpenglow declarar el bloque padre al inicio y, si es necesario, actualizarlo mientras se transmite el bloque, reduciendo los retrasos entre validadores.
Además, desde mayo una red de pruebas comunitaria con un centenar de validadores reales repartidos por todo el mundo está alternando entre Tower BFT y Alpenglow, probando la migración en condiciones reales. La idea es que el lanzamiento en mainnet sea lo menos traumático posible.
Lo que significa para Solana y sus validadores
Visto con perspectiva, Agave 4.1 recuerda a otras actualizaciones de infraestructura que pasaron casi desapercibidas pero resultaron decisivas, como la introducción de QUIC y stake-weighted QoS en 2022 que ayudaron a estabilizar la red tras las paradas de aquel año. Entonces, Solana necesitaba demostrar fiabilidad; ahora, necesita escalar sin romper nada.
El ahorro de CUs y RAM no es solo una cuestión técnica. Abre la puerta a los slots de 200 milisegundos, previstos para Agave 4.2, y a bloques más densos. Sin estas optimizaciones, la red se ahogaría en sus propios costes computacionales. Y con XDP ya mayoritario, el camino hacia los 100 millones de CUs por bloque parece mucho más real.
Eso sí, la migración a Alpenglow no será trivial. Sustituir el consenso de una cadena con más de 2.000 validadores activos es una operación compleja que requerirá meses de pruebas y, probablemente, algún susto en el camino. Pero las piezas ya están colocándose sobre el tablero.
Mientras tanto, el código abierto del cliente Agave sigue disponible en su repositorio oficial de GitHub, y los paneles comunitarios permiten seguir en tiempo real cómo se prueba Alpenglow. La red, una vez más, se reconstruye en silencio.
