Solana Agave 4.2: Reducción del 90% en alquiler y el camino hacia slots de 200 ms

Tres actualizaciones activadas por funciones comenzaron a activarse en la red principal de Solana la semana del 17 de agosto. Una reducción del 90% en el alquiler de almacenamiento en cadena, un aumento de 3.3 veces en el tamaño máximo de transacción, y una reducción gradual del tiempo de ranura de 400ms a 200ms representan el cambio de infraestructura más significativo de Solana desde que Firedancer llegó a la red principal.

La hoja de ruta de infraestructura de Solana en 2026 es una secuencia de apuestas apiladas unas sobre otras. Firedancer llegó a la red principal en diciembre de 2025 y ahora lleva aproximadamente el 14% del stake de la red principal en más del 20% de los validadores activos. Agave 4.2 cambia la economía y las características de rendimiento de la red que esos validadores ejecutan. Alpenglow, que se lanzará en la próxima versión, reemplaza el mecanismo de consenso por completo. Cada capa depende de la anterior, y cada una cambia lo que los desarrolladores pueden construir en Solana.

Este artículo desglosa las tres actualizaciones de Agave 4.2, mide qué cambia cada una en la práctica, y examina cómo posicionan a Solana frente a la hoja de ruta Hegota de Ethereum y la competencia más amplia por la atención de desarrolladores y usuarios.

La reducción del alquiler: qué significan las cuentas de $0.016 para los constructores

El alquiler en Solana es el saldo mínimo que un usuario debe depositar para mantener una cuenta abierta. El depósito escala con la cantidad de datos almacenados. Bajo la tasa anterior, una cuenta de token SPL estándar requería aproximadamente $0.16 en SOL como depósito exento de alquiler. Esa cantidad no es una tarifa. Está bloqueada en la cuenta mientras exista y se devuelve cuando la cuenta se cierra.

SIMD-0437 reduce la constante de lamports por byte en un factor de 10, de 6,960 a 696. El depósito exento de alquiler para la misma cuenta de token cae a aproximadamente $0.016. Para una sola cuenta, la diferencia es trivial. Para aplicaciones que crean miles o millones de cuentas, la diferencia es estructural.

Un intercambio descentralizado que mantiene un libro de órdenes en cadena crea cuentas para cada orden abierta. Un protocolo de juegos que rastrea el estado del jugador crea cuentas para cada jugador activo. Una plataforma de tokenización que emite acciones fraccionarias crea cuentas para cada titular. En cada caso, el costo de arrancar la aplicación escala linealmente con el número de cuentas, y SIMD-0437 reduce ese costo en un 90%.

El efecto práctico es que categorías de aplicaciones que no eran económicas en Solana con la tasa de alquiler anterior se vuelven viables con la nueva. Los libros de órdenes en cadena con niveles de precios granulares, juegos completamente en cadena con estado persistente para millones de jugadores, y plataformas de tokenización con decenas de miles de titulares se vuelven significativamente más baratos de operar.

El contraargumento es que el almacenamiento más barato aumenta la hinchazón del estado. Cada cuenta que existe en Solana ocupa espacio que los validadores deben almacenar y procesar. Reducir el costo de crear cuentas en un 90% podría producir un aumento correspondiente en el número de cuentas, tensando los requisitos de hardware de los validadores. Anza, el equipo de desarrollo detrás de Agave, ha argumentado que la compresión de estado y las características de gestión del ciclo de vida de las cuentas en futuras versiones abordarán la hinchazón independientemente de la tasa de alquiler.

Transacciones más grandes: de soluciones alternativas a ejecución atómica

El límite de transacciones de 1.232 bytes ha sido uno de los puntos de dolor más persistentes para los desarrolladores de Solana. La restricción proviene del límite de tamaño de paquetes basado en UDP de la red, que se fijó en el lanzamiento y nunca se actualizó. Los desarrolladores que trabajan con operaciones complejas, pruebas ZK, configuraciones de multisig grandes y transacciones DeFi de múltiples instrucciones han tenido que dividir el trabajo en múltiples transacciones o usar tablas de búsqueda de direcciones para comprimir referencias.

