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

Introducción

Con Agave 4.0, el cliente validador principal de Solana da otro paso adelante. Mejora las rutas esenciales de rendimiento y prepara la red para bloques más grandes y la esperada actualización del consenso Alpenglow.

Actualizaciones destacadas del ciclo de lanzamiento de Agave 4.0

• XDP acelera drásticamente la retransmisión de Turbine
• Replay Stage con menor latencia
• Preparación para Alpenglow: marcadores de transferencia rápida de líder y validación encadenada del ID de bloque*
• Compatibilidad criptográfica ampliada: aritmética G2 y syscalls BLS12-381*
• Serialización mejorada con Wincode
• Aumento de la delegación mínima de stake con Stake Program v5*
• Reactivación del programa de pruebas ZK ElGamal*
• Compatibilidad con programas SBPFv3*

* actualizaciones controladas mediante feature gates

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

Al momento de escribir este artículo, Agave v4.0.0-rc.0 se considera un candidato de actualización para mainnet (MUC), y Anza busca voluntarios para ayudar a que la versión alcance el 25 % del stake. Validadores: ¡es hora de actualizar!

XDP está listo para una adopción más amplia

XDP (abreviatura de eXpress Data Path) es la ruta de red de alto rendimiento que Agave usa para acelerar Turbine. Permite que Agave cargue un programa eBPF cerca de la tarjeta de interfaz de red, lo que permite que el tráfico de shreds omita gran parte de la ruta estándar de procesamiento de paquetes de Linux.

Esto es importante porque Turbine se convierte en el principal cuello de botella a medida que Solana avanza hacia límites de bloque más altos. Los líderes deben distribuir shreds a cientos de pares, y los validadores grandes ya pueden acercarse a 150 000 paquetes salientes por segundo en las condiciones actuales. Conforme la red avanza hacia el objetivo de larga data de bloques de 100 millones de CU, el despacho de paquetes y el rendimiento de retransmisión deben escalar junto con el rendimiento de ejecución. XDP crea ese margen al hacer que la propagación de bloques sea muchísimo más rápida.

Con Agave 4.0, XDP ya está listo para una adopción más amplia entre los validadores. Se ha sometido a pruebas de estrés con varias configuraciones, se ha reforzado aún más y ha recibido mejoras adicionales de enrutamiento. Los resultados en producción son sumamente alentadores: la retransmisión de Turbine es varios órdenes de magnitud más rápida.

Alessandro Decina

@alessandrod

one of the largest validators turbine retransmit from 600ms to ~0.8ms agave 4.0 w/ XDP is going to be the biggest solana upgrade to date https://t.co/cKwqVnpH2g

22 abr 2026, 5:25 a.m.

Para obtener más contexto sobre por qué XDP representa una mejora tan importante, consulta nuestra entrevista anterior con Alessandro Decina, ingeniero de Anza.

Replay Stage más rápido

Agave 4.0 acelera la reproducción al sacar dos costosos pasos de verificación de la ruta crítica de los hilos de reproducción. En v4.0, tanto la verificación de entradas como la verificación de firmas de transacciones se ejecutan de forma asíncrona. Así, la reproducción puede seguir procesando mientras las tareas en segundo plano confirman que el slot es válido.

El primer cambio mueve la verificación de entradas de PoH a segundo plano. Antes, la reproducción verificaba en línea la cadena de hashes de las entradas antes de continuar. Un segundo cambio aplica la misma idea a las firmas de transacciones, pero con una separación importante: Agave ahora separa la verificación del hash y el mensaje de la transacción de la verificación de firmas Ed25519. La ruta del hash sigue ejecutándose primero para que las transacciones puedan sanearse y ejecutarse de forma segura, mientras que las verificaciones de firmas, más costosas, se ejecutan en segundo plano y se sincronizan antes de aceptar el bloque.

En la práctica, el resultado es una etapa de reproducción mucho menos bloqueada, especialmente durante slots con mucha actividad, donde las verificaciones de firmas escalan con la cantidad de transacciones.

Mayor adopción de Wincode

Wincode es una biblioteca de serialización y deserialización desarrollada por Anza, diseñada para la inicialización in situ y las escrituras directas en memoria con el fin de minimizar el almacenamiento intermedio. Ofrece un rendimiento de primer nivel entre los serializadores de Rust y mantiene compatibilidad total con el más popular bincode.

En Agave 4.0, más rutas de serialización críticas para el rendimiento están migrando de bincode a wincode. Como casi todos los datos escritos en disco o enviados por la red en Solana dependen de bincode, optimizar estas rutas tiene un impacto amplio.

Aumento de la delegación mínima de stake (Stake Program v5)

