Actualización de Agave 4.1: todo lo que necesitas saber

Introducción

Con Agave 4.1, el cliente validador principal de Solana continúa su evolución constante. Ofrece mejoras de rendimiento hoy y sienta las bases para bloques más grandes, slots de 200 ms y el futuro lanzamiento de Alpenglow.

Actualizaciones destacadas del ciclo de lanzamiento de 4.1

• Mayor frecuencia de lanzamientos, con versiones principales cada seis semanas
• Avances continuos en la preparación para Alpenglow, incluida la gestión de claves públicas BLS*, Validator Admission Tickets* y el clúster de pruebas comunitario
• La adopción de XDP supera un umbral crítico de la red
• Más reimplementaciones con Pinocchio, incluidas p-memo y p-ATA
• Menor uso de RAM por parte de los validadores
• Preparación para slots de 200 ms**

* Mejoras controladas por feature gates

** Previsto para Agave 4.2

Además del trabajo en el cliente principal, Anza y el ecosistema en general también impulsan en paralelo varias iniciativas importantes:

• Constellation: Constellation propone la primera implementación formal y a nivel de protocolo de Multiple Concurrent Proposers (MCP) en una blockchain de producción a gran escala. En lugar de otorgar a un solo líder amplia discreción sobre la inclusión de transacciones, Constellation introduce proponentes y certificadores que limitan lo que el líder puede excluir de un bloque válido.
• Refuerzo ante amenazas cuánticas: El equipo de investigación de Anza comenzó a explorar cómo proteger Solana frente a futuros adversarios cuánticos. Esto incluye investigaciones sobre firmas poscuánticas, migración de cuentas, firmas de consenso, propagación de bloques y verificación de firmas onchain.
• Mejoras económicas: También se prepara una nueva ola de propuestas de tokenómica. SIMD-550 propone duplicar la tasa de desinflación de Solana del -15 % al -30 %, mientras que SIMD-553: tarifa de recursos e inclusión propone dividir la tarifa de firma actual en una tarifa base de inclusión pagada al líder y una tarifa de recursos que se quema en función de las unidades de costo solicitadas.
• Nuevas herramientas de gobernanza: La próxima ronda de propuestas económicas también se beneficia de una mejor infraestructura de gobernanza. Las nuevas herramientas permiten que no solo los validadores, sino también quienes hacen staking, participen directamente en la gobernanza de Solana. Así se amplía el grupo que puede opinar sobre cambios fundamentales del protocolo.

Están ocurriendo muchísimas cosas en este momento.

Ya sea que operes un validador o desarrolles aplicaciones, esta guía te ofrece las novedades y la información que necesitas para aprovechar al máximo las últimas mejoras. Cada sección del artículo es independiente, lo que te permite centrarte en los temas más relevantes para ti. 

Al momento de escribir este artículo, Agave v4.1.0-rc.1 ya se recomienda para uso general en mainnet. Operadores de validadores: ¡es hora de actualizar!

Preparación para Alpenglow

Gran parte de las bases para la actualización del consenso a Alpenglow llegará durante el ciclo de lanzamiento de Agave 4.1. Estos cambios preparan la red para la transición de Tower BFT a Alpenglow e incluyen la gestión de claves BLS en el programa de votación, Validator Admission Tickets y marcadores de Fast Leader Handover.

Clúster de pruebas comunitario

El camino restante hacia la activación de Alpenglow en mainnet depende en gran medida de pruebas exhaustivas en condiciones reales. Desde mayo, un clúster de pruebas comunitario con cerca de 100 validadores distribuidos geográficamente ejecuta la actualización en una red activa. Así se prueba la transición entre el consenso actual de Solana, basado en Tower BFT, y Alpenglow antes de activarlo en mainnet.

El objetivo es que el proceso de lanzamiento transcurra sin incidentes. Los validadores del clúster han alternado entre Tower BFT y Alpenglow para probar la ruta de migración en condiciones operativas reales, en lugar de depender únicamente de pruebas internas controladas. Las conversaciones tienen lugar en el canal `ag-community-cluster` del Discord de Solana Tech. La actividad en vivo del clúster puede seguirse mediante los paneles comunitarios de Valid Blocks, Staking Facilities y Noders.

Gestión de claves públicas BLS

