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

Actualizaciones destacadas del ciclo de lanzamiento de Agave 2.1 

• Amplias optimizaciones de rendimiento
• Aumento de los límites de bloque
• Introducción del planificador voraz (experimental)
• Compatibilidad nativa con la verificación de firmas Secp256r1 (Actualización: pospuesta hasta Agave 2.2)
• Desactivación del cobro de tarifas de renta y de las reescrituras por renta
• Flexibilización de las restricciones para los errores de carga de transacciones
• Migración de los programas de configuración y tablas de consulta de direcciones a BPF central

Cada sección de este artículo está diseñada para leerse de forma independiente. Así puedes navegar libremente y concentrarte en los temas que más te interesen. Ya seas operador de validadores, desarrollador o usuario activo, este análisis detallado de Agave 2.1 te dará la información que necesitas para aprovechar estos avances de manera eficaz.

Implementación de funciones

Al momento de escribir este artículo, el 88 % del stake ya ejecuta Agave versión 2.1.11. Las activaciones de funciones en mainnet se pausaron temporalmente para permitir una adopción más amplia de v2.1 y se espera que se reanuden pronto según el orden de activación programado. 

La mayoría de las nuevas funciones completas que se describen en las siguientes secciones aún no están activas. Se espera que se implementen durante el ciclo de lanzamiento 2.1 mediante el sistema de activación de funciones. Las funciones se activan en determinadas épocas según su prioridad relativa y el orden en que se activaron en los clústeres testnet y devnet.

Mejoras de rendimiento

Los validadores y operadores de RPC han informado mejoras evidentes en la estabilidad y el rendimiento con Agave 2.1. Durante el último año, Anza ha priorizado eliminar cuellos de botella, optimizar la eficiencia de los recursos y mejorar el rendimiento general. Las nuevas versiones del cliente buscan tanto perfeccionar los fundamentos centrales —aumentar el ancho de banda y reducir la latencia— como incorporar nuevas funciones. Antes de entrar en los detalles de la actualización 2.1, conviene tomar perspectiva y cuantificar las importantes mejoras de rendimiento logradas en la secuencia más reciente de actualizaciones del cliente.

Tiempos de bloque

Los tiempos de bloque más rápidos en Solana están reduciendo los tiempos promedio de slot por debajo de 400 ms. Las épocas recientes van camino a completarse en poco menos de dos días, el ritmo más rápido en la historia de la red. Ambos clientes están preparados para tiempos de bloque más cortos. Esta aceleración tiene implicaciones que van más allá de un mayor procesamiento de transacciones. Como las recompensas de staking están vinculadas a las emisiones inflacionarias, que se calculan mediante "años de época" y no años calendario, los validadores y quienes hacen staking pueden beneficiarse. Un año de época supone 182.5 épocas por año, según la duración estándar de dos días por época. Cuando las épocas se acortan, caben más en el mismo periodo, lo que aumenta de forma efectiva la frecuencia de distribución de las recompensas de staking.

Tiempo de actividad

Solana demostró una confiabilidad casi perfecta durante 2024 y principios de 2025, con un tiempo de actividad del 100 % durante más de un año. La última interrupción registrada ocurrió el 6 de febrero de 2024, cuando un error conocido interrumpió temporalmente la finalización de bloques en Mainnet. El problema se identificó y corrigió rápidamente. Desde entonces, Solana ha producido bloques sin interrupciones, incluso durante periodos de intensa actividad en la red, como el reciente aumento impulsado por los lanzamientos de tokens de la familia Trump, lo que demuestra su resiliencia bajo cargas elevadas.

Tasas de slots omitidos

La tasa de slots omitidos mide la frecuencia con la que un validador, asignado como líder de un slot determinado, no produce un bloque dentro del tiempo asignado. Desde aproximadamente la época 700, en noviembre de 2024, las tasas de slots omitidos han disminuido drásticamente. Tras fluctuar entre el 2 % y el 5 % durante varios años, ahora han caído a casi cero para la mayoría de los validadores bien optimizados.  

Un factor que contribuyó a esta mejora fue la introducción de recompensas de época particionadas en mainnet durante la época 707. Al distribuir las recompensas de stake entre varios bloques, este cambio mitiga los cuellos de botella de rendimiento provocados por la concentración de la distribución de recompensas en el primer bloque de cada nueva época. El resultado es un funcionamiento más fluido de la red.