SIMD-0296 eleva el límite a 4.096 bytes mediante un nuevo formato de transacción v1. El formato reemplaza las instrucciones de ComputeBudgetProgram con una máscara de configuración llevada directamente en el encabezado de la transacción, liberando espacio para datos de instrucciones reales. Las transacciones v1 se identifican por un byte de versión inicial de 129 y no admiten tablas de búsqueda de direcciones, pero a 4.096 bytes la lista completa de direcciones se puede incluir directamente en la mayoría de los casos.

El impacto se siente más en tres categorías de desarrolladores. La verificación de pruebas ZK, que requiere pasar datos de prueba como entrada de transacción, ahora puede realizarse como una sola transacción atómica en lugar de dividirse en múltiples llamadas. Las billeteras multisig grandes con muchos firmantes pueden incluir todas las firmas en una sola transacción. Y los esquemas de firma en cadena como BLS, que requieren material de clave más grande, pueden ejecutarse sin soluciones alternativas.

Las aplicaciones existentes no necesitan cambiar. Los formatos de transacción v0 y heredados continúan funcionando exactamente como antes. Solo las aplicaciones que quieran el tamaño más grande necesitan adoptar v1. Los indexadores y exploradores de bloques que decodifican bytes de transacción sin procesar necesitarán reconocer el nuevo diseño, pero el camino de migración es opcional en lugar de forzado.

El aumento de 3,3 veces puede parecer modesto en comparación con los calldata efectivamente ilimitados de Ethereum. La diferencia es que las transacciones de Solana se ejecutan en una sola ranura con ordenamiento determinista, mientras que las transacciones de Ethereum compiten por inclusión en un bloque con costos de gas variables. El enfoque de Solana intercambia flexibilidad por velocidad: una transacción de 4.096 bytes en Solana se confirma en menos de un segundo, mientras que una transacción comparable de Ethereum puede esperar minutos dependiendo de los precios del gas y la congestión del bloque.

El camino hacia ranuras de 200 ms

SIMD-0525 es la más ambiciosa de las tres actualizaciones y la que tiene el impacto más visible en los usuarios. El tiempo de ranura actual de Solana es de 400 ms, lo que significa que se produce un nuevo bloque aproximadamente cada 0,4 segundos. SIMD-0525 apunta a una reducción a 200 ms, duplicando efectivamente la tasa de producción de bloques de la red.

La reducción no es instantánea. Procede en cuatro decrementos sucesivos de 50 ms: de 400 ms a 350 ms, luego 300 ms, luego 250 ms, luego 200 ms. Cada decremento está controlado por una activación de característica que los validadores deben adoptar. El protocolo incluye una salvaguarda crítica: si las tasas de omisión de bloques superan un umbral definido en cualquier etapa, la red no avanzará al siguiente decremento hasta que se restablezca la estabilidad.

Testnet ya ha demostrado ranuras de 300 ms, validando los dos primeros decrementos. Los pasos restantes hacia 250 ms y 200 ms dependerán del rendimiento de los validadores de mainnet bajo carga del mundo real, que difiere de las condiciones de testnet en volumen de tráfico, distribución geográfica y diversidad de hardware.

Para los usuarios, ranuras más rápidas significan confirmaciones más rápidas. Un swap en un DEX de Solana actualmente se confirma en aproximadamente 400 ms. Con ranuras de 200 ms, el mismo swap se confirma en la mitad del tiempo. Para los creadores de mercado, ranuras más ajustadas significan diferenciales más ajustados, porque la ventana durante la cual un precio cotizado puede volverse obsoleto se reduce con cada decremento. Para los validadores, ranuras más rápidas significan requisitos de hardware más altos: el presupuesto de cómputo por ranura sigue siendo el mismo, pero el tiempo disponible para procesarlo se reduce a la mitad.