SIMD-0387: gestión de claves públicas BLS en la cuenta de votación se activará durante el ciclo de lanzamiento de Agave 4.1. Esto incorpora la infraestructura del programa de votación necesaria para que los validadores registren claves públicas BLS en sus cuentas de votación antes de Alpenglow. Alpenglow utiliza firmas BLS agregadas para reducir el costo de agregar y verificar votos, pero las claves públicas BLS son distintas de las claves de autoridad de votación Ed25519 que se usan actualmente. 

Los validadores pueden agregar claves públicas BLS a sus cuentas de votación mientras siguen operando con sus claves de autoridad de votación Ed25519 actuales. Cuando Alpenglow esté activo, las cuentas de votación sin una clave pública BLS registrada no podrán participar en el nuevo proceso de votación.

Alpenglow Validator Admission Tickets (VAT)

El ciclo de lanzamiento de Agave 4.1 también incluirá la activación en mainnet de SIMD-0357, que implementa Validator Admission Tickets (VAT). Los VAT están diseñados para mantener una estructura de costos similar para los validadores a medida que Solana abandona el modelo actual de transacciones de votación de Tower BFT.

Actualmente, los validadores pagan tarifas de transacción de votación de forma continua al votar. Estas suman ~2.1 SOL por época para los validadores que votan de manera constante. Con Alpenglow, esas transacciones de votación se sustituyen por un nuevo diseño de consenso, por lo que SIMD-0357 introduce un costo de admisión que se paga una vez por época. Cada validador elegible para participar en la votación de Alpenglow paga un VAT de 1.6 SOL por época. Esto mantiene una barrera económica comparable y reduce el riesgo de una expansión inmediata y descontrolada del conjunto de validadores tras el lanzamiento de Alpenglow.

La implementación se realiza en el límite de cada época. Al entrar en una nueva época, el runtime calcula el conjunto de validadores para la siguiente época. Después, filtra las cuentas de votación que tienen una clave pública BLS registrada y suficientes lamports para cubrir el VAT y la renta. Por último, deduce el VAT de las cuentas de votación de los validadores aceptados. Esos lamports se envían directamente a la cuenta incineradora. Si califican más de 2,000 validadores, el conjunto de votación se limita según el peso del stake y se seleccionan los validadores elegibles con mayor peso.

En términos operativos, esto cambia dónde deben mantener los fondos quienes operan validadores. Actualmente, las tarifas de transacción de votación se pagan desde la cuenta de identidad del validador, que debe ser un par de claves activo para las operaciones normales. Con los VAT, el costo de admisión se deduce de la cuenta de votación.

Marcadores de Fast Leader Handover

Por último, la activación de SIMD-0337: marcadores para Fast Leader Handover de Alpenglow agregará nuevos marcadores de bloque. Estos permiten que un líder de Alpenglow declare el bloque padre al comienzo del bloque y, cuando sea necesario, lo actualice mientras transmite el bloque. Estos marcadores son compatibles con Fast Leader Handover, diseñado para reducir los retrasos de sincronización entre líderes.

Mayor adopción de XDP y el camino hacia los 100 millones de CU

XDP (eXpress Data Path) es la ruta de red de alto rendimiento que Agave utiliza para acelerar Turbine. Permite que Agave cargue un programa eBPF cerca de la tarjeta de interfaz de red, lo que hace posible que el tráfico de shreds omita gran parte de la ruta estándar de procesamiento de paquetes de Linux. La adopción de XDP es esencial para que la red alcance el objetivo histórico de bloques de 100 millones de CU. 

La adopción ya superó un umbral importante. A principios de este mes, la red experimentó el “cambio de mayoría”: ya había más líderes ejecutando XDP que sin ejecutarlo. Actualmente, más de dos tercios de la red han activado XDP. Agave 4.1 refleja esa madurez al eliminar la etiqueta experimental de la compatibilidad con XDP y sustituir las antiguas opciones `--experimental-retransmit-xdp-*` por `--xdp-interface`, `--xdp-cpu-cores` y `--xdp-zero-copy`. Está previsto que XDP se habilite de forma predeterminada en Agave 4.2.

Para quienes operan validadores y aún no han hecho el cambio, la página de actualización de Solana Foundation y la guía de configuración de Anza ofrecen una lista práctica de compatibilidad. Esta abarca la compatibilidad del kernel, el hardware de red, las capacidades del validador, las opciones de inicio y los pasos de verificación. A continuación encontrarás una guía útil de compatibilidad de controladores y NIC.

