Solana ha dado un nuevo paso en la evolución de su infraestructura. La versión 4.1 del cliente validador Agave ya está activa en mainnet y dos terceras partes de la red han adoptado eXpress Data Path (XDP), el acelerador de red que reduce la latencia en la propagación de bloques. Con esta actualización, el ecosistema acelera su preparación para Alpenglow, la próxima gran revisión del consenso que abandonará el actual Tower BFT para mejorar la velocidad y la eficiencia de las votaciones.
Por qué Agave 4.1 no es una simple actualización de mantenimiento
Agave 4.1 trae consigo varios cambios invisibles para el usuario final, pero críticos para los operadores de nodos. Entre ellos destacan la gestión de claves BLS –necesaria para que los validadores se registren de cara a Alpenglow– y los Validator Admission Tickets (VAT), un nuevo mecanismo de admisión que cobrará 1,6 SOL por época a cada validador participante. Ambos hitos permiten que la transición al nuevo consenso sea gradual y ordenada.
Además, la actualización activa SIMD-0449, una optimización del punto de entrada de los programas que elimina la necesidad de analizar manualmente las cuentas. Con ella, un programa Pinocchio con 64 cuentas pasa de consumir 504 unidades de cómputo a solo 7, liberando recursos que antes se desperdiciaban en tareas repetitivas.
XDP cruza la barrera de los dos tercios y apunta a bloques de 100 millones de unidades de cómputo
El camino hacia bloques de 100 millones de unidades de cómputo (compute units o CUs) pasa por la adopción masiva de XDP. Esta tecnología carga un programa eBPF cerca de la tarjeta de red para que el tráfico de shreds –los paquetes en los que se fragmentan los bloques– esquive gran parte del procesamiento estándar de Linux. En las últimas semanas, más de dos tercios de los validadores ya lo han activado, y Agave 4.1 elimina la etiqueta de “experimental” para convertirlo en una opción oficial con nuevos flags de configuración.
El impacto es tangible. Cuando la mayoría de los leaders use XDP, la red podrá elevar el límite de cómputo por bloque sin comprometer los tiempos de consenso. El cliente Agave 4.2, previsto para más adelante, habilitará XDP por defecto y traerá consigo la esperada reducción del slot time de 400 a 200 milisegundos.
Pinocchio aligera los programas más usados: p-memo y p-ATA reducen hasta el 95% del cómputo
La reescritura de los programas nativos de Solana con la librería Pinocchio es una de las palancas más efectivas de esta actualización. Ya lo demostró p-token, que rebajó el consumo de las instrucciones del programa SPL Token al 5% de su coste original, liberando cerca del 9,5% de la capacidad total de un bloque.
Ahora le toca el turno a p-memo y p-ATA. P-memo, ya desplegado, rebaja el gasto de una transacción con un firmante de 13.525 CUs a solo 513. Con dos firmantes, la caída es aún más brusca: de 25.111 a 628 CUs. Mientras, p-ATA, que reescribe el programa de cuentas de token asociadas –el quinto más invocado de la red–, promete un ahorro de de aproximadamente el 80% en el cómputo ponderado. A los niveles de uso actuales, eso supone liberar más de 2,78 millones de CUs por bloque, alrededor del 10% del total de mainnet.
Con Pinocchio, Solana reduce el consumo de cómputo en operaciones cotidianas hasta un 95%, liberando espacio para millones de transacciones adicionales sin tocar las comisiones.
Alpenglow se asoma: tickets de admisión, claves BLS y un cluster comunitario de pruebas
La preparación para Alpenglow no se limita al código. Desde mayo, un cluster comunitario de prueba con un centenar de validadores geográficamente distribuidos está ejecutando la migración en condiciones reales. El objetivo es que el cambio de Tower BFT a Alpenglow sea lo más aburrido posible. Los operadores alternan entre ambos sistemas para verificar que la transición se produce sin sobresaltos.
En paralelo, los VAT mantienen una barrera económica parecida a la actual: mientras que hoy los validadores pagan alrededor de 2,1 SOL por época en comisiones de voto, con los VAT desembolsarán 1,6 SOL de una sola vez, deducidos directamente de su cuenta de voto. La novedad es que, si hay más de 2.000 validadores que cumplen los requisitos, el conjunto votante se limitará a los 2.000 con mayor peso en staking. Una medida que busca evitar una expansión súbita e incontrolada del set de validadores tras la activación de Alpenglow.
El riesgo de concentración y la apuesta por la eficiencia
La limitación del conjunto votante a los 2.000 validadores con más stake ha levantado suspicacias entre quienes temen una deriva centralizadora. Sin embargo, el diseño de los VAT es temporal y está calibrado para replicar los costes del modelo actual. La apuesta de Solana sigue siendo la misma: maximizar el rendimiento sin sacrificar la descentralización en la capa de ejecución, algo que iniciativas como Pinocchio y XDP refuerzan.
Conviene recordar que la red ya ha superado fases de concentración similares en ciclos anteriores, desde las paradas de 2021 hasta la dependencia casi exclusiva del cliente original. Hoy, con Firedancer en el horizonte y un ecosistema de validadores más diverso, el camino parece más sólido. La pregunta no es si Alpenglow llegará, sino si lo hará lo bastante rápido para mantener la ventaja competitiva de Solana frente a otras redes de alto rendimiento.
