Agave 4.0, la próxima gran actualización del cliente validador principal de Solana, ya está en fase de candidato a mainnet. Según detalla Helius en su último análisis, esta versión no solo acelera la propagación de bloques con XDP, sino que además eleva el stake mínimo de 1 lamport a 1 SOL y siembra las bases técnicas para Alpenglow, un rediseño del consenso que llegará en los próximos meses.
Para quien no esté familiarizado, Agave es el software que ejecutan los validadores para mantener la red en pie, y cada gran versión suele traer mejoras que se notan en las comisiones y en la estabilidad. Esta vez el salto es especialmente relevante porque combina tres pilares: rendimiento de red, ajustes económicos en el staking y nuevos ladrillos criptográficos.
XDP: el acelerador de Turbine que ya pueden usar todos los validadores
Cuando un validador produce un bloque, tiene que repartir sus fragmentos (shreds) al resto de la red. Ese protocolo de propagación se llama Turbine, y en bloques muy grandes puede convertirse en el cuello de botella. Ahora mismo, los validadores más potentes ya rondan los 150.000 paquetes por segundo; si el límite de unidades de computación sube a los 100 millones previstos, la cosa se atascaría de inmediato.
Aquí es donde entra XDP (eXpress Data Path). En lugar de que cada paquete pase por todo el sistema operativo antes de ser reenviado, XDP carga un pequeño programa eBPF justo al lado de la tarjeta de red. Es un poco como habilitar un carril exprés en una autopista de peaje: los shreds se despachan casi sin intermediarios. El resultado en producción es contundente: la retransmisión de Turbine mejora en órdenes de magnitud, según los datos que comparte Helius.
En esta versión, el módulo XDP se ha endurecido, se ha probado bajo múltiples configuraciones y se considera suficientemente robusto para que la mayoría de los validadores lo active. El paquete candidato a mainnet, Agave v4.0.0-rc.0, anima a los operadores a ir dando el paso.
De 1 lamport a 1 SOL: la nueva barrera de entrada al staking
Un cambio pequeño en apariencia pero con una lectura estratégica interesante: el programa de staking v5, que llega empaquetado en Agave 4.0 tras la propuesta SIMD-0490, eleva la delegación mínima de staking desde 1 lamport (una fracción casi nula) hasta 1 SOL.
El motivo no es recaudatorio: Solana prepara una reducción de las fianzas de alquiler (las rent bonds) para las cuentas de staking. Si el coste de crear y mantener una cuenta de stake bajara demasiado, mantener el umbral en 1 lamport abriría un vector de ataque con inundación de cuentas minúsculas. Subirlo a 1 SOL lo vuelve económicamente inviable. Las cuentas por debajo de ese umbral apenas representan el 0,02% del total de SOL delegado y se mantendrán sin cambios (serán ‘abueladas’), así que el impacto práctico para la gran mayoría de los stakers es nulo.
Eso sí, las carteras y las herramientas que interactúan con el programa de staking deberán adaptar sus interfaces para mostrar correctamente el nuevo mínimo. Un cambio que, siendo casi invisible para el usuario medio, ordena la casa antes de la siguiente bajada de costes de almacenamiento.
Con XDP la red de Solana está despejando el atasco que limitaba los bloques grandes, y eso es el primer paso para que la máquina pueda correr a toda velocidad.
Criptografía y Alpenglow: los cimientos del nuevo consenso
Agave 4.0 también despliega varias activaciones criptográficas que allanan el terreno a Alpenglow, el próximo mecanismo de consenso que sustituirá al actual Tower BFT con un enfoque de confirmación más rápida. La más destacada es la llegada de las llamadas al sistema BLS12-381, una curva elíptica de 128 bits que usan ecosistemas como Ethereum y que ahora Solana adopta de forma nativa.
Hasta ahora, los desarrolladores tenían que apañárselas con curvas BN254 (menos seguras) o con implementaciones externas como solana-alt-bn128-bls. Con los nuevos syscalls, las pruebas de conocimiento cero y las firmas BLS son verificables directamente dentro de un programa on‑chain. Esto es clave para que los validadores puedan comprobar la posesión de las claves BLS sin exponerse a ataques de clave falsa, uno de los pilares de la seguridad de Alpenglow.
Además de BLS12-381, la actualización incluye la vuelta del programa de verificación ZK ElGamal (desactivado en junio de 2025 por un fallo en el proceso Fiat‑Shamir), el soporte para operaciones en G2 de la curva BN254 y la compatibilidad con formato little-endian, que facilita la integración de herramientas del ecosistema Ethereum. Todas son activaciones que van escalonadas (feature‑gated) para que la red las digiera sin sobresaltos.
Paralelamente, dos cambios ―la validación de la cadena de bloques mediante el Chained Block ID y los marcadores de Fast Leader Handover― reducen las ambigüedades que antes obligaban a los validadores a esperar a tener el bloque completo antes de construir el siguiente. En la práctica, esto acorta el tiempo entre líderes y mejora el rendimiento general, precisamente lo que busca Alpenglow cuando aterrice en mainnet durante el tercer trimestre de 2026 junto con Agave 4.1.
Más allá del titular: qué significa este paso para Solana
Visto con perspectiva, Agave 4.0 no es una simple versión de mantenimiento. Aborda dos de los frenos que han acompañado a Solana en los picos de actividad: el cuello de botella de Turbine (con XDP) y la necesidad de una base criptográfica sólida para el consenso del futuro (con BLS12-381 y los ajustes de Alpenglow).
El ajuste del stake mínimo, por su parte, muestra el mimo con el que el ecosistema va afinando los incentivos económicos. La red ya no puede permitirse grados de libertad que parecían irrelevantes cuando el stake medio era de cientos de SOL. Hoy, 1 SOL es una barrera baja, pero suficiente para desincentivar el spam.
Sin embargo, conviene leer la letra pequeña: muchas de estas mejoras están protegidas por feature gates y requieren que los validadores las activen. La historia reciente enseña que esos despliegues pueden ser lentos, y la reactivación de ElGamal, aunque auditada, pone a prueba la memoria del incidente de 2025. Dicho esto, el rumbo es coherente: cada capa de software se prepara para bloques más grandes y un consenso más rápido. La hoja de ruta hacia Alpenglow parece sólida; ahora queda ver cómo se traduce en términos de TPS reales y en la estabilidad de la red en los meses que vienen.