Agave 4.0 incluirá una actualización importante de Stake Program. Este cambio controlado mediante un feature gate, descrito en SIMD-0490, prepara el impulso más amplio de Solana para reducir las garantías de stake, también conocidas como renta.

El cambio más notable es que la delegación mínima de stake aumenta de 1 lamport a 1 SOL. Esto evita que el costo de crear y mantener cuentas de stake se vuelva demasiado bajo a medida que disminuyen los requisitos de renta, lo que podría introducir un posible vector de ataque. Aunque existen muchas cuentas de stake pequeñas por debajo de este umbral, solo representan el 0,02 % del stake activo total y conservarán sus condiciones actuales cuando la actualización entre en vigor.

La actualización también simplifica varias partes de la gestión de cuentas de stake. Cambia los cálculos de renta para usar la sysvar Rent en lugar de depender del valor rent_exempt_reserve almacenado en cada cuenta, hace opcionales las entradas de cuentas sysvar para las operaciones de Stake Program y reescribe la implementación de Split para corregir casos límite de larga data. 

La comunidad de operadores de validadores ha expresado su conformidad con el nuevo mínimo de 1 SOL. Las herramientas y dapps que interactúan con Stake Program deberán revisar su lógica para tener en cuenta el nuevo mínimo.

Compatibilidad criptográfica mejorada 

Varias activaciones de funciones durante el ciclo de lanzamiento de Agave 4.0 buscan ampliar las capacidades criptográficas nativas de Solana. Esto mejora la compatibilidad con casos de uso modernos, incluidas las pruebas ZK y las firmas BLS.

Reactivación del programa de pruebas ZK ElGamal

El programa de pruebas ZK ElGamal es un programa nativo de Solana que verifica las pruebas de conocimiento cero utilizadas en las transferencias confidenciales de Token-2022. Permite validar saldos y transacciones cifrados sin revelar los datos subyacentes. Funciona como un verificador generalizado de pruebas criptográficas basadas en ElGamal y constituye un componente clave de la funcionalidad de tokens de Solana que preserva la privacidad. 

El programa se deshabilitó en mainnet tras un incidente de seguridad en junio de 2025, en el que una falla en la lógica de verificación de pruebas —específicamente, un elemento faltante en el hash de la transcripción Fiat-Shamir— permitió construir pruebas falsificadas capaces de superar la verificación. Aunque no se observó ningún exploit en entornos reales, el posible impacto llevó a desactivar el programa mediante un feature gate y a pausar las transferencias confidenciales mientras se completaban las correcciones y auditorías. Tras resolver los problemas y reforzar la implementación, el programa está listo para reactivarse en mainnet.

Aritmética G2 para alt_bn128

SIMD-0302: Agregar syscalls G2 de alt_bn128 amplía las syscalls criptográficas BN254 (alt_bn128) existentes de Solana para admitir operaciones nativas sobre puntos de la curva G2, incluidas la suma, la resta y la multiplicación escalar. G1 y G2 son los dos grupos de curvas elípticas utilizados en la criptografía basada en emparejamientos, y G2 se define sobre un campo de extensión más grande.

Esto cubre una carencia clave del conjunto actual de syscalls, que se centra principalmente en operaciones G1, y habilita una compatibilidad más completa con la criptografía basada en emparejamientos directamente on-chain, especialmente para casos de uso como la verificación de firmas BLS y los sistemas avanzados de pruebas ZK.

Ante la falta de compatibilidad nativa con G2, algunos proyectos han recurrido a implementaciones personalizadas como solana-alt-bn128-bls, una biblioteca integral de firmas BLS creada por Dean Little, de Blueshift, sobre las syscalls existentes. Habilitar las operaciones G2 en el nivel de las syscalls eliminaría la necesidad de estas soluciones alternativas y facilitaría la creación de protocolos criptográficos listos para producción de forma nativa en Solana.

Compatibilidad little-endian para alt_bn128

SIMD-0284: Agregar compatibilidad little-endian para alt_bn128 amplía las syscalls criptográficas alt_bn128 existentes de Solana para admitir formatos de entrada y salida little-endian. Antes, estas syscalls solo aceptaban codificación big-endian, lo que generaba fricción para quienes usaban herramientas y bibliotecas, en particular las del ecosistema de Ethereum, ya que la mayoría de los equipos de ZK en Solana usan ark-bn254, que funciona en little-endian. El cambio es retrocompatible y amplía la compatibilidad con los casos de uso existentes que implican operaciones de curvas elípticas en alt_bn128.

Syscalls BLS12-381

