La red Solana se prepara para uno de los saltos técnicos más esperados. Anza, el equipo detrás del cliente validador Agave, ha publicado la versión 4.0.0-rc.0, candidata a mainnet. Esta actualización acelera la verificación de bloques al mover cálculos pesados a segundo plano, incorpora XDP (eXpress Data Path) para que Turbine —el protocolo que propaga los shreds entre validadores— sea mucho más rápido y deja la red casi lista para Alpenglow, el nuevo mecanismo de consenso que llegará en el tercer trimestre.

XDP para Turbine: cómo se evita el atasco de la red

Cuando Solana aspira a bloques de 100 millones de unidades de computación, el principal cuello de botella no está en la ejecución, sino en la propagación. El líder debe enviar fragmentos de bloque (shreds) a cientos de pares, y los validadores más grandes ya rozan los 150.000 paquetes por segundo. XDP (eXpress Data Path) carga un programa eBPF cerca de la tarjeta de red, permitiendo que el tráfico de Turbine se salte gran parte del procesamiento estándar de Linux. En Agave 4.0, esta tecnología sale de pruebas con un rendimiento en retransmisión “órdenes de magnitud” más rápido, según las mediciones compartidas por Helius.

Con XDP, el líder puede enviar los shreds con mucha menos latencia, y los validadores intermedios retransmiten casi sin procesado adicional. El resultado es una red que escala la propagación de bloques al mismo ritmo que crece la carga de transacciones. Para el inversor, esto significa menos riesgo de que un bloque se descarte por retraso y, por tanto, una experiencia de red más fiable incluso en picos de actividad.

XDP convierte a Turbine en una autopista de datos: la capacidad de retransmisión se dispara cuando el líder envía shreds a cientos de validadores simultáneamente.

Verificación en segundo plano: por qué el replay es ahora mucho más ligero

Otra de las grandes mejoras de Agave 4.0 está en la fase de replay, el momento en que un validador repasa un bloque para confirmar que es correcto. Hasta ahora, dos verificaciones pesadas —la cadena de entradas de Proof of History (PoH) y la firma de cada transacción— bloqueaban este proceso. La nueva versión las mueve a segundo plano.

En concreto, la verificación de los hashes de PoH se despacha de forma asíncrona, y la comprobación de firmas Ed25519 se separa del resto del saneamiento de transacciones. Mientras los trabajos en segundo plano confirman la validez, el replay puede seguir procesando. El impacto práctico es un validador menos atascado en momentos de alta demanda, lo que se traduce en confirmaciones más rápidas para el usuario final y menos latencia en las dapps.

El staking sube a 1 SOL y Alpenglow se asoma en cada transacción

Agave 4.0 también renueva el programa de staking. A partir de ahora, la delegación mínima pasa de 1 lamport a 1 SOL, una medida que prepara el terreno para reducir las fianzas de alquiler (rent) sin abrir la puerta a ataques de creación masiva de cuentas. Las cuentas por debajo de este umbral representan apenas el 0,02 % del stake total y se respetarán tras la activación.

Pero el corazón de esta versión son las primeras piezas de Alpenglow, el consenso que sustituirá a TowerBFT. Se han activado las syscalls para la curva BLS12-381, necesarias para verificar pruebas de posesión y evitar ataques de clave impostora. También se incorporan reglas de validación de bloques encadenados y marcadores de fin de slot que permitirán a los líderes empezar a producir bloques sin adivinar si el anterior está completo. Todo ello apunta al lanzamiento de Alpenglow en el tercer trimestre, junto con Agave 4.1.

Una actualización que pone a Solana en la rampa de lanzamiento

Con Agave 4.0, Solana refina sus puntos más dolorosos. La red ya no depende solo de la velocidad bruta de ejecución; acelera también la propagación y la verificación, los dos grandes frenos cuando los bloques crecen. La comunidad de validadores tiene ahora el reto de mover el 25 % del stake hacia la nueva versión para que la activación en mainnet se haga realidad. Es un umbral exigente, pero la apuesta merece la pena: sin esta actualización, el salto a Alpenglow sería mucho más arriesgado.

