Solana estrena una actualización mayor en su cliente validador. Agave 4.2 introduce bloques de 200 milisegundos y transacciones de hasta 4.096 bytes, más del triple del límite anterior de 1.232 bytes.
El cliente validador es el software que mantienen los nodos para confirmar transacciones y producir bloques. En Solana, Agave lo desarrolla Anza, la empresa creada por antiguos ingenieros de la Solana Foundation. Esta versión no es un parche menor: activa tres mejoras muy esperadas mediante feature gates, interruptores que permiten activar cambios de forma escalonada.
Qué trae Agave 4.2: transacciones más grandes y bloques más rápidos
El cambio más visible es el nuevo formato de transacción v1. El límite sube de 1.232 a 4.096 bytes, una ampliación de 3,3 veces definida en la propuesta de mejora SIMD-0296. Las transacciones legacy y v0 siguen funcionando, pero conservan el tope antiguo. Solo el formato v1 puede aprovechar el nuevo tamaño.
Ese límite de 1.232 bytes era una herencia de la arquitectura de red original. Las transacciones viajaban como datagramas UDP individuales y debían caber en la unidad máxima de transmisión IPv6, de 1.280 bytes. Tras restar cabeceras, quedaban 1.232. Solana migró hace tiempo a QUIC, un protocolo basado en flujos que ya no exige fragmentar cada transacción en un único paquete.
El nuevo estándar no solo amplía espacio. También resuelve una de las fricciones del formato v0: las Address Lookup Tables. Estas tablas comprimían las cuentas, pero obligaban a reconstruir la lista completa consultando estado onchain, un problema cuando una tabla ya estaba cerrada. Una transacción v1 puede incluir directamente las 64 cuentas completas, con sus claves públicas de 32 bytes cada una.
Los desarrolladores ganan margen para pruebas criptográficas, aprobaciones multisig y listas de cuentas grandes. Además, la cabecera v1 incorpora configuraciones que antes exigían instrucciones separadas: la tarifa de prioridad, el límite de unidades de cómputo y el tamaño de datos cargados.
Es la actualización de cliente más ambiciosa en la historia de Solana porque ataca a la vez latencia, tamaño de transacción y coste de mantener estado.
La rebaja del 90% en los bonos de estado abarata los pagos con tokens
El segundo gran cambio toca el término que en Solana se llama rent o alquiler, aunque en realidad no es un pago recurrente. Es un bono de estado: un depósito en SOL que una cuenta debe mantener mientras exista. Cuando la cuenta se cierra, el depósito se recupera. Hasta ahora, ese bono desanimaba aplicaciones con muchas cuentas.
Agave 4.2 reduce el parámetro lamports por byte de 6.960 a 696, un recorte del 90% en cinco escalones. Una cuenta de token SPL de 165 bytes pasa de requerir unos 0,16 dólares a menos de 0,02 dólares. Para pagos con stablecoins, distribuciones de tokens o airdrops, el coste de abrir una cuenta al usuario se desploma.
La rebaja no suprime el mecanismo de seguridad. La cuenta sigue necesitando un saldo mínimo, solo que ahora es diez veces menor. Y si el crecimiento del estado se descontrola, la propia actualización incluye protecciones para volver a subir el mínimo sin romper cuentas existentes, mediante las reglas de grandfathering de la SIMD-0392.
El riesgo de abaratar el estado y la apuesta por un segundo motor
Aquí está el matiz más interesante. Un bono de estado más bajo también abarata los ataques de spam. Enviar millones de cuentas basura cuesta menos capital inmovilizado. Según el análisis citado en el lanzamiento, los archivos de estado ocupan unos 495 GB frente a 1 TB recomendado. Agotar esa capacidad exigiría a un atacante bloquear aproximadamente 17,2 millones de dólares en SOL. Duplicar la asignación de almacenamiento a 2 TB eleva la barrera a 51 millones.
El crecimiento actual ronda 0,3 GB al día después de restar cuentas cerradas. Eso no significa que no haya concentración: una parte relevante del estado está ligada a cuentas de libros de órdenes como OpenBook y Serum, y otro porcentaje notable procede de activos lanzados con Pump.fun.
La historia de Solana ayuda a leer el movimiento. La red sufrió paradas de producción de bloques en septiembre de 2021 y febrero de 2022 por congestión y fallos de recursos. Desde entonces migró de UDP a QUIC y estabilizó el consenso con mejoras iterativas. Agave 4.2 sigue esa línea: cambios agresivos, pero activados por fases y con un plan de marcha atrás.
No veo esto como una actualización cosmética. Ataca tres costes reales: latencia de confirmación, espacio por transacción y capital bloqueado por cuenta. El riesgo es que bloques de 200 ms aprieten el hardware de validadores de gama baja y concentren la red en menos operadores. Es un riesgo asumido, medible y reversible. Agave sigue siendo el cliente dominante, y por eso cada release se observa como una actualización de la propia red.