Más reimplementaciones de programas con Pinocchio

El exitoso lanzamiento de p-token demostró recientemente que las reimplementaciones específicas de los programas más utilizados de Solana pueden generar ahorros de cómputo significativos en toda la red. Como sustituto directo del programa SPL Token, p-token reduce el consumo de unidades de cómputo (CU) cerca de un 95 %, lo que supone una mejora de eficiencia de ~19 veces para las transacciones de tokens estándar. Antes, las instrucciones del programa de tokens representaban cerca del 10 % del uso de CU de todo el bloque. Al reducir el costo de esas instrucciones a aproximadamente el 5 % de su valor anterior, p-token liberó cerca del 9.5 % de la capacidad total del bloque.

La “p” de p-token significa Pinocchio, una biblioteca optimizada, eficiente y sin dependencias para escribir programas de Solana, desarrollada por Anza. Pinocchio sustituye al crate solana-program estándar, que utiliza ampliamente tipos zero-copy para gestionar datos de instrucciones y cuentas.

Anza ahora reimplementa otros programas principales con Pinocchio. El objetivo no es introducir nuevos estándares ni forzar migraciones en las aplicaciones, sino reducir drásticamente el costo de ejecutar programas existentes y de uso generalizado.

Programa p-memo

El primer ejemplo es p-memo, una reimplementación del programa SPL Memo con Pinocchio que ya está activa en mainnet. El programa Memo es pequeño, pero las mejoras de eficiencia siguen siendo sorprendentes. Sin firmantes, p-memo consume 287 CU, frente a las 2,022 CU del programa Memo actual, es decir, cerca del 14 % del costo existente. Cuando hay firmantes, la diferencia se vuelve aún más marcada: con un firmante, p-memo utiliza 513 CU frente a 13,525 CU; con dos firmantes, 628 CU frente a 25,111 CU; y con tres firmantes, 743 CU frente a 36,406 CU. Esto significa que, en casos con muchos firmantes, p-memo reduce el consumo de cómputo a solo entre el 2 % y el 4 % del costo del programa actual.

Programa p-ATA

También se está trabajando en p-ATA, una reimplementación con Pinocchio del programa Associated Token Account. El programa ATA define la asignación estándar entre una wallet, la emisión de un token y la cuenta de tokens utilizada para guardar esa emisión. Ofrece una forma determinista de derivar la cuenta de tokens asociada de un usuario y permite que cualquiera cree esa cuenta para un destinatario si aún no existe. 

El programa ATA es el quinto programa más invocado de la red. Según las estimaciones del equipo de Anza, aparece en el ~11.9 % de todas las transacciones y representa el ~13.3 % del consumo total de CU. La reimplementación podría reducir un 80.9 % el uso promedio ponderado de CU. Se esperan ahorros adicionales de las nuevas instrucciones incorporadas junto con p-ATA. Con el uso actual de la red, esto supondría un ahorro global cercano al 10 % de las CU en mainnet. En la muestra de Anza, p-ATA liberó más de 2.78 millones de CU por bloque.

Es poco probable que p-token, p-memo y p-ATA sean el final de este trabajo. El programa Token-2022 es otro de los más solicitados. En términos más generales, el esfuerzo de Anza por hacer que los programas principales sean `no_std` sienta las bases para reimplementar más programas fundamentales de Solana con menos dependencias y menores costos de cómputo.

Reducción de la sobrecarga del punto de entrada de los programas

Otro cambio relacionado, cuya activación está prevista durante el ciclo de lanzamiento de Agave 4.1, es SIMD-0449: punteros directos a cuentas en la entrada del programa, que optimiza el punto de entrada del programa. Actualmente, los programas sBPF ABIv1 deben analizar la sección de cuentas serializadas de la entrada del programa para encontrar los límites de las cuentas y construir el segmento de cuentas que se pasa al programa. SIMD-0449 cambia esto al hacer que la VM agregue un segmento de punteros directos a cuentas en la entrada del programa. Para ello, utiliza la información de límites que la VM ya conoce al preparar la invocación.