La preocupación por el hardware de los validadores no es teórica. ETHNews informó que la actualización Agave 4.2 "hace que sea más barato de usar, más difícil de ejecutar". La reducción del alquiler reduce los costos para los desarrolladores. La reducción del tiempo de ranura aumenta los costos para los validadores. Si el equilibrio es netamente positivo depende de si los costos de desarrollo más baratos atraen suficiente actividad nueva para justificar los mayores costos de infraestructura que los validadores deben absorber.

El papel de Firedancer en la actualización

Las demandas de rendimiento de Agave 4.2 serían más difíciles de cumplir sin la presencia de Firedancer en la red principal. El cliente validador en C y C++ de Jump Crypto, que llegó a la red principal en diciembre de 2025, proporciona una base de rendimiento que el cliente Agave original por sí solo no podría garantizar.

Los datos de los operadores del período de implementación de 2025 a 2026 muestran que los validadores de Firedancer lograron una mejora de 18 a 28 puntos básicos en la reducción de la tasa de omisión, un 15% menos de créditos de votación perdidos, una latencia de voto de aproximadamente 1.002 slots y bloques más llenos con un promedio de 47 millones frente a 44.8 millones de unidades de cómputo bajo Agave. Estos márgenes importan cuando los tiempos de slot se reducen a la mitad, porque la tolerancia a los retrasos de procesamiento se reduce con cada decremento.

Firedancer ahora lleva aproximadamente el 14% del stake de la red principal en más del 20% de los validadores activos. La diversidad de clientes también es una característica de resiliencia: un error que bloquee Agave no afectará necesariamente a Firedancer, y viceversa. Para una red que se prepara para reducir a la mitad su tiempo de slot y luego reemplazar por completo su mecanismo de consenso, tener dos clientes independientes no es un lujo sino un requisito de seguridad.

Alpenglow: la reescritura del consenso que espera en la próxima versión

Agave 4.2 incluye el código completo de Alpenglow pero no lo activa en la red principal. Esa activación está reservada para Agave 4.3, con fecha prevista para octubre de 2026. Cuando se lance, Alpenglow reemplazará tanto a Proof of History como a TowerBFT, los dos sistemas que Solana ha ejecutado desde su lanzamiento en 2020.

El reemplazo es Votor, un algoritmo de votación que apunta a una finalidad de aproximadamente 150 ms en comparación con la finalidad actual de TowerBFT de 12.8 segundos. Votor elimina por completo las transacciones de voto en cadena. Bajo TowerBFT, los validadores envían votos como transacciones regulares que consumen espacio de bloque y unidades de cómputo. Bajo Votor, los validadores intercambian votos directamente a través de un canal separado, liberando capacidad de bloque para transacciones de usuarios.

El modelo de seguridad tolera que el 20% del stake esté fuera de línea y el 20% del stake sea adversario simultáneamente. Anza ha publicado un programa de recompensas por errores de 50,000 SOL para Alpenglow, con presentaciones a partir del 5 de agosto, lo que indica confianza en el código base mientras reconoce que un reemplazo de consenso de esta magnitud requiere revisión de seguridad externa.

La secuencia importa. Agave 4.2 reduce el alquiler, aumenta el tamaño de las transacciones y comienza a reducir los tiempos de slot. Agave 4.3 reemplaza el mecanismo de consenso. Cada actualización está diseñada para ser útil de forma independiente, pero la visión completa, slots de 200 ms con finalidad de 150 ms en un protocolo de consenso que no consume espacio de bloque para votar, requiere que todas se implementen con éxito.

Cómo se compara esto con la hoja de ruta Hegota de Ethereum

Solana y Ethereum persiguen caminos diferentes hacia el mismo destino: menores costos, mayor rendimiento y finalidad más rápida. El contraste entre Agave 4.2 y el plan de actualización Hegota de Ethereum ilustra las diferencias arquitectónicas.

