Muchas gracias a 0xIchigo y Brian Wong por revisar las versiones anteriores de este trabajo.
Introducción
La versión principal de Agave v3.0 marca otro hito para Solana, introduciendo una serie de mejoras destinadas a mejorar el rendimiento de la red, las operaciones de los validadores y la experiencia del desarrollador.
Actualizaciones Notables de Agave 3.0
Revisión de Caché: entrega un procesamiento de transacciones 30–40% más rápido
Límite de Cómputo por Cuenta Única Mayor: eleva el límite de cuenta única al 40% de las CUs de un bloque
Nueva Estructura de Vista de Transacción de Scheduler: mejora la eficiencia de programación
eXpress Data Path (XDP) para Turbine: un requisito previo para bloques de 100 millones de CU
Aumento de la profundidad de anidamiento de CPI: eleva el límite de anidamiento de CPI de 4 a 8
Relajar las restricciones de entrada: simplifica la lógica de programación y es necesario para la ejecución asincrónica
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 datos de transacción cargada: estandariza cómo se calcula el tamaño de los datos de transacción cargados
Mejoras RPC: actualizaciones en tiempo real más rápidas y confiables para dApps que usan PubSub WebSockets
Cada sección de este artículo es autosuficiente, lo que permite a los lectores centrarse en los temas más relevantes para ellos. Ya seas un operador de validador, desarrollador o miembro activo de la comunidad, esta guía de Agave v3.0 te ofrece las actualizaciones y los conocimientos clave necesarios para aprovechar al máximo las últimas mejoras.
Tendencias Relacionadas con Clientes
Antes de explorar los detalles de las nuevas características de Agave v3.0, veamos cómo los datos recientes destacan el progreso realizado por la red Solana y el cliente Agave, mostrando ciclos de lanzamiento más rápidos, una adopción más amplia de clientes y un rendimiento robusto bajo presión.
Ritmo de Lanzamiento de Agave
Anza ha acelerado notablemente su ritmo de lanzamientos este año, reduciendo la brecha entre versiones menores de Agave a menos de tres meses. La serie Agave 2.2.* se mantuvo como la versión supermayoritaria durante solo 11 semanas, con Agave 2.3 siguiendo un cronograma similar.
Red Multi-Cliente
La adopción de Firedancer en mainnet ha avanzado significativamente en los últimos meses. Actualmente, el 21.6% de la participación está ejecutando el cliente Jito-Frankendancer, una cifra que ha crecido lentamente y de manera constante a lo largo del año (ver gráfico a continuación). Se espera que la adopción se mantenga alrededor del umbral del 20% hasta que el cliente Firedancer completo esté listo para producción para el despliegue en mainnet.
Esto marca un hito significativo para la estrategia de múltiples clientes de Solana, un objetivo de larga data destinado a mejorar la seguridad, la vitalidad y la resiliencia de la red. La mayor diversidad de clientes ofrece mayor elección a los operadores de validadores, fomenta una competencia saludable entre los equipos de clientes y trae más ojos a las bases de código de los clientes. También mitiga el riesgo de que un solo error crítico desencadene una falla en toda la red.
También es notable que la participación que ejecuta el cliente Agave vanilla, es decir, Agave sin modificaciones de MEV de terceros como Jito, ha disminuido de alrededor del 6% al comienzo del año a aproximadamente 2% hoy. Mientras tanto, la adopción de Paladin-Agave ha aumentado en los últimos meses, representando ahora alrededor del 6% de la participación total.
Prueba de Estrés de la Red
El 10 de octubre, el mercado de criptomonedas experimentó el mayor evento de liquidación en su historia, desencadenando una volatilidad extrema en todas las principales cadenas de bloques. A pesar del aumento récord en la actividad de la red, la red Solana y el cliente validador Agave demostraron una notable resiliencia y estabilidad bajo presión.
Durante el pico, Solana mantuvo seis veces sus niveles de tráfico normales con líderes ingiriendo alrededor de 100,000 paquetes de transacción por segundo, mientras producía bloques completos en el límite de 60 millones de CUs.
Incluso bajo estas condiciones, Solana exhibió la dinámica de tarifas más estable de cualquier red importante al procesar un rendimiento de órdenes de magnitud superior. El verdadero TPS (transacciones no votadas) superó los 3,200 en el momento de mayor actividad.
Durante la ventana pico de aproximadamente dos horas, la tarifa de transacción media (P50) de Solana solo aumentó a $0.007, menos de un centavo. Las tarifas promedio alcanzaron brevemente $0.10, y el 1% superior de las transacciones (P99) alcanzó picos justo por encima de $1.00. Este patrón demuestra la efectividad de los mercados de tarifas locales, que confinaron tarifas altas solo a aquellas transacciones que interactuaban con cuentas calientes en disputa, mientras que los usuarios ordinarios que realizaban transferencias simples (por ejemplo, pagos de stablecoin) no se vieron afectados.
Para comparación, Ethereum mainnet y Arbitrum vieron tarifas medianas que brevemente aumentaron a más de $100 por transacción durante el mismo período. Base, operado por Coinbase, también experimentó aumentos de tarifas con tarifas medianas alcanzando picos de más de $3. Estas redes carecen de mercados de tarifas locales, aplicando ajustes globales de tarifas que aumentan uniformemente los costos para todos los usuarios durante el estrés de la red.
Crecimiento del Estado
Solana recientemente cruzó un hito importante en el crecimiento del estado en la cadena, superando 1 billón de cuentas totales. Casi el 67% de estas cuentas son propiedad del Programa de Tokens, de las cuales el 89.45% son cuentas de tokens asociadas y el 10.55% 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 el número de cuentas, también lo hace la demanda de almacenamiento, tamaño de instantáneas e indexación de cuentas, todo lo cual puede impactar el rendimiento y los requisitos de hardware. Soluciones como ZK Compression ofrecen un camino prometedor a largo plazo para reducir la hinchazón del estado.
Actualizaciones del ciclo de lanzamiento de Agave 3.0
Reforma de caché
Agave 3.0 reduce significativamente las operaciones redundantes en tiempo de ejecución. Una revisión completa de la caché del programa elimina cientos de búsquedas de cuentas superfluas por lote de transacciones, resultando en un procesamiento de transacciones aproximadamente 30–40% más rápido en benchmarks internos.
Aumentar el límite de cuentas al 40% del CU del bloque
Como parte del ciclo de lanzamiento de Agave 3.0, Solana activará SIMD-0306: Aumentar los límites de CU de cuenta. Esto aumenta el límite de CU por cuenta de un constante fija de 12M al 40% del límite de CU del bloque. Actualmente, cada cuenta puede consumir hasta 12 millones de CUs por bloque. Como se muestra en el gráfico a continuación de Anza, las cuentas más disputadas a menudo alcanzan este techo.
Con este cambio, el límite por cuenta aumentará inicialmente de 12 millones a 24 millones de CUs, y eventualmente a 40 millones de CUs una vez que SIMD-0286 (bloques de 100M CU) se active. Combinado con actualizaciones como la introducción del programa P-token, esta mejora aumentará significativamente el rendimiento para cuentas activas que se acceden con frecuencia dentro de cada bloque.
Otras restricciones permanecerán sin cambios, incluyendo:
Máximas Unidades de Voto: el límite en el total de CUs de transacciones de voto por bloque, en 36 millones de CUs
Máxima Delta del Tamaño de Datos de Cuentas del Bloque: el límite en los cambios totales de datos de cuenta por bloque, en 100 megabytes.
Si bien elevar el límite de CU por cuenta mejora el rendimiento para el estado caliente, también puede aumentar el tiempo de ejecución serializado en el peor de los casos, potencialmente prolongando la verificación de bloques o la duración de slots en escenarios de alta carga.
Finalmente, vale la pena mencionar la reciente propuesta SIMD-0370: Eliminar el límite de bloques de unidades de cómputo, que explora la eliminación total de los límites de bloques basados en CU, una dirección que probablemente se revisite después de la actualización de Alpenglow.
eXpress Data Path (XDP) para Turbine
eXpress Data Path (XDP) es una tecnología del núcleo de Linux diseñada para redes de alto rendimiento. Permite a las aplicaciones eludir gran parte del camino estándar de procesamiento de paquetes del núcleo, reduciendo tanto las copias de datos intermedias como los cambios de contexto entre el espacio de usuario y el núcleo. Al manejar paquetes directamente con la tarjeta de interfaz de red (NIC) en el espacio de usuario, XDP reduce drásticamente el costo por paquete.
El soporte para XDP en Turbine se introdujo por primera vez en Agave v2.3.8 y se habilitará por defecto a partir de Agave 3.1. Turbine es el principal cuello de botella de escalabilidad a medida que los límites de bloques aumentan a 100M CUs. Los líderes retransmiten sus fragmentos a 200 pares, generando una carga pesada en la red. Los validadores grandes con más slots de líder pueden acercarse a 150,000 paquetes salientes por segundo en las condiciones actuales. XDP aborda directamente este cuello de botella, haciendo que el despacho de paquetes sea hasta 100 veces más rápido, permitiendo a los validadores propagar bloques más grandes de manera mucho más eficiente.
Los lectores interesados en una mirada más profunda a la implementación de XDP en Agave pueden consultar la guía de configuración del validador y nuestra anterior entrevista con el ingeniero de Anza Alessandro Decina, quien lideró la integración de XDP en el cliente Agave.
Especificación del tamaño de datos de transacción cargada
Como parte de los esfuerzos en curso para simplificar y estandarizar el modelo de ejecución de Solana, SIMD-0186: Especificación del tamaño de datos de transacción cargada, está programado para activarse en mainnet durante el ciclo de lanzamiento de Agave 3.0.
Esto introduce un método seguro para el consenso para calcular la cantidad total de datos de cuenta cargados por cada transacción. El objetivo es asegurar que todos los clientes validador calculen tamaños de datos de transacción idénticos, eliminando inconsistencias sutiles que de otro modo podrían causar que el consenso diverja.
Actualmente, la lógica de tamaño de datos de transacción de Solana es excesivamente compleja. La implementación existente es idiosincrática en cómo maneja los programas LoaderV3 y BPF Upgradeable Loader, ambos de los cuales a menudo subestiman el tamaño real de los datos del programa cargado. Estas discrepancias dificultaron que los equipos de clientes independientes implementaran lógica compatible.
Bajo SIMD-0186, las reglas de tamaño son ahora explícitas y fáciles de razonar:
Cada cuenta cargada se cuenta exactamente una vez
Los programas que utilizan el Cargador BPF Actualizable 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 la ejecución de la transacción, con 64 bytes adicionales para metadatos
Las Tablas de Búsqueda de Direcciones (ALTs) añaden 8,248 bytes cada una
Esta especificación estandariza el tamaño de las transacciones en todos los clientes y hace que el comportamiento de las transacciones sea más predecible para los desarrolladores.
El límite del tamaño de datos cargados cumple un papel similar al límite de CU por transacción, proporcionando una contabilidad de recursos predecible para los nodos validador. Por defecto, cada transacción puede cargar hasta 64MB de datos de cuenta, consumiendo ocho unidades de cómputo (CUs) por cada 32KB cargados, equivalente a un costo base de 16,000 CUs, incluso si se cargan menos datos. Los desarrolladores pueden reducir este límite a través de la instrucción setLoadedAccountsDataSizeLimit para disminuir el costo de cómputo y mejorar la eficiencia de programación.
Dado que el nuevo método de tamaño puede producir valores variables según la estructura de la transacción, los desarrolladores pueden necesitar ajustar el límite de tamaño de datos de cuenta cargada especificado en sus instrucciones de presupuesto de cómputo.
Estructura de TransactionView del Programador
Con Agave 3.0, el programador introduce una nueva estructura de datos ligera llamada TransactionView, diseñada para simplificar cómo se analizan y procesan las transacciones. A diferencia de los tipos de transacciones más antiguos del SDK, que requerían deserialización y múltiples asignaciones de memoria, TransactionView proporciona una vista directa de una transacción serializada. Analiza y almacena en caché los metadatos sobre el diseño de la transacción sin realmente deserializarlo.
Tiempos de Inicio Más Rápidos
El rendimiento de inicio del cliente sigue mejorando con el lanzamiento de Agave v3.0, marcando una notable mejora en la calidad de vida para los operadores de validadores y RPC. Ya sea reiniciando después de un fallo, una actualización o un mantenimiento programado, los nodos ahora pueden volver a estar en línea significativamente más rápido.
A partir de un archivo de instantánea, los tiempos de inicio se han reducido a menos de tres minutos y medio, menos de la mitad de la duración requerida bajo Agave v2.2 (ver gráfico a continuación). Esta mejora representa una ganancia de rendimiento crítica, ya que un inicio más rápido mejora directamente la resiliencia de la red y el tiempo de actividad del validador al reducir el tiempo que tardan los nodos en volver a unirse al consenso.
Mirando hacia adelante, Agave v3.1 simplificará aún más este proceso eliminando la verificación de cuentas en segundo plano, permitiendo a los validadores comenzar a votar inmediatamente después de que comience la repetición.
Aumentar el límite de anidamiento de CPI
SIMD-0268: Aumentar el límite de anidamiento de CPI aumenta la profundidad máxima de las llamadas de Invocación entre Programas (CPI) de 4 a 8. Esto efectivamente duplica el número 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 característica fundamental del tiempo de ejecución de Solana que permite a los programas construir sobre la lógica de otros.
Protocolos complejos en la cadena como swaps perpetuos, billeteras inteligentes y sistemas de margen cruzado a menudo dependen de múltiples capas de interacciones de programas para gestionar posiciones, liquidaciones y riesgos. El límite CPI anterior de 4 niveles restringió estos diseños, en algunos casos forzando a los desarrolladores a dividir la lógica en múltiples transacciones.
Las aplicaciones existentes continuarán funcionando como antes (a menos que dependan del antiguo límite en su lógica para fallar transacciones). En general, este cambio solicitado con frecuencia amplía el espacio de diseño para los desarrolladores y fortalece la compositividad de Solana.
Relajar las restricciones de entrada
SIMD-0083: Relajar las restricciones de entrada, programado para activarse durante Agave 3.0, elimina la regla que establece que las transacciones dentro de una entrada de bloque no deben entrar en conflicto entre sí. Anteriormente, cualquier entrada que contuviera transacciones en conflicto (es decir, aquellas que escriben en la misma cuenta o donde una lee mientras otra escribe) invalidaría todo el bloque.
Con esta actualización, tales conflictos ahora están permitidos. Cuando ocurren, las transacciones se ejecutan secuencialmente en el orden en que aparecen. Este cambio simplifica las reglas de empaquetado de bloques, dando a los líderes mayor flexibilidad en el orden de las transacciones y la construcción de bloques. También es un cambio necesario para que Solana implemente la ejecución asincrónica.
Mejoras RPC
Agave v3.0 introduce mejoras de respuesta al servidor de suscripción, que ahora prioriza los mensajes entrantes, como solicitudes de suscripción y PINGs, sobre las notificaciones salientes. Este cambio proporciona actualizaciones en tiempo real más rápidas y confiables para dApps que usan PubSub WebSockets.
Además, se han agregado propiedades de slot a los datos de error de recompensas de época, mejorando la depuración y la observabilidad para los desarrolladores.
Otros cambios
A partir de Agave v3.0.0, Anza ha dejado de publicar binarios preconstruidos de agave-validator. Los operadores de validadores deben ahora compilar los binarios desde la fuente siguiendo las instrucciones de construcción proporcionadas.
Con Agave v3.0, el intervalo de instantáneas predeterminado se ha extendido a cada 100,000 slots, desde 50,000 en v2.3 y 25,000 en v2.2. Aumentar el intervalo mejora significativamente el rendimiento del disco, reduciendo picos en IOPS (operaciones de entrada/salida por segundo) durante la creación de instantáneas.
Numerosos argumentos y banderas de CLI antiguos obsoletos han sido eliminados (lista completa aquí).
Actualmente, una instrucción de nonce avanzado en una transacción puede especificar cualquier cuenta en la transacción como la cuenta a avanzar. Tras la activación de la puerta de funciones para SIMD-0242: Solo Cuenta de Nonce Estática, esto restringirá la instrucción de nonce avanzado a solo poder avanzar una cuenta incluida estáticamente.
Conclusión
Agave v3.0 es una actualización sustancial del cliente, introduciendo un procesamiento de transacciones más rápido, límites de cómputo más altos, una mayor eficiencia del programador y una variedad de optimizaciones para validadores y RPC. Juntos, estas actualizaciones fortalecen tanto el rendimiento de la red como la experiencia del desarrollador.
Datos recientes refuerzan aún más este progreso: ritmos de lanzamiento más rápidos, creciente diversidad de clientes y excepcional estabilidad de la red bajo demanda máxima destacan la maduración de Solana. Con Agave 3.0 ahora impulsando la red, Solana sigue demostrando su capacidad para escalar.