Esto es especialmente relevante para los programas que siguen el estilo de Pinocchio, porque el análisis de cuentas representa gran parte del costo del punto de entrada. Con punteros directos a cuentas, el punto de entrada puede acceder a las cuentas sin recorrer toda la sección de cuentas. Así, el cómputo del punto de entrada se vuelve prácticamente constante sin importar la cantidad de cuentas. 

En las pruebas de rendimiento actualizadas, un punto de entrada de Pinocchio con 64 cuentas pasa de 504 CU a unas 7 CU, mientras que los conjuntos de cuentas más pequeños también convergen en el mismo costo reducido de 7 CU.

Tiempos de slot reducidos a 200 ms

Una de las mejoras de rendimiento más esperadas es la reducción del tiempo objetivo de los slots de Solana de 400 ms a 200 ms. Es poco probable que se implemente durante el ciclo de lanzamiento de Agave 4.1; lo más probable es que llegue a mainnet con Agave 4.2. Sin embargo, crece el impulso para llevar esta importante mejora a mainnet lo antes posible.

SIMD-0525: reducción de los tiempos de slot propone un lanzamiento por etapas: pasar de slots de 400 ms a 350 ms, luego a 300 ms, después a 250 ms y, por último, a 200 ms. Cada etapa está controlada por un feature gate, lo que permite a los equipos de clientes y a los operadores observar la red con slots más cortos antes de pasar a la siguiente etapa. Anza lleva meses probando internamente slots de 200 ms y el equipo considera que la red está lista para reducir de forma considerable el tiempo de los slots. Las mejoras en la etapa de reproducción han hecho que el cambio sea más viable: reproducir un slot completo de 400 ms ahora tarda cerca de 40 ms.

La motivación es sencilla. Los slots más cortos reducen la latencia de confirmación y finalización para los usuarios. También acortan la ventana de cada líder. Actualmente, el periodo de liderazgo de Solana abarca cuatro slots consecutivos, lo que da al líder una ventana de 1.6 segundos con slots de 400 ms. Con slots de 200 ms, esa ventana se reduce a 800 ms. Esto mejora la estructura del mercado porque reduce el tiempo máximo durante el cual un líder malicioso puede retrasar, reordenar o incluir transacciones de forma selectiva antes de que el siguiente líder tenga la oportunidad de producir un bloque.

Los slots más cortos también ofrecen a las aplicaciones una visión más detallada del tiempo onchain. Esto es importante para sistemas que evalúan la actualidad de los slots, incluidos los consumidores de oráculos y los creadores de mercado propietarios de tipo AMM.

La propuesta está diseñada cuidadosamente para no cambiar la economía de Solana. `slots_per_year` aumenta según la proporción inversa, lo que mantiene el calendario de inflación de SOL. Con Alpenglow, los costos de Validator Admission Ticket (VAT) también se ajustan según la etapa del tiempo de slot, lo que mantiene el costo de admisión cerca de los ~0.8 SOL diarios previstos. Además, los límites de trabajo por slot se reducen de manera proporcional al menor tiempo objetivo del slot, por lo que la cantidad de trabajo que la red puede procesar por segundo se mantiene prácticamente igual. 

Varios supuestos fundamentales no cambian. Los periodos de liderazgo siguen siendo de cuatro slots, las épocas permanecen fijas en 432,000 slots y los ticks por slot siguen siendo 64. Como las épocas mantienen una cantidad fija de slots, los slots de 200 ms reducen la duración de una época de unos dos días a uno.

Un punto controvertido es el impacto en los costos de votación de los validadores si se activan slots más cortos antes de Alpenglow. Los slots más rápidos implican más votos diarios y, por lo tanto, mayores costos diarios de votación para los validadores. Los costos de las transacciones de votación son el mayor gasto individual para quienes operan validadores. Las transacciones de votación tienen un precio uniforme de 0.000005 SOL y estos costos suman ~1.086 SOL al día. Con slots de 200 ms, esos costos se duplicarían aproximadamente.

Otras actualizaciones destacadas

Varias mejoras menores pero destacadas se activarán durante el ciclo de lanzamiento de Agave 4.1. Estas abarcan desde tasas de comisión más precisas para los validadores hasta nuevas primitivas criptográficas y la eliminación de un vector de ataque de denegación de servicio en el cargador actualizable.

Mayor precisión en las tasas de comisión de los validadores

