Solana define el cronograma de grandes actualizaciones con Transaction V1 y Alpenglow
Puntos clave
- •La actualización Transaction V1 de Solana se activa el 9 de septiembre y aumenta el tamaño máximo de transacción serializada de 1.232 bytes a 4.096 bytes, un incremento de aproximadamente 3,3 veces.
- •Solana iniciará la primera de cinco etapas de reducción de renta durante la semana que comienza el 31 de agosto, recortando eventualmente los requisitos de renta en un 90%, de 6.960 a 696 lamports por byte.
- •La red redujo su tiempo de slot objetivo de 400 a 350 milisegundos, con reducciones adicionales a 300, 250 y finalmente 200 milisegundos planificadas pero aún sin fecha.
- •El rediseño de consenso Alpenglow, que busca reemplazar Tower BFT y lograr una finalidad de aproximadamente 150 milisegundos, tiene como objetivo octubre, pero depende de las pruebas y el soporte de la red.
- •Cada actualización requiere una activación separada de los validadores, y los formatos de transacción heredados seguirán siendo válidos, con las aplicaciones optando por el formato más grande según lo necesiten.

Solana ha delineado un importante cronograma de actualizaciones, con Transaction V1 prevista para el 9 de septiembre y Alpenglow con objetivo de octubre, junto con reducciones de renta y tiempos de slot más rápidos en la hoja de ruta de la red. Transaction V1 ampliará el límite de tamaño de transacción de Solana a 4.096 bytes, cinco reducciones de renta planificadas podrían bajar los requisitos hasta en un 90%, y Alpenglow apunta a una finalidad de transacción de aproximadamente 150 milisegundos. La red se está preparando para varios cambios de protocolo que podrían ampliar la capacidad de transacción, reducir los costos de desarrollo y acelerar la finalidad. Sin embargo, cada actualización sigue un proceso y cronograma de activación separados.
La actualización Transaction V1 de Solana amplía la capacidad de transacción
La actualización Transaction V1 de Solana está programada para activarse el 9 de septiembre, según Jacob Creech, vicepresidente de tecnología de la Solana Foundation. La actualización aumentará el tamaño máximo de transacción serializada de los actuales 1.232 bytes a 4.096 bytes, un incremento de aproximadamente 3,3 veces.
Como resultado, los desarrolladores tendrán más espacio para operaciones on-chain complejas y aplicaciones con grandes volúmenes de datos. Los casos de uso potenciales incluyen pruebas de conocimiento cero, instrucciones multifirma, firmas BLS y transacciones entre cadenas. El límite de tamaño ha sido una restricción recurrente para estas categorías, ya que las pruebas y los esquemas de agregación de firmas con frecuencia superan el techo de 1.232 bytes, lo que a menudo obliga a los desarrolladores a dividir operaciones en múltiples transacciones.
Sin embargo, Transaction V1 no reemplazará los formatos de transacción existentes. Las transacciones heredadas y de versión cero seguirán siendo válidas, mientras que las aplicaciones deberán elegir explícitamente el formato más grande cuando lo necesiten.
Mientras tanto, Solana planea iniciar su primera etapa de reducción de renta durante la semana que comienza el 31 de agosto. La red ha delineado cinco etapas que podrían reducir los requisitos de renta en un 90%, de 6.960 a 696 lamports por byte. Creech expuso el cronograma de renta en X:
There are a lot of major changes happening soon
– Next week: First step down in rent reduction
– Sept 9: Transaction V1 goes live
– Dropping slot time even further
– October: Alpenglow
Then we all meetup at Scale or Die in NovemberSolana development will never be the same
— Jacob Creech (@jacobvcreech) August 29, 2026
Requisitos de renta más bajos podrían reducir la cantidad de SOL que los desarrolladores deben bloquear al crear cuentas y mantener el estado de las aplicaciones, haciendo que el despliegue de aplicaciones con grandes cantidades de cuentas sea menos intensivo en capital. La renta ha sido históricamente uno de los costos recurrentes citados por los equipos que construyen aplicaciones con muchas cuentas en Solana, y las reducciones escalonadas dan a los desarrolladores tiempo para observar cada paso en lugar de absorber un solo cambio de gran magnitud.
Alpenglow apunta a octubre mientras Solana acelera
Solana también ha reducido su tiempo de slot objetivo de 400 a 350 milisegundos. Están planificadas reducciones adicionales a 300, 250 y finalmente 200 milisegundos, aunque no se han anunciado fechas de activación específicas.
Estos cambios en el tiempo de slot son independientes de Transaction V1 y requerirán activaciones individuales de los validadores. Este enfoque permite a los operadores de la red evaluar el desempeño antes de adoptar objetivos de slot más rápidos en toda la red de Solana.
Alpenglow sigue con objetivo de octubre. El rediseño de consenso, presentado por primera vez por investigadores de la Solana Foundation y Anza en mayo de 2025, busca reemplazar la arquitectura de consenso Tower BFT existente de Solana con el objetivo de lograr una finalidad de transacción de aproximadamente 150 milisegundos — un cambio sustancial respecto a los tiempos de confirmación de varios segundos que la red ha entregado históricamente — lo que lo convierte en un cambio de protocolo más amplio que Transaction V1. Aun así, octubre sigue siendo un objetivo y no una fecha de activación garantizada en la mainnet, ya que aún son necesarias las pruebas y el soporte de la red.
En general, la hoja de ruta señala un período concentrado de desarrollo para Solana hasta finales de 2026. Las actualizaciones podrían fortalecer la flexibilidad de las transacciones, reducir los costos de las aplicaciones y mejorar el desempeño de confirmación. Para los desarrolladores y operadores de la red, los hitos cercanos a seguir son la primera reducción de renta en la semana del 31 de agosto, la activación de Transaction V1 el 9 de septiembre y la señalización de los validadores que determinará si Alpenglow llega a la mainnet en octubre.