Por último, SIMD-0388: Syscalls BLS12-381 introduce compatibilidad nativa con operaciones criptográficas en la curva elíptica BLS12-381. Así, los programas de Solana obtienen una curva moderna de 128 bits de seguridad y apta para emparejamientos. Hasta ahora, Solana ha dependido de BN254 (alt_bn128) para la criptografía basada en emparejamientos, que no cumple este estándar de seguridad y limita la compatibilidad con otros ecosistemas de amplia adopción, como Ethereum.

En lugar de introducir una interfaz de syscall completamente nueva, esta actualización amplía las syscalls de curvas existentes con nuevos identificadores para las operaciones G1 y G2 de BLS12-381. Esto permite realizar aritmética de grupos, validación de puntos, descompresión y comprobaciones de emparejamiento por lotes mediante una interfaz conocida, a la vez que amplía considerablemente las capacidades criptográficas.

Además de ofrecer mejoras generales para las pruebas de conocimiento cero y la verificación de firmas BLS, este trabajo también es un habilitador clave para el consenso Alpenglow. En particular, permite que los validadores verifiquen on-chain las pruebas de posesión BLS, lo que evita ataques de claves maliciosas. Esto nos lleva a la siguiente sección.

Preparación para Alpenglow

Las syscalls BLS12-381 son solo una de varias activaciones mediante feature gates durante el ciclo de lanzamiento de Agave 4.0 que sientan las bases para la actualización del consenso Alpenglow. A continuación se muestran activaciones adicionales que contribuyen al despliegue, actualmente previsto para llegar a mainnet en el tercer trimestre de 2026 junto con Agave 4.1.

Validación encadenada del ID de bloque

SIMD-0340: Validar el ID de bloque encadenado define cómo los validadores deben verificar la ascendencia de los bloques para garantizar una cadena canónica y coherente con los consensos TowerBFT y Alpenglow. Dado que los números de slot por sí solos no identifican los bloques de forma única, especialmente en casos de equivocación donde pueden producirse varios bloques para un mismo slot, los clientes no pueden depender del orden de los slots para determinar la relación correcta entre bloque padre e hijo.

Este cambio introduce reglas explícitas de validación de la cadena para garantizar que cada bloque haga referencia correctamente a su padre. Así evita divergencias y ayuda a que la red converja en un único historial. En TowerBFT, esto se aplica exigiendo que los conjuntos FEC hagan referencia a la raíz de Merkle de su padre tanto dentro de los slots como entre ellos. Alpenglow usa una construcción de raíz de Merkle doble sobre todos los conjuntos FEC de un slot. Si estas comprobaciones fallan, el bloque o el slot se marca como inactivo. Aplicar estas reglas refuerza la seguridad del consenso y garantiza que los validadores puedan recuperarse tras recibir bloques incorrectos o en conflicto.

Marcadores de transferencia rápida de líder

SIMD-0337: Marcadores para la transferencia rápida de líder de Alpenglow define reglas explícitas de señalización que permiten a los validadores determinar cuándo un slot padre está completamente finalizado y es seguro construir sobre él, un requisito para las transiciones rápidas de líder. El cambio introduce requisitos de ubicación más estrictos para DATA_COMPLETE_SHRED y un nuevo marcador de “padre listo”, lo que garantiza que el estado completo de un bloque pueda detectarse sin ambigüedades directamente desde el flujo de shreds.

Hoy, la ambigüedad sobre si un slot se ha transmitido por completo puede retrasar al siguiente líder, ya que quizá deba esperar shreds adicionales o arriesgarse a construir sobre datos incompletos. Al estandarizar cómo se indica la finalización, este cambio permite que el siguiente líder comience a producir bloques antes y con confianza, sin coordinación adicional ni conjeturas.

Este es un componente fundamental del diseño de transferencia rápida de líder de Alpenglow, en el que minimizar el intervalo entre líderes mejora directamente el rendimiento de la red.

Actualización del modelo de costos de las transacciones de voto

SIMD-0458: Dejar de usar el costo estático de transacciones SimpleVote elimina el uso de un costo fijo en CU para las transacciones de voto y las alinea con el modelo estándar de costos utilizado para las transacciones que no son de voto. 

Hoy, las transacciones de voto simples tienen un costo constante de 3428 CU, basado en supuestos heredados sobre un costo de ejecución determinista. Con el nuevo modelo, las transacciones de voto se medirán dinámicamente como cualquier otra transacción, lo que hará más coherente la contabilización de costos y eliminará la necesidad de un límite de CU independiente para los votos.

Aunque el consumo real de CU en tiempo de ejecución de las transacciones de voto permanece igual, sí cambia la forma de contabilizarlas durante el empaquetado de bloques. En particular, los votos ahora incluirán unas ~16 mil CU estimadas adicionales, como los costos de carga de datos de las cuentas. Esto dará lugar a reservas iniciales de CU más altas cuando los líderes construyan bloques.

