Solana vuelve a apretar el acelerador. La llegada de Agave 4.1, el cliente validador de Anza que utilizan la mayoría de los operadores de la red, supone un salto organizativo y tecnológico con nombre de nevado alpino: Alpenglow. Con esta versión, el ecosistema acelera su cadencia de lanzamientos a cada seis semanas y siembra las bases para bloques de mayor tamaño, tiempos de ranura (slot) de 200 milisegundos y una transición de consenso que llevamos meses esperando.
Ritmo de seis semanas y preparativos para el nuevo consenso
Lo primero que llama la atención es el nuevo ciclo de lanzamientos. Anza, el equipo heredero del desarrollo de validadores de Solana Labs, ha fijado una cadencia de seis semanas entre versiones mayores. Agave 4.1 no es un parche cosmético: es la primera pieza de un rompecabezas que culminará en Alpenglow, el diseño de consenso que sustituirá a la actual Tower BFT (el mecanismo que permite a los validadores ponerse de acuerdo sobre el orden de las transacciones gracias a una cadena de timestamps criptográficos). Desde el 2 de agosto de 2026, el release candidate de esta versión ya está recomendado para uso general en la red principal.
El despliegue de Alpenglow requiere ajustes que Agave 4.1 va activando de forma gradual. Uno de ellos es SIMD-0387, que prepara al programa de voto para gestionar claves públicas BLS. Esta firma agregada hará que los votos de los validadores sean más baratos de verificar, pero exige que cada operador registre una clave BLS en su cuenta de voto antes de que el nuevo consenso entre en acción. Quien no lo haga no podrá participar en la votación cuando Alpenglow se active.
Otro cambio relevante son los Validator Admission Tickets (VAT), regulados por la propuesta SIMD-0357. Hoy, los validadores pagan comisiones de voto cada vez que emiten uno, acumulando unos 2,1 SOL por época. Bajo Alpenglow, esa mecánica desaparece y en su lugar se aplica un coste fijo de 1,6 SOL por época que se deduce directamente de la cuenta de voto al cruzar el límite entre épocas. Así se mantiene una barrera económica equivalente y se evita una explosión repentina del número de validadores. Además, el sistema introduce marcadores de bloque (Fast Leader Handover) que permiten a un líder de Alpenglow declarar y actualizar el padre de un bloque mientras lo emite, lo que reduce los tiempos de sincronización entre líderes y allana el camino a los famosos slots de 200 ms.
La transición no se hace a ciegas. Desde mayo, un clúster comunitario de prueba con un centenar de validadores distribuidos en todo el mundo viene alternando entre Tower BFT y Alpenglow para verificar que la migración en vivo sea un paseo, no un sobresalto. La actividad se sigue en el canal ag-community-cluster de Discord y en paneles públicos como los de Valid Blocks, Staking Facilities y Noders.
Con Agave 4.1, Solana ensaya en producción el mayor rediseño de su consenso desde el lanzamiento de la red principal: la migración a Alpenglow es una obra de ingeniería planificada paso a paso.
El motor interno acelera: XDP, Pinocchio y bloques más ligeros
Paralelamente, Agave 4.1 sube el voltaje de la infraestructura que permite a la red procesar miles de transacciones por segundo. La adopción de XDP (eXpress Data Path) ha alcanzado un punto de inflexión. Este sistema, que carga un programa eBPF cerca de la tarjeta de red para que los fragmentos de datos (shreds) eviten buena parte del procesamiento estándar de Linux, ha superado el ecuador: más de dos tercios de los validadores ya lo utilizan, y por primera vez hay más líderes con XDP que sin él. La etiqueta “experimental” ha desaparecido, y en la próxima versión (Agave 4.2) vendrá activado por defecto. Eliminar cuellos de botella en la capa de red es la única forma de alcanzar el objetivo histórico de 100 millones de unidades de cómputo por bloque.
La eficiencia también llega a los programas. Las reescrituras con la biblioteca Pinocchio, desarrollada por Anza y sin dependencias externas, están reduciendo el consumo de recursos de los contratos más usados. Tras el éxito de p-token (que recortó el coste de las instrucciones del token estándar en cerca del 95%), Agave 4.1 estrena p-memo y prepara p-ATA. El programa Memo, aunque pequeño, pasará a gastar menos de 300 CU sin firmantes, frente a los más de 2.000 actuales; con varios firmantes, la diferencia es abismal: 743 CU en lugar de 36.406. P-ATA, que reorganiza las cuentas asociadas a un monedero y aparece en el 11,9 % de todas las transacciones, promete un ahorro superior al 80 % en consumo de cómputo. A escala de red, eso se traduce en liberar un 10 % adicional de la capacidad de cada bloque.
Se suma una optimización a nivel de máquina virtual: la propuesta SIMD-0449 añade punteros directos a las cuentas en la entrada de los programas sBPF, lo que elimina la necesidad de recorrer todo el grupo de cuentas para encontrarlas. En las pruebas con Pinocchio, la entrada de 64 cuentas pasa de consumir 504 CU a apenas 7. Es pura ganancia de rendimiento sin coste para el usuario.
Qué significa esto para el inversor y el futuro de la red
Si algo demuestra Agave 4.1 es que Solana ha entrado en una fase de madurez industrial. La aceleración de los lanzamientos, la disciplina en la preparación de Alpenglow y la atención obsesiva al ahorro de recursos no son maniobras cosméticas: son la respuesta a un calendario que ya tiene fecha —aunque no milimétrica— para los slots de 200 ms y los bloques ampliados. Cuando los tiempos de ranura se reduzcan a la mitad, la experiencia de usuario en bolsas descentralizadas, liquidaciones, perpetual swaps o DePIN se acercará a la latencia de sistemas financieros tradicionales, pero con liquidación en cadena. El trabajo que ahora se hace con Pinocchio, XDP y la entrada de punteros directos no es glamuroso, pero es el que permite que esa bajada de latencia no rompa la red por el camino.
El avance hacia Alpenglow tampoco es neutral. La centralización del voto que durante años descansó en Tower BFT dejará paso a un modelo de firmas agregadas donde los operadores necesitan mantener fondos en cuentas de voto y registrar claves BLS. Es una pequeña carga administrativa que, si no se comunica bien, puede dejar fuera a validadores despistados. Pero el diseño de los VAT y la prueba comunitaria en vivo demuestran que Anza no improvisa: quiere que la migración pase desapercibida para el usuario final.
Con todo, el mayor riesgo sigue siendo el de siempre: concentración del staking y dependencia del cliente dominante. Aunque Firedancer y otros clientes avanzan, Agave sigue siendo el estándar que dicta el ritmo del ecosistema. Que las mejoras se entreguen cada seis semanas es una señal de fortaleza, siempre que no aparezcan grietas por el camino. De momento, la red ha respondido bien a la adopción de XDP y al alivio de cómputo. Los números, al menos, acompañan. Veremos si el calendario se mantiene cuando los bloques de 200 ms entren en juego.