Desde la perspectiva del inversor, la actualización transmite una señal de madurez técnica. Solana no solo está añadiendo funcionalidades, sino que reescribe caminos críticos con el foco en la estabilidad. El despliegue de XDP, la verificación asíncrona y los preparativos criptográficos recuerdan a los trabajos de infraestructura que precedieron a la llegada de Firedancer, el otro gran cliente validador. Si aquel fue el refuerzo de la descentralización, Agave 4.0 es el fortalecimiento del rendimiento puro.

Eso sí, conviene no perder de vista los riesgos. La adopción del 25 % del stake no está garantizada y cualquier retraso en la migración aplazaría los beneficios. Además, la complejidad de las nuevas funciones —especialmente las syscalls BLS12-381— exigirá auditorías exhaustivas para evitar incidentes como el que en 2025 obligó a desactivar temporalmente el programa ZK ElGamal. Pero lo esencial está sobre la mesa: Agave 4.0 es el primer paso firme hacia el Solana que veremos en 2027.

La comunidad de Solana debate una de las actualizaciones más relevantes de sus tokenomics. La nueva SIMD-550 propone duplicar la velocidad a la que se reduce la inflación de la red, pasando del ritmo actual del 15 % anual al 30 %. Si se aprueba, el calendario de emisiones se recortaría en unos 18,9 millones de SOL durante los próximos seis años, lo que a precios actuales equivale a algo más de 1.500 millones de dólares. ¿Qué significa esto para quien tiene SOL en staking o sigue la red como inversión? Vamos a desgranarlo.

La propuesta es una actualización directa de la SIMD-411, que llevaba meses en el cajón a la espera de nuevas herramientas de gobernanza. Aquella ya planteaba duplicar la llamada desinflación (el mecanismo por el cual la emisión anual de SOL baja gradualmente). Ahora, con la infraestructura necesaria para que los stakers también voten, la SIMD-550 retoma el testigo y lo hace con un argumento demoledor: el tiempo corre y cada mes de retraso diluye el ahorro potencial en emisiones.

¿En qué consiste exactamente la SIMD-550?

Hoy, la inflación de Solana sigue tres parámetros: una tasa inicial del 8 %, un ritmo de desinflación del -15 % anual y una tasa terminal a largo plazo del 1,5 %. Con esos números, la red alcanzaría su inflación mínima en torno a 2032. La SIMD-550 cambia una única variable: sube la desinflación al -30 % anual, lo que acorta el calendario a 2,8 años. Así, la tasa del 1,5 % se alcanzaría ya en el primer semestre de 2029.

Este movimiento no es un recorte brusco. Acelera la trayectoria que ya estaba prevista y la hace más predecible. La propia hoja de ruta de la Solana Foundation contempla propuestas complementarias, como la SIMD-553 (quemar un recurso extra en las comisiones) o los Validator Admission Tickets de Alpenglow, que buscan modernizar una política monetaria que muchos consideran anclada en la fase de arranque de la red.

Por qué Solana necesita pisar el freno de la inflación

En sus primeros años, una emisión alta tenía sentido: había que distribuir el stake, asegurar un cadena joven y atraer participantes. Esa etapa, según el análisis de Helius y Steakhouse Financial, ya ha terminado. Solana es una red madura, con actores institucionales y volúmenes que compiten con las finanzas tradicionales. Mantener una inflación elevada solo añade presión vendedora sobre SOL sin la contrapartida de compra que proporcionaba antes el bootstrapping.

Hay, además, un problema muy terrenal: la fiscalidad. En muchas jurisdicciones, las recompensas de staking tributan como ingreso ordinario y obligan a vender una parte para pagar impuestos. Es lo que el investigador Max Resnick bautizó como el “cubo agujereado” (un 17 % que se fuga del ecosistema). Reducir la emisión anual mitiga esa hemorragia. Y no es una cuestión marginal: los modelos indican que, al cabo de seis años, la oferta total de SOL sería un 2,6 % más baja de lo que será sin la SIMD-550. Es decir, 18,9 millones de monedas que no se crearán.

Con los precios actuales, cada mes sin reducir la emisión extra cuesta unos 283.000 SOL que se añaden a la oferta circulante.

Qué supone para los usuarios de staking y los validadores

El dato que más rápido se mira es la rentabilidad nominal del staking. Con la desinflación al 30 %, el rendimiento anual bajaría progresivamente desde el 5,84 % actual hasta el 2,25 % en el tercer año. Es una caída que, traducida a euros, sí se nota, pero el análisis de Helius muestra que apenas afecta a la viabilidad de los validadores: de los 738 nodos que operan hoy, solo 2 dejarían de ser rentables en el primer año, 13 en el segundo y 30 en el tercero.