Como parte del ciclo de lanzamiento de Agave 4.1, se activará en mainnet la mejora controlada por feature gate SIMD-0291: tasa de comisión en puntos básicos. Actualmente, las tasas de comisión de los validadores solo pueden establecerse en puntos porcentuales enteros. Esto significa que un validador puede fijar una comisión del 5 % o el 6 %, pero no del 5.5 %, el 5.25 % o el 5.01 %.

Con esta actualización, los validadores obtienen un control más detallado al establecer tasas de comisión en puntos básicos, donde 100 puntos básicos equivalen al 1 %. El programa de votación agrega una nueva instrucción `UpdateCommissionBps`, que permite al retirador autorizado de una cuenta de votación actualizar con mayor precisión la comisión del validador sobre las recompensas por inflación. Esto ofrece a los validadores una configuración de comisiones más flexible y competitiva.

Este cambio es una de varias actualizaciones relacionadas con la nueva Vote Account V4. También ayuda a preparar la red para la esperada activación de SIMD-0123: distribución de ingresos de bloques, que permitirá distribuir las recompensas de bloques dentro del protocolo.

Syscall SHA-512

SIMD-0512: syscall Sha512 introduce una nueva syscall que ofrece a los programas onchain acceso directo al hashing SHA-512 mediante el runtime. Utiliza una interfaz similar a las syscalls de hash existentes, como `sol_sha256`, `sol_keccak256` y `sol_blake3`.

SHA-512 es una primitiva fundamental utilizada para verificar firmas Ed25519 y ya existe como dependencia interna en los clientes validadores Agave y Firedancer. Sin embargo, hasta ahora no estaba disponible para los programas onchain. Calcular directamente el hash de un mensaje corto onchain es costoso y consume miles de CU, frente a menos de 100 CU mediante una syscall.

Con `sol_sha512`, los programas pueden calcular hashes SHA-512 al costo de una syscall y recibir directamente el digest estándar de 64 bytes. El cambio es adicional y está controlado por un feature gate, por lo que no afecta a los programas que no utilizan la nueva syscall. Las syscalls de hash existentes tampoco cambian.

Refuerzo del cargador actualizable

El ciclo de lanzamiento de Agave 4.1 también incluirá la versión controlada por feature gate de SIMD-0431: Loader V3: tamaño mínimo de extensión de programas, que agrega un tamaño mínimo de extensión a la instrucción `ExtendProgram` de Loader V3. Tras su activación, los programas deberán ampliarse al menos 10,240 bytes (10 KiB), salvo que la cuenta de datos del programa ya esté a menos de 10 KiB del tamaño máximo de cuenta de 10 MiB.

Este cambio aborda un vector sutil de denegación de servicio en el cargador actualizable vigente. `ExtendProgram` no requiere permisos, lo que significa que cualquiera puede ampliar la cuenta de datos de un programa actualizable, incluso en un solo byte. Como cada extensión invalida la entrada del programa en la caché del slot actual, una extensión económica de un byte puede interrumpir temporalmente el acceso al programa.

En lugar de restringir `ExtendProgram` mediante permisos, el cambio mantiene el diseño sin permisos de la instrucción, pero hace que abusar de ella resulte poco atractivo en términos económicos. Con el nuevo mínimo de 10 KiB, cada extensión cuesta alrededor de 0.072 SOL en lamports exentos de renta.

Para las actualizaciones legítimas de programas, el impacto debería ser limitado. Los programas que necesiten menos de 10 KiB de espacio adicional tendrán que ampliarse hasta el mínimo completo, pero la capacidad sobrante seguirá disponible para futuras actualizaciones. La SIMD tampoco modifica las cuentas de las instrucciones, los requisitos de los firmantes, las restricciones de CPI ni los flujos de trabajo multisig existentes.

Conclusión

Agave 4.1 es una importante actualización del cliente que reúne una amplia variedad de mejoras y optimizaciones de rendimiento. De cara al futuro, Agave 4.2 se perfila como una versión aún más relevante, con transacciones más grandes de 4096 bytes, tiempos de slot reducidos a 200 ms y, posiblemente, la esperada actualización del consenso a Alpenglow.

Recursos adicionales

• Calendario de lanzamiento de Agave 4.1
• Calendario del seguimiento de feature gates
• Registro de cambios de Agave 4.1
• Pull requests de Agave 4.1