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

Introducción

La versión principal Agave v3.0 marca otro hito para Solana. Incluye varias mejoras diseñadas para optimizar el rendimiento de la red, las operaciones de los validadores y la experiencia del desarrollador.

Actualizaciones destacadas de Agave 3.0 

• Renovación de la caché: ofrece un procesamiento de transacciones entre un 30 y un 40 % más rápido
• Mayor límite de cómputo por cuenta: eleva el límite por cuenta al 40 % de las CU de un bloque
• Nueva estructura TransactionView del planificador: mejora la eficiencia de la planificación
• eXpress Data Path (XDP) para Turbine: un requisito previo para los bloques de 100 millones de CU
• Mayor profundidad de anidamiento de CPI: eleva el límite de anidamiento de CPI de 4 a 8
• Relajación de las restricciones de entrada: simplifica la lógica de planificación y es necesaria para la ejecución asíncrona
• Tiempos de inicio más rápidos: los nodos ahora vuelven a estar en línea más rápido
• Especificación del tamaño de los datos de transacciones cargados: estandariza cómo se calculan los datos de transacciones cargados
• Mejoras de RPC: actualizaciones en tiempo real más rápidas y confiables para las dApps que usan PubSub WebSockets

Cada sección de este artículo es independiente, por lo que puedes centrarte en los temas más relevantes para ti. Ya seas operador de validadores, desarrollador o miembro activo de la comunidad, esta guía de Agave v3.0 ofrece las actualizaciones y los datos clave que necesitas para aprovechar al máximo las mejoras más recientes.

Tendencias relacionadas con los clientes

Antes de explorar los detalles de las nuevas funciones de Agave v3.0, veamos cómo los datos recientes reflejan los avances de la red Solana y del cliente Agave: ciclos de lanzamiento más rápidos, mayor adopción de clientes y un rendimiento sólido bajo presión.

Frecuencia de lanzamientos de Agave

Anza ha acelerado notablemente su frecuencia de lanzamientos este año y ha reducido a menos de tres meses el intervalo entre versiones menores de Agave. La serie Agave 2.2.* mantuvo la supermayoría durante solo 11 semanas, y Agave 2.3 sigue un calendario similar.

Red con múltiples clientes

La adopción de Firedancer en mainnet ha avanzado de forma considerable durante los últimos meses. Actualmente, el 21,6 % del stake ejecuta el cliente Jito-Frankendancer, una cifra que ha crecido de forma lenta y constante durante el año (consulta el gráfico siguiente). Se espera que la adopción se mantenga cerca del umbral del 20 % hasta que el cliente Firedancer completo esté listo para implementarse en producción en mainnet.

Esto representa un hito importante para la estrategia de múltiples clientes de Solana, un objetivo de larga data que busca mejorar la seguridad, la disponibilidad y la resiliencia de la red. Una mayor diversidad de clientes ofrece más opciones a los operadores de validadores, fomenta una competencia sana entre los equipos de clientes y permite que más personas revisen sus bases de código. También reduce el riesgo de que un único error crítico provoque una interrupción en toda la red.

También cabe destacar que el stake que ejecuta el cliente Agave estándar, es decir, Agave sin modificaciones de MEV de terceros como Jito, disminuyó de alrededor del 6 % a principios de año a cerca del 2 % en la actualidad. Mientras tanto, la adopción de Paladin-Agave aumentó durante los últimos meses y ahora representa cerca del 6 % del stake total.

Prueba de estrés de la red

El 10 de octubre, el mercado de criptomonedas vivió el mayor evento de liquidación de su historia, lo que provocó una volatilidad extrema en todas las principales blockchains. A pesar del aumento récord de la actividad, la red Solana y el cliente validador Agave demostraron una resiliencia y estabilidad notables bajo presión.

Durante el pico, Solana sostuvo seis veces su nivel normal de tráfico, con líderes recibiendo alrededor de 100 000 paquetes de transacciones por segundo, mientras producía bloques completos con el límite de 60 millones de CU.

Incluso en estas condiciones, Solana mostró la dinámica de comisiones más estable entre las principales redes, mientras procesaba un orden de magnitud más de rendimiento. Los TPS reales (transacciones sin votos) superaron los 3200 en el punto máximo de actividad.