Además, los Créditos de voto oportuno (TVC), introducidos en noviembre de 2024, incentivan a los validadores a votar con rapidez y desalientan los votos tardíos. Al reducir el número de validadores que retienen votos de forma intencional, TVC mejora la convergencia del clúster y permite una confirmación y finalidad más rápidas. Este mecanismo ayuda a minimizar las bifurcaciones y acorta su duración. Como la puntuación TVC ahora influye en la clasificación de los pools de stake, los operadores han respondido actualizando su hardware y optimizando sus configuraciones de validadores para mejorar el rendimiento.

Transacciones por segundo (TPS)

Un mayor número de transacciones por segundo (TPS) indica un mayor rendimiento de la cadena. Los TPS sin votos de Solana (también llamados «TPS reales») mantienen una tendencia ascendente constante desde finales de 2023. Los datos más recientes de la primera semana de febrero de 2025 muestran que la red registró un promedio de 1,228 TPS en el percentil 50, con un rendimiento máximo de 2,520 TPS en el percentil 99.  

El máximo histórico de TPS se observó durante la semana del airdrop del token PENGU, que terminó el 23 de diciembre de 2024. El percentil 50 promedió 1,260 TPS, mientras que el percentil 99 alcanzó un máximo de 3,252 TPS. Este crecimiento sostenido demuestra la continua escalabilidad de Solana y la mejora en la eficiencia del procesamiento de transacciones.

Tarifas de prioridad

Por último, una comparación del cobro de tarifas de prioridad entre Agave 2.1 y la versión anterior 2.0, del 27 de enero al 4 de febrero de 2025, muestra que Agave 2.1 cobra de forma constante tarifas de prioridad ligeramente más altas.

Aumento de los límites de bloque

Está previsto aumentar los límites de bloque durante el ciclo de lanzamiento 2.1 de Solana, como se propone en SIMD-0207: Aumentar el límite de bloque a 50M. Actualmente, el protocolo limita los recursos computacionales totales por bloque a 48 millones de unidades de cómputo (CU). Los límites de bloque garantizan que los nodos puedan seguir el ritmo de la red al restringir la cantidad de trabajo que un líder puede incluir en un bloque. El equipo fundador eligió el límite actual de forma empírica, según lo que los validadores pueden procesar razonablemente para alcanzar tiempos de bloque de 400 milisegundos. 

Sin embargo, la actividad actual de mainnet no está limitada por los tiempos de ejecución. Esto significa que los bloques podrían admitir más transacciones sin superar el objetivo de 400 ms. Esta actualización introduce un aumento moderado del 4 % para ampliar gradualmente la capacidad de la red. Eleva el límite de cómputo por bloque de 48M a 50M CU. Aunque podría ser viable un aumento más agresivo, como duplicar el límite, se ha considerado demasiado arriesgado para un cambio inicial. Ampliar los límites de bloque afecta tanto a los validadores como a infraestructura crítica, incluidos nodos RPC, indexadores y servicios de archivo, que deben escalar en consecuencia.

Los demás límites del protocolo no cambian:

• El límite de cómputo por cuenta y por bloque se mantiene en 12M CU.
• El cómputo máximo por transacción se mantiene en 1.4M CU.

Se prevén nuevos aumentos de los límites de bloque, que deberían avanzar mediante el proceso formal de SIMD.

Planificador voraz

Contexto: el planificador central

La última gran actualización del planificador, el planificador central, se incorporó en Agave 1.18 en mayo del año pasado. Este planificador crea un grafo de dependencias de las N transacciones con mayor prioridad, donde N está configurado actualmente en 256. Después intenta programar las transacciones por orden de prioridad y garantiza que las transacciones sin conflictos se procesen primero. Una vez programadas, estas transacciones se eliminan del grafo, lo que permite priorizar las que antes presentaban conflictos. Luego, el planificador vuelve a llenar el grafo para mantener una cola de N transacciones.

Este enfoque se diseñó principalmente para optimizar el procesamiento de lotes grandes y mejorar el rendimiento general de las transacciones. Sin embargo, una desventaja importante es que crear el grafo de dependencias y ordenar las transacciones requiere mucho tiempo, lo que genera un cuello de botella. 

Consulta nuestra publicación anterior del blog de Helius para obtener una descripción más detallada de Agave 1.18 y la implementación del planificador central.

