Actualización de Agave v2.3: todo lo que necesitas saber

Introducción

La versión v2.3 del cliente validador Agave representa otro avance importante para Solana. Al igual que las actualizaciones anteriores, esta nueva versión incorpora mejoras esenciales diseñadas para optimizar tanto el rendimiento de la red como la experiencia de los desarrolladores.

Actualizaciones destacadas de Agave 2.3 

• Nuevo cliente TPU tpu-client-next
• Optimizaciones de AccountsDB que reducen el uso de E/S de disco
• El calendario de líderes ahora usa las cuentas de voto como clave
• Verificación de eventos sancionables
• El planificador voraz está activado de forma predeterminada
• Mejoras en las instantáneas
• Mejoras en gossip
• Transiciones de época más rápidas

Cada sección de este artículo es independiente, por lo que puedes ir directamente a los temas que más te interesen. Ya seas operador de validadores, desarrollador o usuario activo, esta guía completa de Agave 2.3 te dará la información clave que necesitas para aprovechar al máximo las mejoras más recientes.

Anza está acelerando el ritmo de lanzamientos de Agave. Menos de tres meses después de la versión 2.2, la versión 2.3 ya está activa y actualmente se ejecuta sobre el 13 % del stake total. Se espera que la adopción crezca rápidamente durante las próximas semanas. Mientras tanto, las activaciones de feature gates en mainnet se pausaron temporalmente durante el despliegue y se reanudarán pronto como parte de la secuencia de activación planificada.

Nuevo cliente TPU

Agave 2.3 incorpora una nueva implementación del cliente de la Unidad de Procesamiento de Transacciones (TPU), que reemplaza a ConnectionCache. Este cliente TPU se encarga de enviar transacciones serializadas a los validadores a través de la red mediante el protocolo QUIC. El nuevo diseño, conocido como tpu-client-next, es una reimplementación completa cuyo objetivo es mejorar considerablemente el rendimiento, reducir el uso de recursos y simplificar la arquitectura general.

El cliente TPU se usa en dos escenarios principales: en ForwardingStage, donde los validadores reenvían transacciones al próximo líder, y en SendTransactionService, que los RPC usan para transmitir transacciones al líder.

La implementación anterior, ConnectionCache, se creó para admitir los protocolos UDP y QUIC, lo que la hacía innecesariamente compleja. ConnectionCache dependía de una cola asíncrona interna para almacenar las transacciones, en lugar de un canal explícito, e incluía una lógica de precalentamiento de caché que enviaba paquetes vacíos. También tenía problemas persistentes relacionados con la administración de endpoints de Quinn (es decir, una implementación de QUIC en Rust).

El nuevo tpu-client-next resuelve estos problemas con un diseño asíncrono y simplificado. Internamente, sigue un modelo basado en agentes en el que tareas de trabajo individuales administran cada conexión QUIC. Estos trabajadores se comunican con un ConnectionWorkersScheduler centralizado mediante canales asíncronos. 

Cuando el planificador recibe un lote de transacciones, lo difunde al conjunto adecuado de trabajadores según la estrategia configurada. La arquitectura elimina por completo el uso de múltiples streams, lo que reduce la fragmentación del tráfico. Además, las conexiones se establecen previamente, lo que elimina la latencia asociada con la apertura de nuevos streams al momento del envío.

tpu-client-next muestra mejoras claras de rendimiento. 

• En experimentos con RPC de testnet, tanto el cliente anterior como el nuevo alcanzaron un TPS promedio similar bajo carga. Sin embargo, tpu-client-next mostró una variación notablemente menor. 
• En casos de uso de validadores, ForwardingStage logró un aumento del 10 % en el volumen de transacciones reenviadas, junto con patrones de tráfico más estables y una reducción del 30 % en el uso de CPU.
• La herramienta de pruebas de estrés de código cerrado de Anza, transaction-bench, se creó con el cliente más reciente. Genera el doble de transacciones por segundo que la herramienta anterior de pruebas de rendimiento, bench-tps.

tpu-client-next ofrece compatibilidad total con versiones anteriores y ahora es la implementación predeterminada para los nodos de Agave. Si surgen problemas, los operadores pueden volver al comportamiento anterior iniciando su nodo con la opción --use-connection-cache para restaurar la implementación anterior.

En resumen, tpu-client-next ofrece:

• Una arquitectura compatible con operaciones asíncronas y basada en agentes
• Tráfico uniforme con menor variación
• Menor uso de CPU y memoria
• Políticas configurables de planificación y gestión de colas
• Integración simplificada y una superficie de API más limpia