En otras palabras, la red aguanta el cambio sin desestabilizarse. Y para el inversor que no hace staking activo —la mayoría—, el recorte de emisiones reduce la dilución, lo que suele traducirse en una presión compradora neta más favorable. Dicho de otro modo: menos SOL nuevo diluyendo el valor de los ya existentes.

Conviene recordar que la inflación programada va con retraso. El diseño original asumía épocas de 2 días justos, pero hasta diciembre de 2024 la red no logró mantener ese ritmo. Eso ha provocado que la inflación real se haya quedado 276 días por detrás del calendario teórico. De modo que, incluso con la SIMD-550, el ahorro es menor del que se habría logrado hace un año: la SIMD-411 habría evitado 22,3 millones de SOL; ahora, la cifra se queda en 18,9 millones. El mensaje es claro: cuanto antes gobierne la comunidad, mayor será el impacto.

La propuesta se perfila como uno de los debates clave del verano en Solana. Al duplicar un solo parámetro, evita el galimatías técnico que descarriló la SIMD-228 y concentra el voto en una decisión sencilla: ¿reducimos la emisión futura a la mitad de velocidad? Las cifras que manejan Helius y Steakhouse Financial sugieren que el ecosistema está preparado para dar ese paso, ahora que los grandes desbloqueos ya quedaron atrás y la red compite de tú a tú con las infraestructuras financieras tradicionales.

Agave 4.1 ha llegado a la red principal de Solana con una reducción del 93% en la entrada/salida de disco durante la reproducción de bloques y transacciones que se procesan el doble de rápido. No se trata de un retoque cosmético: la actualización del cliente validador principal sienta las bases para los bloques masivos de 100 millones de unidades de cómputo y para la gran transición a Alpenglow, el nuevo motor de consenso que aspira a jubilar al veterano Tower BFT.

Menos disco y transacciones más ágiles: lo que ganan los validadores

El recorte del 93% en la E/S de disco durante la reproducción de bloques no es un detalle menor para quienes operan un nodo. Cada vez que un validador necesita repasar la cadena para verificar el estado, el acceso a storage era uno de los cuellos de botella más insidiosos. Con Agave 4.1, esa fricción desaparece casi por completo. Además, las transacciones se procesan ahora el doble de rápido, lo que reduce la latencia percibida por los usuarios finales y allana el camino para los tiempos de ranura de 200 milisegundos que se esperan con la próxima versión, Agave 4.2.

La actualización también incluye una rebaja en el consumo de RAM del validador, algo que los operadores con hardware más modesto agradecerán. Anza, el equipo de desarrollo que lidera el cliente Agave, ha acortado el ciclo de lanzamientos mayores a seis semanas: una cadencia casi industrial que transmite madurez y previsibilidad al ecosistema.

Alpenglow se asoma: claves BLS, tickets de admisión y un centenar de validadores probando el nuevo consenso

La gran promesa de Agave 4.1 es que activa las primeras piezas funcionales de Alpenglow, el sustituto de Tower BFT —el mecanismo de consenso actual basado en votos encadenados con Prueba de Historia—. Entre las novedades destacan las claves BLS para las cuentas de voto y los Validator Admission Tickets (VAT), dos engranajes que evitan una entrada masiva y caótica de validadores cuando Alpenglow esté plenamente operativo. Para seguir la implementación detallada, se puede consultar el repositorio público de las SIMD.

Los tickets de admisión (VAT) funcionan como una barrera económica por época: cada validador que desee participar en el proceso de voto bajo Alpenglow abonará 1,6 SOL al inicio del periodo, en lugar de los constantes pagos de comisiones por voto que exige Tower BFT. Ese coste se descuenta directamente de la cuenta de voto, no de la identidad del nodo, lo que simplifica la operativa. Además, si hay más de 2.000 validadores que cumplen los requisitos, el sistema selecciona a los que tienen mayor peso de participación (stake), limitando el tamaño del conjunto de votantes y manteniendo la descentralización sin descontrol.