El nuevo planificador voraz

A diferencia del planificador central, el planificador voraz no crea un grafo de dependencias. En su lugar, sigue un enfoque más directo:

• Primero, selecciona la transacción con mayor prioridad.
• Si la transacción no presenta conflictos con un lote en curso, se agrega a una de las cuatro colas de hilos de trabajo.
• Si surgen conflictos, el lote actual se finaliza y se envía, y la transacción se agrega a un nuevo lote.

Este método acelera considerablemente la programación de transacciones, pero produce lotes más pequeños, lo que aumenta la sobrecarga por transacción. Sin embargo, en condiciones reales de mainnet, esta compensación vale la pena porque el tiempo de ejecución está dominado por el procesamiento BPF y no por el procesamiento por lotes.

El planificador central tiene dificultades cuando la carga de la red es alta, principalmente porque necesita tiempo para ordenar las transacciones y crear el grafo de dependencias. Al eliminar esta sobrecarga, el planificador voraz mejora la capacidad de respuesta a costa de una menor eficiencia del procesamiento por lotes.

Considera un escenario donde las transacciones pertenecen a tres grupos de conflictos: A, B y C. Las transacciones entran en conflicto cuando una quiere escribir en una cuenta que otra quiere leer o modificar. Las transacciones de A tienen tarifas de prioridad más altas que las de B o C.

• El planificador central programaría juntas las transacciones sin conflictos A1, B1 y C1 en un lote: [A1, B1, C1].
• El planificador voraz prioriza primero las transacciones con las tarifas más altas. Programa A1 como un lote independiente y luego continúa con A2 en el siguiente lote.

Esta priorización permite una programación más rápida, pero puede generar lotes más pequeños que los del planificador central.

Programa nativo para verificar firmas Secp256r1

Solana está incorporando un nuevo programa nativo para verificar firmas de curva elíptica secp256r1. Esto habilita la compatibilidad onchain con Passkeys, el estándar WebAuthn y nuevos modelos de abstracción de cuentas, incluida la autenticación de dos factores (2FA). Esta mejora abre el camino para que la autenticación sin contraseña, ya muy utilizada en Web2, funcione como segundo factor de seguridad onchain.

La curva elíptica secp256r1 es una curva criptográfica estandarizada por el NIST y cuenta con amplia compatibilidad en dispositivos modernos, incluidos:

• WebAuthn: Un estándar del W3C para la autenticación basada en criptografía de clave pública, compatible con todos los principales navegadores web.
• Secure Enclave de Apple: Un entorno de ejecución de confianza (TEE) basado en hardware que firma mensajes y al que solo se puede acceder mediante autenticación biométrica.
• Android Keystore: Una API para administrar claves privadas y métodos de firma que aprovecha el TEE del dispositivo para almacenar claves de forma segura.
• Passkeys: Un estándar de FIDO Alliance y W3C que reemplaza las contraseñas por pares de claves criptográficas y es compatible con la criptografía de curva elíptica.

Varias otras redes, incluida Ethereum (EIP-7212), también han explorado integrar compatibilidad con la curva secp256r1.

Detalles del programa Secp256r1

El nuevo programa se implementará con el ID: Secp256r1SigVerify1111111111111111111111111

Estructura de la instrucción:

• Un contador u8 especifica el número de firmas que deben verificarse.
• A continuación, se incluye un solo byte de relleno.
• Para cada firma, se utiliza la siguiente estructura serializada:

struct Secp256r1SignatureOffsets {
    signature_offset: u16,             // offset to secp256r1 signature of 64 bytes
    signature_instruction_index: u16,  // instruction index to find signature
    public_key_offset: u16,            // offset to public key of 32 bytes
    public_key_instruction_index: u16, // instruction index to find public key
    message_data_offset: u16,          // offset to start of message data
    message_data_size: u16,            // size of message data
    message_instruction_index: u16,    // index of instruction data to get msg data
}

Esta actualización proviene de SIMD-0048: Programa nativo para Sigverify con Secp256r1, propuesta por el equipo de Bunkr. El programa precompilado Secp256r1 SigVerify funcionará de forma similar a la compatibilidad existente de Solana con secp256k1 y las firmas ed25519.

Desactivación del cobro de tarifas de renta y omisión de reescrituras por renta