Calendario de líderes basado en cuentas de voto

Como parte del ciclo de lanzamiento de Agave 2.3, Solana activará SIMD-0180: Usar la dirección de la cuenta de voto como clave del calendario de líderes. Este cambio modifica la forma en que la red determina qué validadores tienen programado producir bloques: en lugar de usar las direcciones de identidad de los validadores, utiliza las direcciones de sus cuentas de voto como clave principal del calendario de líderes.

Esta migración resuelve una ambigüedad histórica del protocolo de Solana: la imposibilidad de asociar de forma confiable un validador que produce bloques con un stake específico. En el diseño actual, el calendario de líderes usa como clave las direcciones de identidad de los validadores. Sin embargo, varias cuentas de voto pueden delegar a la misma identidad de validador, lo que dificulta vincular la producción del bloque de un slot específico con un conjunto concreto de stake delegado.

Al usar las direcciones de las cuentas de voto como clave del calendario de líderes, este cambio establece un vínculo claro y directo entre el stake delegado y la función de liderazgo del validador. Esta modificación, que parece menor, habilita varias capacidades importantes.

Primero, proporciona la base necesaria para distribuir las recompensas por bloque, como se especifica en SIMD-0123, que superó una votación formal de gobernanza en marzo. Esto permite que los validadores establezcan una tasa de comisión sobre las tarifas de los bloques y distribuyan los ingresos restantes de forma proporcional entre los delegadores. Este sistema refleja el modelo de reparto de recompensas que ya se usa para las recompensas inflacionarias de staking, lo que alinea mejor los incentivos económicos entre los validadores y quienes les delegan stake.

Segundo, usar las direcciones de las cuentas de voto como clave del calendario de líderes es esencial para habilitar las sanciones programáticas, que penalizan a los validadores que infringen las reglas de la red al enviar bloques duplicados o emitir votos en múltiples bifurcaciones. Esto nos lleva directamente a la siguiente actualización.

Verificación de eventos sancionables

El slashing es un mecanismo que penaliza a los validadores maliciosos mediante la verificación de conductas indebidas on-chain y la quema de una parte de su stake delegado. Sirve como un importante factor disuasorio contra comportamientos que amenazan la seguridad o la estabilidad de la red.

Existen dos modelos principales de slashing:

Slashing social (sistema actual de Solana)

Actualmente, Solana depende de un enfoque de consenso manual impulsado por la comunidad, conocido como slashing social. Según este modelo, si un validador actúa de forma maliciosa —por ejemplo, al poner en riesgo la disponibilidad o la seguridad de la red—, los participantes honestos pueden coordinarse off-chain para iniciar una bifurcación dura, reiniciar la red y aplicar slashing al stake del infractor. Aunque este método permite evaluar cada caso con flexibilidad, implica una sobrecarga de coordinación considerable y es reactivo por naturaleza.

Slashing programático (slashing dentro del protocolo)

En cambio, el slashing programático se aplica por completo on-chain. Si un validador infringe las reglas del protocolo, se puede enviar una prueba criptográfica de la infracción a un programa específico, que activa automáticamente el slashing. Este modelo reduce la dependencia de la coordinación humana y permite sancionar infracciones menores sin interrumpir las operaciones de la red. Así, sienta las bases para una rendición de cuentas escalable y descentralizada.

El slashing consta de dos pasos clave:

• Detección y atribución de faltas: identificar la conducta indebida y al validador responsable.
• Aplicación de sanciones: castigar económicamente al infractor mediante el slashing de su stake y exigirle responsabilidad.

Como parte del ciclo de lanzamiento de Agave 2.3, Solana activará una feature gate para el programa de slashing, según lo descrito en el SIMD: SIMD-0204: Verificación de eventos sancionables. Este es el primer paso para habilitar el slashing programático en Solana, con énfasis en la detección y atribución de faltas. Incorpora un programa on-chain que permite que cualquier persona reporte y registre conductas sancionables, lo que sienta las bases para una futura aplicación automatizada.

Este programa no modifica el stake ni las recompensas; solo verifica y registra las infracciones y funciona como un registro on-chain de las conductas indebidas de los validadores. Ya se implementó un prototipo inicial del programa en Testnet (por ejemplo, una transacción de muestra de DuplicateBlockProof). 

Al principio, el programa se enfocará en detectar y registrar la producción de bloques duplicados. Está previsto que más adelante admita otras infracciones, como la doble votación. Es importante destacar que el slashing programático se limita a las conductas indebidas que pueden demostrarse claramente. Por lo tanto, es mucho más difícil sancionar problemas subjetivos o sistémicos, como la producción deliberadamente lenta de bloques o la extracción de MEV, y es poco probable que el programa de slashing los aborde.

