La red Solana ha activado Agave 4.1, una actualización del cliente validador que reduce la carga de entrada/salida (I/O) durante la reproducción de bloques en un 93% y despliega los primeros componentes del nuevo consenso Alpenglow. La renovación incluye la adopción masiva de XDP —el camino rápido de red que evita el procesamiento estándar del kernel de Linux— y un conjunto de reescrituras de programas que liberan capacidad en cada bloque sin pedir a los desarrolladores que modifiquen sus aplicaciones. El código de Agave 4.1 está disponible en el repositorio oficial de Anza en GitHub.
XDP pasa de experimental a estándar y acelera la red
XDP (eXpress Data Path) permite a Agave cargar un pequeño programa eBPF cerca de la tarjeta de red, de modo que el tráfico de bloques evita la pila de red tradicional de Linux. Esto reduce la latencia y la carga de CPU en Turbine, el protocolo de propagación de bloques de Solana. Tras superar el umbral crítico en el que más de dos tercios de los validadores ya lo utilizan,Anza ha retirado la etiqueta de ‘experimental’ y simplificado los comandos de configuración. En la próxima versión, Agave 4.2, XDP estará activado por defecto, allanando el camino hacia bloques de 100 millones de unidades de cómputo (CU), un objetivo largamente perseguido.
Las reescrituras Pinocchio liberan hasta un 10% de capacidad en cada bloque
El equipo de Anza ha aplicado la biblioteca Pinocchio —un entorno de desarrollo ligero y sin dependencias— para reescribir algunos de los programas más utilizados de Solana. Primero fue p-token, que redujo el consumo de cómputo en cerca de un 95% y liberó casi el 9,5% de la capacidad total de bloque. Ahora llegan p-memo y p-ATA. La primera, una reimplementación del programa Memo, reduce el coste de las transacciones con firmantes múltiples hasta en un 98%. La segunda, aún en desarrollo, ataca al programa de cuentas de token asociadas, que aparece en el 11,9% de las transacciones y consume el 13,3% del cómputo global. Se espera que p-ATA recorte el uso de unidades de cómputo en un 80,9% de media, lo que podría traducirse en un ahorro adicional de hasta el 10% del espacio disponible en cada bloque.
De forma paralela, la mejora SIMD-0449 optimiza la entrada a los programas virtualizados, reduciendo la sobrecarga de análisis de cuentas de 504 a 7 unidades de cómputo. En conjunto, estos cambios multiplican la eficiencia sin que los usuarios tengan que migrar sus aplicaciones.
Anza ha optado por hacer el software más eficiente en lugar de pedir a los desarrolladores que migren: una lección de ingeniería que beneficia a toda la red.
Alpenglow se asoma con BLS, tickets de admisión y un clúster de pruebas comunitario
La gran apuesta de futuro es Alpenglow, un nuevo mecanismo de consenso que sustituirá al actual Tower BFT (basado en Proof of History). Durante este ciclo se activan tres piezas: la gestión de claves BLS en las cuentas de voto (SIMD-0387), los Validator Admission Tickets (SIMD-0357) que establecen un coste fijo de 1,6 SOL por época para participar en el consenso, y los marcadores de traspaso rápido de líder (SIMD-0337). Además, desde mayo funciona un clúster de pruebas con un centenar de validadores distribuidos geográficamente, donde se alterna entre Tower BFT y Alpenglow para ensayar la migración en condiciones reales. La comunidad puede seguir los paneles de Valid Blocks, Staking Facilities o Noders.
Análisis: los cimientos de la próxima generación de Solana
Estas actualizaciones no son meros parches. Reflejan una madurez creciente del ecosistema: una cadencia de lanzamiento cada seis semanas, un enfoque en eficiencia sin romper la compatibilidad y la transición cuidadosa hacia un consenso más robusto. Sin embargo, persisten riesgos: la dependencia funcional del cliente Anza (hasta que Firedancer alcance una cuota significativa) y la necesidad de que las pruebas comunitarias de Alpenglow sean exhaustivas para evitar sorpresas. La adopción masiva de XDP y la llegada de los tickets de admisión apuntalan la economía de la red y preparan el terreno para tiempos de bloque de 200 milisegundos y bloques más grandes, previstos para Agave 4.2. Para el inversor, cada ganancia de eficiencia se traduce en menores costes de transacción y una red más atractiva para proyectos institucionales.