El cronograma de Hegota de Ethereum establece una fecha límite de preferencia en septiembre, con la actualización en sí dirigida a 2027. El alcance aún se está definiendo: se presentaron 66 propuestas, y la comunidad debe recortar la mayoría de ellas antes de finalizar la actualización. Los candidatos clave incluyen EIP-8182 para privacidad nativa, FOCIL para resistencia a la censura y aumentos de rendimiento de blobs para la escalabilidad de rollups. El devnet Glamsterdam se retrasó, empujando el cronograma más adelante.

El enfoque de Solana es más rápido y más centralizado en su toma de decisiones. Anza establece el cronograma de activación de funciones, los validadores lo adoptan y la actualización procede. No hay equivalente al proceso de EIP de varios años de Ethereum con gobernanza comunitaria sobre qué propuestas se incluyen. La compensación es que Solana puede implementar tres actualizaciones importantes en una sola versión mientras que Ethereum tarda de 12 a 18 meses en finalizar un alcance comparable de cambios.

La brecha de rendimiento después de Agave 4.2 es marcada. Solana con slots de 200 ms y finalidad de Alpenglow de 150 ms confirmaría transacciones en menos de 400 ms. La finalidad actual de Ethereum es de aproximadamente 13 minutos, con las mejoras de Hegota, si se implementan, apuntando a una finalidad de slot único que aún se mediría en segundos en lugar de milisegundos.

La brecha de costos también se está ampliando. La reducción de alquiler de Solana hace que el almacenamiento en cadena sea un orden de magnitud más barato. El L1 de Ethereum sigue siendo caro para el almacenamiento, con los rollups absorbiendo la mayor parte de la reducción de costos a través de datos blob. Para los desarrolladores que eligen dónde construir nuevas aplicaciones, la economía de infraestructura favorece cada vez más a Solana para casos de uso que requieren alto rendimiento, bajo costo y finalidad rápida.

El contraargumento es que el proceso más lento de Ethereum produce actualizaciones más robustas y probadas en batalla con un consenso comunitario más amplio. La ventaja de velocidad de Solana viene a costa de la presión de centralización de los validadores y un margen de seguridad más delgado durante las transiciones importantes de infraestructura. El mercado finalmente juzgará ambos enfoques por la adopción de desarrolladores y la actividad de usuarios, no solo por especificaciones técnicas.

La señal de migración de desarrolladores

Las actualizaciones de infraestructura solo importan si los desarrolladores responden construyendo aplicaciones que las utilicen. El indicador principal no es el precio de SOL ni el TVL, sino la tasa de nuevos despliegues de programas y el volumen de adopción de transacciones v1 en las semanas posteriores a la activación.

El ecosistema de desarrolladores de Solana ha crecido constantemente durante 2026, con la Fundación Solana reportando más de 2,500 desarrolladores activos mensuales en su informe de ecosistema más reciente. Se espera que la reducción de alquiler acelere el desarrollo de juegos en cadena, protocolos sociales descentralizados y plataformas de tokenización que anteriormente estaban limitados por los costos de creación de cuentas.

La dinámica competitiva también es relevante. Los desarrolladores que esperaban una infraestructura de Solana más barata ahora la tienen. Los desarrolladores que consideraban los rollups de Ethereum por razones de costo deben sopesar la complejidad adicional del puente L2 y la liquidez fragmentada contra la experiencia integrada de L1 de Solana a costos similares o más bajos.

El caso opuesto: por qué estas actualizaciones conllevan riesgo

El caso alcista para Agave 4.2 es que hace que Solana sea más barato, más rápido y más capaz. El caso bajista es que hace que Solana sea más difícil de ejecutar, aumentando la presión de centralización sobre los validadores mientras introduce tres cambios simultáneos en una red que procesa miles de millones de dólares en volumen diario.