Este cambio sucede a SIMD-0387 (gestión de claves públicas BLS en la cuenta de voto), que eliminó la suposición de que Vote Program tiene un perfil de ejecución estático.

Otras actualizaciones destacadas

Otros aspectos destacados del ciclo de lanzamiento de Agave 4.0 incluyen compatibilidad con programas SBPFv3, la capacidad de crear cuentas prefinanciadas y E/S directa para desempaquetar snapshots.

Compatibilidad con programas SBPFv3

El ciclo de lanzamiento de Agave 4.0 incluye un feature gate que habilita el despliegue y la ejecución de programas SBPFv3. Solana Berkeley Packet Filter (SBPF) es el fork de eBPF basado en Rust de Solana: el formato de bytecode de bajo nivel y la máquina virtual a los que se compilan los programas on-chain antes de ejecutarse. Esta actualización combina el trabajo descrito en tres SIMD: SIMD-0178, SIMD-0189 y SIMD-0377. 

SIMD-0178 introduce syscalls estáticas, lo que permite resolver las referencias a syscalls durante el enlazado, en lugar de hacerlo mediante reubicaciones ELF en tiempo de ejecución. Actualmente, esas reubicaciones añaden complejidad al cargador de programas. Eliminarlas simplifica la ejecución y reduce el riesgo de seguridad.

SIMD-0189 restringe después la disposición ELF permitida para los programas, exigiendo una estructura de archivos más estricta para que los validadores tengan menos casos límite que analizar y menos datos inesperados que gestionar. Esto debería ser transparente para quienes desarrollan, ya que se espera que la cadena de herramientas del enlazador genere automáticamente binarios compatibles.

Por último, SIMD-0377 actualiza la máquina virtual SBPF para que coincida mejor con el conjunto moderno de instrucciones eBPF generado por LLVM. Esto incluye compatibilidad con instrucciones adicionales, como operaciones de salto de 32 bits. El objetivo es hacer que la VM de Solana sea más compatible con las herramientas upstream y permitir que los programas se compilen en un bytecode más eficiente. Para quienes desarrollan, el resultado práctico es una carga de programas más rápida, una superficie de ataque menor y la posibilidad de reducir el uso de cómputo sin cambiar la lógica de la aplicación.

Creación de cuentas prefinanciadas

Está previsto que SIMD-0312: CreateAccountAllowPrefund se active en mainnet durante el ciclo de lanzamiento de Agave 4.0. Esto introduce una nueva instrucción en System Program que elimina el requisito de que las cuentas recién creadas comiencen con un saldo de cero lamports. Así, las cuentas pueden prefinanciarse antes de su creación, lo que simplifica un flujo de trabajo común y reduce las instrucciones innecesarias.

Antes, la instrucción CreateAccount fallaba si la cuenta de destino ya contenía lamports. Como resultado, quienes desarrollaban debían dividir la inicialización de la cuenta en varios pasos: normalmente una transferencia, seguida de allocate y assign. Esto aumenta la complejidad y añade un costo de cómputo adicional. Este patrón es especialmente común en programas que financian cuentas por adelantado.

La nueva instrucción consolida estos pasos en una sola llamada al permitir inicializar directamente cuentas prefinanciadas. En la práctica, esto reduce la sobrecarga de CPI y puede ahorrar miles de unidades de cómputo en flujos comunes, ofreciendo en adelante una ruta más limpia y eficiente. Como se introduce mediante una instrucción nueva y no como una modificación de las instrucciones existentes, mantiene una retrocompatibilidad total.

E/S directa para desempaquetar snapshots 

Agave 4.0 cambia el desempaquetado de snapshots para usar E/S directa de forma predeterminada, en lugar de dirigir las escrituras de snapshots a través de la caché de páginas del sistema operativo. Esto mejora el tiempo de inicio y el rendimiento de restauración de snapshots. Resulta especialmente útil porque los datos de los snapshots suelen transmitirse al disco y no necesitan desplazar de la memoria los datos más activos del validador. Los operadores pueden desactivar esta opción con --no-accounts-db-snapshots-direct-io si su sistema de archivos no admite O_DIRECT. Se espera que la E/S directa también se aplique a la creación de snapshots en una versión futura. 

Conclusión

Agave v4.0 es una actualización importante del cliente que ofrece diversas mejoras de rendimiento y optimizaciones del entorno de ejecución. Estos cambios buscan hacer que la red sea más rápida, segura y fácil de usar para desarrollar.

De cara al futuro, el siguiente hito es Agave 4.1 y la actualización del consenso Apenglow.

Recursos adicionales

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