Cliente validador de Solana Agave 4.1 acelera la red: bloques más grandes y slots de 200 ms rumbo a Alpenglow

La nueva release del cliente validador introduce un ciclo de seis semanas, gestión de claves BLS y admisión de validadores de cara a Alpenglow. El XDP ya supera el 66% de la red y las reescrituras Pinocchio ahorran millones de unidades de cómputo por bloque.

Agave 4.1 no es solo una actualización más. Es la primera pieza que, según Anza, deja a Solana lista para los bloques de 100 millones de unidades de cómputo, los tiempos de slot de 200 milisegundos y, en última instancia, la transición del consenso a Alpenglow. La versión, que ya puede desplegarse en la red principal (mainnet), introduce una cadencia de lanzamientos cada seis semanas y recoge el testigo de una comunidad de validadores que ya ha probado la futura arquitectura en un clúster de pruebas.

Qué trae Agave 4.1: bloques más grandes y una red más rápida

El objetivo declarado por el equipo de Anza es doble: mejorar la eficiencia del validador en el día a día y cimentar el camino hacia Alpenglow, la gran actualización del consenso que reemplazará al actual Tower BFT. Entre las mejoras más notables está la reducción del uso de memoria RAM en los validadores y la preparación para los tiempos de slot de 200 milisegundos, aunque su activación definitiva se espera para la versión 4.2. Un slot es el intervalo en el que un líder propone un bloque; actualmente dura 400 milisegundos. Si se reduce a la mitad, la confirmación de transacciones será notablemente más rápida.

Publicidad

Además, Anza ha instaurado un ciclo de lanzamientos cada seis semanas, lo que asegura un goteo constante de mejoras en lugar de las grandes actualizaciones espaciadas que se veían antes. Para los operadores de validador, esta cadencia más predecible facilita la planificación de las migraciones.

El paso a Alpenglow: claves BLS y boletos de admisión de validadores

Agave 4.1 mejoras

La gran meta de todo este trabajo es Alpenglow, un nuevo mecanismo de consenso que sustituirá a Tower BFT y que, en su propuesta más concreta (Constellation), introduce un sistema de proponentes y atestadores múltiples para limitar el poder del líder. Para que la transición sea suave, Agave 4.1 activa tres piezas clave.

La primera es la gestión de claves BLS (SIMD-0387). Los validadores pueden ahora registrar una clave pública BLS en su cuenta de voto. Esto es necesario porque Alpenglow usará firmas agregadas BLS para abaratar la verificación de los votos, y las claves BLS son distintas de las actuales Ed25519. Sin una clave BLS registrada antes de la activación de Alpenglow, un validador no podrá participar en el nuevo sistema de votación.

El segundo elemento son los boletos de admisión de validadores (Validator Admission Tickets, VAT). Hoy los validadores pagan comisiones por cada voto que emiten, sumando aproximadamente 2.1 SOL por época (el período de aproximadamente dos días en Solana). Con Alpenglow, ese modelo de votos continuos desaparece, así que el VAT introduce en su lugar un coste fijo por época de 1.6 SOL que se deduce directamente de la cuenta de voto. Así se mantiene una barrera económica similar y se evita una explosión incontrolada del número de validadores cuando Alpenglow reduzca los costes operativos. Si al cruzar a una nueva época hay más de 2.000 validadores que cumplan los requisitos (tener clave BLS y saldo suficiente), solo los de mayor participación en staking serán admitidos.

Agave 4.1 no es un parche: es el encofrado sobre el que se vierte el hormigón del nuevo consenso de Solana.

La tercera pieza son los marcadores de Fast Leader Handover (SIMD-0337), pensados para reducir los retardos de sincronización entre líderes consecutivos y agilizar la producción de bloques. Todo ello se está probando en un clúster comunitario de prueba formado por unos 100 validadores repartidos geográficamente que cambian entre Tower BFT y Alpenglow bajo condiciones reales. El objetivo es que, cuando llegue el momento de activar Alpenglow en mainnet, el proceso sea lo menos traumático posible.

XDP se hace mayor y Pinocchio lima el gasto de cómputo para toda la red

Mientras se construye el futuro, el presente también mejora. La tecnología XDP (eXpress Data Path) permite al cliente Agave cargar un programa eBPF cerca de la tarjeta de red y saltarse gran parte del procesamiento de paquetes del sistema operativo Linux. En esta versión, XDP pierde la etiqueta de experimental: más de dos tercios de los validadores ya la usan, y en Agave 4.2 estará activada por defecto. Sin XDP, alcanzar el ansiado límite de 100 millones de unidades de cómputo por bloque sería inviable.

Otro frente de eficiencia es la librería Pinocchio, una alternativa ligera al SDK estándar de Solana. Anza la ha usado para reescribir algunos de los programas más invocados de la red sin cambiar su funcionalidad, solo para que consuman menos cómputo. El programa de tokens SPL, por ejemplo, ya se reescribió como p-token y redujo su gasto en torno al 95%. Ahora llega p-memo (el programa de memos, que llega a consumir solo entre un 2% y un 14% del cómputo original) y está en marcha p-ATA, la reescritura del programa de cuentas asociadas de token, que aparece en casi el 12% de las transacciones y consume el 13% de todo el cómputo de la red. Las estimaciones apuntan a que p-ATA liberará más de 2,78 millones de unidades de cómputo por bloque, un ahorro global de aproximadamente el 10%.

Por si fuera poco, la mejora SIMD-0449 añade punteros directos a las cuentas en la entrada del programa, eliminando la necesidad de analizar las cuentas secuencialmente. Con esta optimización, el coste de entrada de un programa Pinocchio con 64 cuentas pasa de 504 unidades de cómputo a solo 7.

Por qué esta actualización técnica importa para el inversor y el usuario

Detrás de la jerga, Agave 4.1 representa un avance concreto hacia una red más barata y más rápida. Cada unidad de cómputo que se ahorra, cada milisegundo que se reduce en la transmisión de bloques, baja las comisiones que pagan los usuarios y permite que la red absorba más actividad sin degradarse. Con bloques más grandes y slots más cortos en el horizonte, Solana demuestra que puede escalar en la capa base sin depender de soluciones de segunda capa, una diferencia competitiva frente a otros ecosistemas.

La transición a Alpenglow será, sin duda, el mayor desafío técnico de la red desde su creación. Los riesgos no son nulos: si muchos validadores no registran sus claves BLS o no actualizan sus nodos a tiempo, la participación en el nuevo consenso podría ser baja. Afortunadamente, el clúster comunitario de pruebas ofrece un campo de ensayo realista. Por otro lado, esta actualización llega en un momento en que la gobernanza del protocolo empieza a madurar, con propuestas económicas como SIMD-550 y SIMD-553 en discusión, lo que subraya que Solana no solo mejora su rendimiento, sino que también ajusta sus incentivos.

Para el inversor, el mensaje es claro: la infraestructura que sostiene a SOL se endurece y se pule. La red nunca había sido tan estable como en los últimos meses, y Agave 4.1 es la base sobre la que se construirá el próximo récord de transacciones. El único nubarrón: hay que estar atentos a que la comunidad de validadores adopte los cambios a tiempo.


Publicidad