Durante la ventana máxima de aproximadamente dos horas, la comisión mediana (P50) por transacción en Solana solo aumentó a $0.007, menos de un centavo. Las comisiones promedio alcanzaron brevemente los $0.10 y el 1 % superior de las transacciones (P99) llegó a un máximo ligeramente superior a $1.00. Este patrón demuestra la eficacia de los mercados locales de comisiones, que limitaron las comisiones altas a las transacciones que interactuaban con cuentas activas disputadas. Los usuarios comunes que realizaban transferencias simples, como pagos con stablecoins, no se vieron afectados.

En comparación, las comisiones medianas de Ethereum mainnet y Arbitrum aumentaron brevemente por encima de $100 por transacción durante el mismo periodo. Base, la L2 operada por Coinbase, también experimentó aumentos y sus comisiones medianas alcanzaron un máximo superior a $3. Estas redes no tienen mercados locales de comisiones y aplican ajustes globales que elevan los costos de manera uniforme para todos los usuarios cuando la red está bajo presión.

Crecimiento del estado

Solana superó recientemente un hito importante en el crecimiento del estado onchain al rebasar los mil millones de cuentas totales. Casi el 67 % de estas cuentas pertenece al Token Program; de ellas, el 89,45 % son cuentas de tokens asociadas y el 10,55 % son cuentas de acuñación de tokens.

Esta expansión constante del estado tiene implicaciones a largo plazo para los clientes de Solana y los proveedores de infraestructura. A medida que aumenta la cantidad de cuentas, también crece la demanda de almacenamiento, el tamaño de las instantáneas y la indexación de cuentas. Todo esto puede afectar el rendimiento y los requisitos de hardware. Soluciones como ZK Compression ofrecen una vía prometedora a largo plazo para reducir la expansión innecesaria del estado.

Actualizaciones del ciclo de lanzamiento de Agave 3.0

Renovación de la caché

Agave 3.0 reduce significativamente las operaciones redundantes del entorno de ejecución. Una renovación completa de la caché de programas elimina cientos de búsquedas innecesarias de cuentas por lote de transacciones. Como resultado, el procesamiento de transacciones es aproximadamente entre un 30 y un 40 % más rápido en las pruebas de rendimiento internas.

Aumento del límite por cuenta al 40 % de las CU del bloque

Como parte del ciclo de lanzamiento de Agave 3.0, Solana activará SIMD-0306: Aumento de los límites de CU por cuenta. Esto aumenta el límite de CU por cuenta desde una constante fija de 12 millones hasta el 40 % del límite de CU del bloque. Actualmente, cada cuenta puede consumir hasta 12 millones de CU por bloque. Como muestra el siguiente gráfico de Anza, las cuentas con mayor contención suelen alcanzar este límite.

Con este cambio, el límite por cuenta aumentará inicialmente de 12 a 24 millones de CU y, finalmente, a 40 millones de CU cuando se active SIMD-0286 (bloques de 100 millones de CU). Junto con actualizaciones como la introducción del programa P-token, esta mejora aumentará de forma significativa el rendimiento de las cuentas activas a las que se accede con frecuencia dentro de cada bloque.

Otras restricciones no cambiarán, entre ellas:

• Máximo de unidades de voto: el límite total de CU de transacciones de voto por bloque, fijado en 36 millones de CU
• Variación máxima del tamaño de datos de las cuentas del bloque: el límite total de cambios en los datos de las cuentas por bloque, fijado en 100 megabytes.

Aunque elevar el límite de CU por cuenta mejora el rendimiento del estado activo, también puede aumentar el tiempo de ejecución serializada en el peor de los casos. Esto podría prolongar la verificación de bloques o la duración de los slots en situaciones de alta carga.

Por último, cabe mencionar la propuesta reciente SIMD-0370: Eliminación del límite de unidades de cómputo por bloque, que explora la eliminación total de los límites de bloque basados en CU. Es probable que esta opción vuelva a evaluarse después de la actualización Alpenglow.

eXpress Data Path (XDP) para Turbine

eXpress Data Path (XDP) es una tecnología del kernel de Linux diseñada para redes de alto rendimiento. Permite que las aplicaciones eviten gran parte de la ruta estándar de procesamiento de paquetes del kernel, lo que reduce tanto las copias intermedias de datos como los cambios de contexto entre el espacio de usuario y el kernel. Al gestionar los paquetes directamente con la tarjeta de interfaz de red (NIC) en el espacio de usuario, XDP reduce drásticamente la sobrecarga por paquete.