Dos actualizaciones relacionadas, propuestas en SIMD-0084: Desactivar el cobro de tarifas de renta y SIMD-0183: Omitir reescrituras por renta, eliminarán gran parte de la sobrecarga heredada asociada a las cuentas que pagan renta.

El cobro de tarifas de renta es un componente complejo dentro de Bank. Desactivarlo simplificará el código base del cliente validador y agilizará el desarrollo de todas las implementaciones de clientes validadores, ya que no tendrán que replicar la lógica de cobro de renta. La renta dejará de deducirse de las cuentas y las tarifas de renta cobradas ya no se distribuirán entre los validadores. Ya no es posible crear nuevas cuentas que paguen renta: cualquier intento producirá un error de transacción.

Actualmente, el cobro de renta comprueba cada cuenta al menos una vez por época. Carga y almacena cuentas aunque no hayan cambiado. Como todas las cuentas de Solana ya están exentas de renta, mantener este proceso supone un trabajo computacional innecesario.

Se eliminarán las reescrituras de cuentas relacionadas con la renta, lo que reducirá el número de cuentas almacenadas por slot. Como resultado, los validadores mejorarán su rendimiento porque se incluirán menos cuentas en los cálculos del hash delta de cuentas y del hash incremental de cuentas. Este cambio también reduce el tamaño de las instantáneas incrementales y disminuye aún más el consumo de recursos.

Flexibilización de las restricciones de transacciones: errores de carga

Actualmente, las transacciones de Solana están sujetas a restricciones estrictas que pueden hacerlas fallar antes de que se incluyan en un bloque. Estos errores previos al bloque desperdician recursos de cómputo del validador, ya que se utilizan recursos sin obtener tarifas de transacción. En la práctica, se realiza trabajo sin compensación.

La producción de bloques se complica aún más por la necesidad de filtrar transacciones que invocan programas no válidos o superan el límite máximo de 64 MiB (~67.11 MB) de datos de cuentas cargados. Estas restricciones aumentan la complejidad del ensamblaje de bloques y dificultan determinar su validez. Al flexibilizar estas restricciones, las transacciones podrían incluirse en un bloque y pagar tarifas sin tener que cargar y verificar previamente los datos del programa. Este cambio busca eliminar la dependencia del estado de las cuentas para validar bloques.

Estos cambios, propuestos en SIMD-0191, pueden afectar herramientas como los exploradores de blockchain, que asumen que todas las transacciones intentan ejecutarse. Además, los usuarios deben asegurarse de que sus transacciones puedan ejecutarse para evitar gastos innecesarios en tarifas.

Migración de los programas de configuración y tablas de consulta de direcciones a BPF central

Como parte de la transición en curso de programas nativos integrados a programas Berkeley Packet Filter (BPF), los programas Config y Address Lookup Table se migrarán a programas BPF centrales. Este cambio separa estos programas críticos del entorno de ejecución del validador, lo que permite actualizaciones más flexibles y un mantenimiento más sencillo.

Los programas BPF son menos complejos que sus equivalentes nativos, lo que simplifica el desarrollo y el mantenimiento en distintos clientes validadores. Con este cambio, los equipos que trabajan en Firedancer y Anza ya no tendrán que seguir e implementar por separado los cambios de los programas en sus entornos de ejecución. En su lugar, las actualizaciones se aplicarán de forma universal a todos los clientes. 

Los programas reimplementados conservarán ABI idénticas a las de sus versiones nativas. Esto garantiza una compatibilidad total y solo cambia el uso de cómputo.

Conclusión

La actualización Agave 2.1 marca un gran avance para Solana e incorpora importantes mejoras de funciones y optimizaciones del entorno de ejecución. Esta versión fortalece la red al ampliar su funcionalidad, perfeccionar su rendimiento y superar los límites de lo que Solana puede lograr. Con compatibilidad nativa para verificar firmas Secp256r1, mayores límites de bloque, amplias mejoras de rendimiento y la futura introducción del planificador voraz, Agave 2.1 mejora tanto la eficiencia como la escalabilidad. Ya seas desarrollador, validador o usuario activo, esta actualización abre nuevas posibilidades y hace que Solana sea más rápida, flexible y potente que nunca.

Recursos adicionales

• Repositorio del cliente Agave
• Calendario de lanzamiento de Agave v2.1
• Solicitudes de incorporación etiquetadas para Agave v2.1