Un clúster comunitario de cien validadores, repartidos geográficamente, lleva desde mayo alternando entre Tower BFT y Alpenglow en un entorno de pruebas real. El objetivo es que la migración a la red principal sea lo más aburrida posible, sin sorpresas. Los dashboards de Valid Blocks y Noders permiten seguir en directo la actividad de ese banco de pruebas, que se ha convertido en el termómetro oficioso de la salud del futuro consenso.

La combinación de menos dependencia del disco, XDP generalizado y un consenso más rápido está convirtiendo la capacidad de cómputo por bloque en un recurso cada vez más abundante, no en un cuello de botella.

XDP supera el 66% de la red y allana los 100 millones de CU por bloque

El eXpress Data Path (XDP), el acelerador de red que permite a Agave manejar el tráfico de Turbine casi a nivel de hardware, ha dado el salto definitivo. Por primera vez, hay más líderes funcionando con XDP que sin él, y más del 66% de la red ya está activada. Agave 4.1 retira la etiqueta de experimental y simplifica las banderas de configuración: ahora basta con `–xdp-interface`, `–xdp-cpu-cores` y `–xdp-zero-copy`. La próxima versión, Agave 4.2, activará XDP por defecto.

Esta adopción masiva es la llave para alcanzar bloques de 100 millones de unidades de cómputo, una meta que hasta hace poco parecía una utopía técnica. Con XDP, los fragmentos (shreds) de Turbine pueden eludir gran parte de la pila de procesamiento de paquetes del kernel Linux, ganando la microsegundos que, multiplicados por miles de transacciones, se traducen en una red mucho más capaz.

Pinocchio: reescribiendo los programas más usados para exprimir cada CU

Uno de los hilos conductores de Agave 4.1 es la eficiencia computacional. La librería Pinocchio, desarrollada por Anza, permite reescribir los programas más invocados de la red eliminando dependencias superfluas y recortando el gasto de CU. El programa p-memo, ya activo, consume entre el 2% y el 14% de lo que gastaba su predecesor, dependiendo de los firmantes implicados. Con tres firmantes, pasa de 36.406 CU a solo 743 CU.

El siguiente en llegar es p-ATA, una reimplementación del programa de Cuentas de Token Asociadas, que aparece en el 13,3% de todas las transacciones y acapara una porción similar del gasto total de CU. Las estimaciones apuntan a un ahorro ponderado del 80,9 % por transacción, lo que liberaría cerca de 2,78 millones de CU por bloque a escala global. A esto se suma la optimización de la entrada de programa (SIMD-0449), que con punteros directos a cuentas reduce el coste de entrada de 504 CU a tan solo 7 CU en el peor de los casos.

Análisis: por qué Agave 4.1 refuerza la tesis de inversión paciente en Solana

El mercado suele mirar hacia otro lado cuando se publican actualizaciones de cliente validador, pero Agave 4.1 merece una lectura diferente. Las paradas de red —como las de septiembre de 2021, enero de 2022 o febrero de 2023— han sido el talón de Aquiles de Solana y el principal argumento de sus críticos. Cada punto porcentual de mejora en la estabilidad del consenso, cada megabyte menos de disco consumido, reduce la probabilidad de que un pico de carga se convierta en un apagón. La reducción del 93% en E/S de disco durante la reproducción ataca directamente una de las causas raíz de aquellas interrupciones.

Además, la transición hacia Alpenglow introduce disciplina económica con los VAT y la gestión de claves BLS, lo que podría diluir una de las críticas más recurrentes: la concentración del poder de voto en unos pocos validadores con grandes infraestructuras. Al mantener un techo de 2.000 validadores elegidos por peso de stake y cobrar una cuota fija por época, se evita tanto la entrada masiva para minar comisiones como la exclusión por falta de hardware de última generación. Es un equilibrio incómodo pero pragmático.

Con todo, el riesgo existe. La migración desde Tower BFT a Alpenglow no tiene precedentes en una red del tamaño de Solana, y aunque el clúster de pruebas está funcionando, nadie puede garantizar que la activación en la red principal sea indolora. La adopción de XDP también requiere que los operadores actualicen kernels y controladoras de red; un fallo de coordinación podría dejar fuera a una parte del conjunto de validadores justo cuando más se necesita. Pero el historial reciente de Anza —con lanzamientos cada seis semanas y la exitosa activación de p-token sin incidentes— invita a un optimismo moderado. La ruta hacia los bloques de 100 millones de CU ya no es un eslogan: es una realidad técnica medible.