La compatibilidad con XDP en Turbine se introdujo por primera vez en Agave v2.3.8 y estará activada de forma predeterminada a partir de Agave 3.1. Turbine es el principal cuello de botella para la escalabilidad a medida que los límites de bloque aumentan a 100 millones de CU. Los líderes retransmiten sus shreds a 200 pares, lo que genera una gran carga de red. En las condiciones actuales, los validadores grandes con más slots de líder pueden acercarse a 150 000 paquetes salientes por segundo. XDP aborda directamente este cuello de botella y acelera hasta 100 veces el envío de paquetes. Así, permite que los validadores propaguen bloques más grandes con mucha mayor eficiencia. 

Si quieres conocer con más detalle la implementación de XDP en Agave, consulta la guía de configuración del validador y nuestra entrevista anterior con Alessandro Decina, ingeniero de Anza, quien dirigió la integración de XDP en el cliente Agave.

Especificación del tamaño de los datos de transacciones cargados

Como parte de los esfuerzos continuos para simplificar y estandarizar el modelo de ejecución de Solana, SIMD-0186: Especificación del tamaño de los datos de transacciones cargados se activará en mainnet durante el ciclo de lanzamiento de Agave 3.0.

Esto introduce un método seguro para el consenso que calcula la cantidad total de datos de cuentas cargados por cada transacción. El objetivo es garantizar que todos los clientes validadores calculen tamaños idénticos para los datos de las transacciones y eliminar inconsistencias sutiles que podrían provocar una divergencia del consenso.

Actualmente, la lógica de Solana para calcular el tamaño de los datos de las transacciones es demasiado compleja. La implementación existente gestiona de forma particular los programas LoaderV3 y BPF Upgradeable Loader, que suelen contabilizar menos datos de programa cargados que los reales. Estas discrepancias dificultaban que los equipos de clientes independientes implementaran una lógica compatible.

Con SIMD-0186, las reglas de cálculo del tamaño ahora son explícitas y fáciles de comprender:

• Cada cuenta cargada se cuenta exactamente una vez
• Los programas que usan BPF Upgradeable Loader incluyen sus datos de programa asociados
• El tamaño de cada cuenta cargada se define como la longitud en bytes de sus datos antes de ejecutar la transacción, más 64 bytes de metadatos
• Cada Address Lookup Table (ALT) agrega una cantidad fija de 8248 bytes

Esta especificación estandariza el tamaño de las transacciones en todos los clientes y hace que su comportamiento sea más predecible para los desarrolladores.

El límite del tamaño de los datos cargados cumple una función similar al límite de CU por transacción y permite contabilizar de forma predecible los recursos de los nodos validadores. De forma predeterminada, cada transacción puede cargar hasta 64 MB de datos de cuentas y consume ocho unidades de cómputo (CU) por cada 32 KB cargados. Esto equivale a un costo base de 16 000 CU, aunque se carguen menos datos. Los desarrolladores pueden reducir este límite mediante la instrucción setLoadedAccountsDataSizeLimit para disminuir el costo de cómputo y mejorar la eficiencia de la planificación.

Como el nuevo método de cálculo puede producir valores distintos según la estructura de la transacción, es posible que los desarrolladores deban ajustar el límite del tamaño de los datos de las cuentas cargadas que especifican en sus instrucciones de presupuesto de cómputo.

Estructura TransactionView del planificador

Con Agave 3.0, el planificador introduce una nueva estructura de datos ligera llamada TransactionView, diseñada para agilizar el análisis y el procesamiento de las transacciones. A diferencia de los tipos de transacción anteriores del SDK, que requerían deserialización y múltiples asignaciones de memoria, TransactionView ofrece una vista directa de una transacción serializada. Analiza y almacena en caché los metadatos sobre la estructura de la transacción sin deserializarla.

Tiempos de inicio más rápidos

El rendimiento de inicio del cliente sigue mejorando con Agave v3.0, lo que supone una importante mejora práctica para los operadores de validadores y RPC. Ya sea tras un fallo, una actualización o una tarea de mantenimiento programada, los nodos ahora pueden volver a estar en línea mucho más rápido.

Al iniciar desde un archivo de instantánea, el tiempo de arranque se redujo a menos de tres minutos y medio, menos de la mitad del tiempo necesario con Agave v2.2 (consulta el gráfico siguiente). Esta mejora representa un avance crítico de rendimiento, ya que un inicio más rápido aumenta directamente la resiliencia de la red y el tiempo de actividad de los validadores al reducir el tiempo que tardan los nodos en reincorporarse al consenso.

