Agave 4.2, el mayor upgrade del cliente validador de Solana, reduce los slots a 200 milisegundos y triplica el tamaño de las transacciones. La actualización también rebaja un 90% la fianza de estado y deja listo Alpenglow para su activación en la próxima versión.
Tres cambios que tocan la velocidad, el coste y el tamaño de las transacciones
El cliente validador es el software que ejecutan los operadores de nodos para mantener la red y consensuar el estado. Agave, desarrollado por Anza, es el cliente dominante de Solana y heredero del código original que dejó Solana Labs. Este lanzamiento, el 4.2, es el que el propio equipo define como el mayor de su historia.
La reducción de slots (los intervalos de tiempo en los que la red produce un bloque) de 400 a 200 milisegundos acelera la confirmación de transacciones. En la práctica, Solana duplica su ritmo de producción de bloques, lo que estrecha el margen para estrategias de front-running y mejora la experiencia de las aplicaciones sensibles al tiempo, como los pagos o las liquidaciones.
El segundo cambio es el nuevo formato de transacción v1, que eleva el tamaño máximo de 1.232 bytes a 4.096 bytes, una mejora de 3,3 veces. Este incremento, definido en la propuesta SIMD-0296, ya no depende del límite de red heredado de la era UDP porque Solana migró su ingesta a QUIC, un protocolo que no obliga a fragmentar paquetes en datagramas individuales. El nuevo formato permite incluir hasta 64 direcciones completas sin tablas de compresión externas y admite cargas criptográficas como pruebas de conocimiento cero o firmas múltiples.
El tercer pilar es la rebaja de la fianza de estado, conocida popularmente como rent. No es un alquiler, sino un depósito reembolsable que cada cuenta debe mantener mientras exista en la blockchain. Agave 4.2 reduce el valor de referencia de 6.960 lamports por byte a 696, un descenso del 90% escalonado en cinco fases progresivas. Una cuenta estándar de token SPL pasa de exigir unos 0,16 dólares a menos de 2 centavos, lo que abarata la incorporación de nuevos usuarios a pagos con stablecoins, distribuciones y programas de fidelización.
La activación no es inmediata. Cada reducción se controla mediante feature gates, interruptores que activan el código solo cuando la red vota a favor. Así, los operadores pueden observar cómo responde el estado y frenar si el crecimiento descontrolado o el consumo de disco se convierten en un riesgo. Hoy, la base de datos de cuentas de Solana ocupa unos 495 GB frente a la asignación recomendada de 1 TB, y crece alrededor de 0,3 GB diarios.
Para que la reducción sea segura, la actualización introduce dos salvaguardas. La propuesta SIMD-0392 permite que las cuentas existentes queden exentas de un futuro aumento de la fianza, y una segunda propuesta, SIMD-0438, puede restaurar el valor anterior de 6.960 lamports por byte si el estado se desborda. Dicho de otro modo, Anza se guarda la marcha atrás.
Un cliente validador no se mide solo por cuántas transacciones caben en un bloque; también se mide por cuánta fricción elimina antes de que el usuario llegue a firmar.
Qué significa para los usuarios y por qué Anza blinda la reversibilidad
Para cualquier wallet, el coste de crear una cuenta asociada a un token era uno de los primeros roces al entrar en Solana. Con la rebaja del 90%, ese desembolso inicial pasa a ser casi residual y favorece que las plataformas de pagos asuman la incorporación de nuevos usuarios sin trasladar el coste. No obstante, el cambio no reduce los límites de cómputo, de firmas o de instrucciones: una transacción grande sigue necesitando capacidad de ejecución.
El nuevo formato v1, que mueve las firmas al final y utiliza un byte de versión 0x81, obliga a los exploradores, carteras e indexadores a actualizar sus lectores de transacciones. Para los desarrolladores, elimina buena parte de la complejidad asociada a las Address Lookup Tables, esas tablas externas que comprimían direcciones pero complicaban el parseo cuando desaparecían de la blockchain.
Alpenglow, la siguiente mejora del cliente, queda completa en esta versión pero no se activa todavía. Su despliegue está previsto para el próximo lanzamiento, según detalla Helius, el proveedor de infraestructura que ha documentado la actualización. Otra pieza, XDP transmit, llega habilitada por defecto y optimiza la transmisión de paquetes a nivel de red.
Lectura Merca2: una actualización de consenso que no es un simple parche
El historial de Agave importa. Tras las paradas de red de septiembre de 2021 y febrero de 2022, Solana arrastraba la etiqueta de cadena frágil. Desde entonces, la llegada de equipos como Anza y Jump Crypto con Firedancer ha repartido el riesgo de depender de un único cliente. El lanzamiento 4.2 no corrige un fallo: amplía márgenes de diseño con cambios que antes habrían sido impensables por la arquitectura de red.
La reducción de slots a 200 ms tiene una lectura de mercado. Un intervalo más corto significa ventanas de arbitraje más pequeñas, pero también exige más al consenso y a la infraestructura. Si la red lo absorbe sin elevar las transacciones fallidas, se confirma la tesis de que Solana puede escalar sin comprometer la descentralización de su set de validadores, que hoy ronda el millar de nodos operativos.
El principal riesgo de esta actualización no es técnico, sino de incentivos. Abaratar el estado reduce la barrera para que un atacante perpetúe datos basura; por eso la activación escalonada y las herramientas de reversibilidad son la parte menos vistosa pero más sensata del diseño. Mi lectura es prudente: prefiero ver dos trimestres de crecimiento de cuentas antes de dar por cerrada la transición.
La próxima prueba será la activación de Alpenglow. Hasta entonces, el ecosistema observará si los usuarios notan de verdad la caída de la fianza, si los desarrolladores adoptan el formato v1 y si el estado de Solana crece de forma controlada. El consenso es frágil cuando se toca sin red.