Las pruebas enviadas incluyen dos shreds en conflicto para el mismo slot, ambos firmados por el mismo validador. El programa de slashing verifica la prueba comprobando que los shreds formen una prueba válida de bloque duplicado, que pertenezcan al mismo slot y que estén firmados correctamente por el validador infractor. Esta lógica refleja el enfoque que usa el protocolo gossip de Solana para gestionar pruebas de bloques duplicados durante el proceso de selección de bifurcaciones. 

Una vez que una prueba se verifica correctamente, los resultados se almacenan en una dirección derivada de programa (PDA) para futuras consultas. Esto facilita la creación de paneles que muestran datos relacionados con el slashing con solo ejecutar getProgramAccounts en el programa de slashing. Los validadores pueden usarlo para comprobar si se reportaron infracciones en su contra y tomar las medidas correctivas necesarias.

Un futuro SIMD abordará la aplicación económica del slashing, incluidos parámetros como la penalización de stake para distintas infracciones. Como estas decisiones afectan la economía de operar un validador de Solana, cualquier cambio propuesto deberá aprobarse mediante una votación completa de gobernanza.

Transiciones de época más rápidas

Agave 2.3 incorpora una mejora importante en la velocidad de las transiciones de época. Los cálculos de recompensas de época ahora se completan en menos de 500 milisegundos. Esto reduce la cantidad de slots omitidos y mejora la confiabilidad de la inclusión de transacciones cerca del límite de la época.

Además, si se omite el primer slot de líder de una nueva época, Agave 2.3 garantiza que los cálculos de recompensas no se vuelvan a ejecutar. En su lugar, se reutilizan los resultados calculados previamente, lo que elimina los cálculos redundantes y permite un inicio más fluido de la nueva época.

Optimizaciones de AccountsDB

La eficiencia del almacenamiento mejoró considerablemente en esta versión. El uso de E/S de disco disminuyó aproximadamente un 75 % y el volumen de solicitudes de reparación se redujo cerca de un 85 %. En conjunto, estas optimizaciones permiten un rendimiento más uniforme y confiable de los nodos, especialmente durante períodos de alta carga en la red.

Planificador voraz activado de forma predeterminada

En Agave 2.3, el planificador voraz ahora está activado de forma predeterminada. El planificador central anterior solía convertirse en un cuello de botella cuando la red soportaba una carga elevada debido al tiempo necesario para ordenar las transacciones y crear un grafo de dependencias. El nuevo enfoque voraz acelera considerablemente la planificación de transacciones gracias a una lógica simplificada y lotes más pequeños.

Puedes obtener más información sobre el planificador voraz en nuestra publicación anterior del blog de Helius.

Versión de shred en gossip

Agave 2.3 aplica de forma más estricta la coincidencia de versiones de shred en la red gossip. Ahora los nodos solo pueden establecer conexiones gossip entrantes si su versión de shred coincide con la del clúster, lo que ayuda a rechazar antes los nodos mal configurados.

Anteriormente, los nodos espía podían unirse a la red sin que su versión de shred coincidiera con la del clúster. Con este cambio, todos los nodos, incluidos los que funcionan en modo espía, deben obtener la versión de shred correcta desde un punto de entrada del clúster o configurarla explícitamente mediante la línea de comandos.

Esta actualización amplía las iniciativas recientes para reducir la sobrecarga de gossip. En los últimos meses, el tráfico gossip entrante disminuyó aproximadamente un 61 %, gracias a la obsolescencia de tres tipos de mensajes gossip y a la eliminación de los anuncios de slots de época por parte de validadores sin stake.

Las simulaciones RPC incluyen el uso de recursos

Para mejorar la visibilidad del uso de recursos de las transacciones, se agregó un nuevo campo al método RPC `simulateTransaction` predeterminado: `loadedAccountsDataSize`. Este campo informa la cantidad total de bytes de datos de cuentas cargados durante la simulación.

Esta incorporación permite que los desarrolladores calculen los costos de las transacciones y ajusten las tarifas de prioridad con mayor precisión. Cargar datos de cuentas consume unidades de cómputo (CU) a una tasa de 8 CU por cada 32 KB, basada en el tamaño de asignación de páginas de heap de Solana. Al mostrar esta métrica, los desarrolladores pueden optimizar mejor la rentabilidad al crear y enviar transacciones.

Mejoras en las instantáneas