De cara al futuro, Agave v3.1 agilizará aún más este proceso al eliminar la verificación de cuentas en segundo plano. Esto permitirá que los validadores comiencen a votar inmediatamente después de que se inicie la reproducción.

Aumento del límite de anidamiento de CPI

SIMD-0268: Aumento del límite de anidamiento de CPI aumenta de 4 a 8 la profundidad máxima de las llamadas Cross-Program Invocation (CPI). Esto duplica efectivamente la cantidad de veces que un programa de Solana puede invocar otros programas dentro de una sola transacción.

CPI es el mecanismo mediante el cual un programa de Solana llama a otro. Es una función fundamental del entorno de ejecución de Solana que permite que los programas se basen en la lógica de otros.

Los protocolos onchain complejos, como los swaps perpetuos, las billeteras inteligentes y los sistemas de margen cruzado, suelen depender de varias capas de interacción entre programas para gestionar posiciones, liquidaciones y riesgos. El límite anterior de cuatro niveles de CPI restringía estos diseños y, en algunos casos, obligaba a los desarrolladores a dividir la lógica entre varias transacciones.

Las aplicaciones existentes seguirán funcionando como antes, salvo que su lógica dependa del límite anterior para provocar el fallo de las transacciones. En general, este cambio solicitado con frecuencia amplía las posibilidades de diseño para los desarrolladores y refuerza la composabilidad de Solana.

Relajación de las restricciones de entrada

SIMD-0083: Relajación de las restricciones de entrada, cuya activación está prevista durante Agave 3.0, elimina la regla que impedía que las transacciones dentro de una entrada de bloque tuvieran conflictos entre sí. Antes, cualquier entrada que incluyera transacciones en conflicto, es decir, que escribieran en la misma cuenta o que una leyera mientras otra escribía, invalidaba todo el bloque.

Con esta actualización, ahora se permiten estos conflictos. Cuando ocurren, las transacciones simplemente se ejecutan de forma secuencial en el orden en que aparecen. Este cambio simplifica las reglas de empaquetado de bloques y ofrece a los líderes más flexibilidad para ordenar las transacciones y construir los bloques. También es un cambio necesario para que Solana pueda implementar la ejecución asíncrona.

Mejoras de RPC

Agave v3.0 mejora la capacidad de respuesta del servidor de suscripciones, que ahora prioriza los mensajes entrantes, como las solicitudes de suscripción y los PING, sobre las notificaciones salientes. Este cambio ofrece actualizaciones en tiempo real más rápidas y confiables para las dApps que usan PubSub WebSockets.

Además, se agregaron propiedades de slot a los datos de error de las recompensas de época, lo que mejora la depuración y la observabilidad para los desarrolladores.

Otros cambios

• A partir de Agave v3.0.0, Anza dejó de publicar binarios precompilados de agave-validator. Ahora, los operadores de validadores deben compilar los binarios desde el código fuente siguiendo las instrucciones de compilación proporcionadas.
• Con Agave v3.0, el intervalo predeterminado entre instantáneas se amplió a 100 000 slots, frente a los 50 000 de v2.3 y los 25 000 de v2.2. Aumentar el intervalo mejora considerablemente el rendimiento del disco y reduce los picos de IOPS (operaciones de entrada/salida por segundo) durante la creación de instantáneas.
• Se eliminaron numerosos argumentos y opciones obsoletos del CLI (lista completa aquí).
• Actualmente, una instrucción advance nonce de una transacción puede especificar cualquier cuenta de esa transacción como la cuenta que se debe avanzar. Tras activar la función de SIMD-0242: Solo cuentas nonce estáticas, la instrucción advance nonce solo podrá avanzar una cuenta incluida de forma estática.

Conclusión

Agave v3.0 es una actualización importante del cliente que ofrece un procesamiento de transacciones más rápido, límites de cómputo más altos, mayor eficiencia del planificador y varias optimizaciones para validadores y RPC. En conjunto, estas actualizaciones refuerzan tanto el rendimiento de la red como la experiencia del desarrollador.

Los datos recientes confirman este avance: los ciclos de lanzamiento más rápidos, la creciente diversidad de clientes y la excepcional estabilidad de la red durante los picos de demanda demuestran la madurez de Solana. Ahora que Agave 3.0 impulsa la red, Solana continúa demostrando su capacidad para escalar.

Recursos adicionales

• Calendario de lanzamiento de Agave 3.0
• Calendario de seguimiento de activación de funciones
• Registro de cambios de Agave 3.0
• Solicitudes de incorporación de cambios de Agave 3.0