La reducción de alquiler crea un riesgo de crecimiento del estado. Si el número de cuentas en Solana aumenta proporcionalmente a la reducción de costos, los validadores necesitarán almacenar y procesar 10 veces más datos de estado. La Fundación Solana no ha publicado una proyección de crecimiento del estado para el entorno posterior a SIMD-0437.

La reducción del tiempo de ranura aumenta los requisitos de hardware en un momento en que los costos de los validadores de Solana ya son más altos que los de la mayoría de las redes competidoras. Un validador que ejecuta Solana requiere hardware de alta gama con almacenamiento NVMe rápido, redes de alto ancho de banda y RAM sustancial. Reducir a la mitad el tiempo de ranura no duplica el costo del hardware, pero reduce el margen de error y puede empujar a los validadores más pequeños por debajo del umbral de rendimiento necesario para evitar penalizaciones por omisión.

El aumento del tamaño de transacción introduce un nuevo formato que los indexadores, billeteras y SDKs deben soportar. Si bien la migración es opcional, la fragmentación del ecosistema entre formatos de transacción v0, heredado y v1 crea complejidad adicional para los desarrolladores y proveedores de infraestructura.

El momento también introduce riesgo de ejecución. Activar tres características principales simultáneamente en una red que procesa miles de millones de dólares diariamente significa que cualquier efecto de interacción entre las actualizaciones, un escenario que la testnet puede no replicar completamente, podría surgir bajo carga de producción. La reducción escalonada del tiempo de ranura mitiga el mayor riesgo individual, pero la reducción de alquiler y el aumento del tamaño de transacción se activan sin salvaguardas equivalentes.

También hay un riesgo competitivo que se discute menos. Si Agave 4.2 tiene éxito, valida la tesis de que un solo equipo puede implementar cambios importantes de infraestructura más rápido que el proceso de gobernanza descentralizada de Ethereum. Esa tesis atrae desarrolladores a corto plazo. A largo plazo, crea dependencia de la competencia continua de Anza y su alineación con el ecosistema. El proceso más lento de Ethereum distribuye ese riesgo entre un conjunto más amplio de contribuyentes. Si la velocidad o la resiliencia importan más depende del horizonte temporal.

Lo que demostraría que el caso bajista es incorrecto: la activación exitosa de las tres características sin aumento en las tasas de omisión, sin salidas de validadores, y un crecimiento medible en la actividad de los desarrolladores y en las cuentas en cadena dentro de los 90 días. El período de 90 días es importante porque los cambios de infraestructura a menudo muestran sus efectos gradualmente en lugar de inmediatamente.

Qué ver

• Índice de omisión después de cada decremento de tiempo de ranura. La salvaguarda en SIMD-0525 detiene la progresión si los índices de omisión superan el umbral. Si la red avanza a través de los cuatro decrementos o se detiene en un paso intermedio señalará los límites del mundo real de la infraestructura de validadores de Solana.
• Tasa de creación de cuentas después de la reducción de alquiler. Un aumento brusco en nuevas cuentas valida la tesis de que el alquiler era una barrera significativa para el desarrollo. Una creación de cuentas plana sugeriría que la restricción estaba en otro lugar.
• Adopción de transacciones v1. La rapidez con la que los proveedores de billeteras, los DEX y los protocolos DeFi adopten el formato de transacción más grande determinará si el aumento de tamaño se traduce en nuevas capacidades o permanece sin uso.
• Resultados del programa de recompensas por errores de Alpenglow. El programa de recompensas de 50,000 SOL que se cierra antes del lanzamiento de Agave 4.3 producirá hallazgos de seguridad públicos que informarán si el cambio de consenso de octubre procede según lo programado.
• Trayectoria de la participación de Firedancer. La diversidad de clientes es un requisito previo para el perfil de riesgo de estas actualizaciones. Si la participación del 14% de Firedancer crece hacia el 33%, el umbral ampliamente considerado necesario para una resiliencia significativa, importa para la seguridad de la red durante la transición.

Preguntas frecuentes