Las instantáneas funcionan como puntos de guardado periódicos y permiten que los nodos restauren su estado. Los nodos generan estas instantáneas continuamente y, con el tiempo, reemplazan las anteriores por versiones más recientes.

Esta versión incorpora varias mejoras prácticas en el funcionamiento de las instantáneas:

• Intervalo predeterminado actualizado: El intervalo predeterminado de las instantáneas completas aumentó de 25 000 a 50 000 slots, lo que reduce la frecuencia con la que se crean.
• Nueva opción para desactivar las instantáneas: Se incorporó una nueva opción `--no-snapshots` para desactivar explícitamente la generación de instantáneas. El método anterior que usaba `--snapshot-interval-slots 0` ahora está obsoleto.
• Comportamiento mejorado de Geyser: Al restaurar desde una instantánea, las notificaciones de cuentas enviadas mediante Geyser ya no se deduplican.

Otro beneficio de ampliar el intervalo de las instantáneas es un rendimiento más fluido del disco, con menos picos de IOPS (operaciones de entrada/salida por segundo).

Mejoras en la cadena de herramientas SBPF

Agave 2.3 incorpora varias mejoras prácticas para los desarrolladores que trabajan con la cadena de herramientas SBPF:

• Selección de versión: Ahora los desarrolladores pueden seleccionar explícitamente versiones específicas de BPF VM (v0–v3) al compilar programas, lo que ofrece mayor control.
• Solo Rust para SBPFv3: A partir de SBPFv3, solo se admite la cadena de herramientas basada en Rust. La cadena de herramientas C heredada ya no es compatible con versiones futuras.
• Nueva opción de optimización: Se agregó una nueva opción de compilación `--optimize-size` para generar binarios de programas más pequeños para su implementación. Esto puede reducir el almacenamiento, aunque podría aumentar ligeramente el uso de unidades de cómputo (CU).

Otros cambios

Esta versión también incluye las siguientes actualizaciones:

• Recuperación automática del clúster: Se incorporó una nueva función de recuperación del clúster, `wen-restart`, para activar automáticamente el reinicio del clúster si la cadena falla.
• ABI de registro actualizado: El ABI de registro `TimedTracedEvent` se actualizó para incluir nuevos diagnósticos. Por lo tanto, los validadores deben actualizar cualquier herramienta externa de rastreo o análisis que dependa de estos registros para garantizar la compatibilidad. Los datos de rastreo existentes deben borrarse después de la actualización para evitar incompatibilidades de formato.
• Mejoras en la CLI: Se agregó withdraw-stake AVAILABLE para simplificar el retiro de todos los lamports sin stake y se actualizó solana-test-validator para vincular los servicios RPC a localhost (127.0.0.1) de forma predeterminada, lo que mejora la seguridad.
• Inicio más rápido: Los tiempos de inicio de los validadores se redujeron considerablemente. Ahora los nodos tardan aproximadamente 3 minutos en iniciarse y cargar el ledger, y alrededor de 5 minutos en alcanzar la punta de la cadena. Sin embargo, fastboot ahora requiere un cierre controlado mediante la nueva opción --wait-for-exit. Los operadores deben permitir que el proceso del validador finalice por completo por sí solo antes de reiniciarlo, en lugar de ejecutar un comando de reinicio inmediato.

Conclusión

Agave 2.3 representa otro hito clave para el protocolo de Solana. Entre los puntos destacados se incluyen el lanzamiento de un nuevo cliente TPU (`tpu-client-next`), reducciones importantes de la E/S de disco mediante optimizaciones de AccountsDB, un mejor rendimiento de las instantáneas, mejoras en la red gossip y transiciones de época y tiempos de inicio más rápidos. En conjunto, estas actualizaciones hacen que la red sea más robusta y mejoran la experiencia tanto de los desarrolladores como de los operadores de validadores.

Solana continúa avanzando de manera constante hacia una red robusta con múltiples clientes. Firedancer ya funciona sobre más del 8 % del stake total y esa cifra sigue aumentando. Casi un año y medio de funcionamiento ininterrumpido refleja la creciente madurez y estabilidad del software central de la red. Al mismo tiempo, se acelera el ritmo de los lanzamientos principales y secundarios.

Próximamente: ¡Agave 3.0!

Recursos adicionales

• Calendario de lanzamiento de Agave 2.3
• Registro de cambios de Agave 2.3
• Solicitudes de incorporación de cambios de Agave 2.3
• Notas del parche de Agave 2.3 - Blog de Anza 
• Presentación de tpu-client-next - Solana Core Community Call, 20 de junio de 2025