Solana enciende el 17 de agosto todo menos su gran cambio: Alpenglow viaja apagado dentro del código y lo que sí se activa es un alquiler un 90% más barato
El titular que circula desde el sábado dice que Solana está a punto de recibir "el mayor cambio de protocolo de su historia". La página oficial de la Solana Foundation dice otra cosa, y lo…
El titular que circula desde el sábado dice que Solana está a punto de recibir "el mayor cambio de protocolo de su historia". La página oficial de la Solana Foundation dice otra cosa, y lo dice en la misma frase en la que anuncia la fecha: Alpenglow no se activa en esta versión. El código viaja completo dentro de Agave 4.2, apagado, esperando a la siguiente release. Lo que de verdad se enciende a partir del 17 de agosto son tres cosas menos vistosas y bastante más inmediatas.
Anza, el equipo que mantiene el cliente validador de Solana, tiene Agave 4.2 recomendado para adopción en mainnet este mes, con las activaciones de features empezando la semana del 17 de agosto. En el paquete van una rebaja del 90% en el coste de guardar datos en cadena, transacciones que pasan de 1.232 a 4.096 bytes y una reducción del tiempo de slot de 400 a 200 milisegundos. Ninguna de las tres se enciende de golpe: las tres van por escalones, y al menos una lleva un interruptor para volver atrás.
Alpenglow entra en el código y sale en octubre
La distinción importa porque cambia qué se puede romper este mes. Según la nota de la Solana Foundation, 4.2 incluye todos los cambios de código necesarios para ejecutar Alpenglow, pero los ingenieros del núcleo lo seguirán probando en un clúster de test de la comunidad. La activación se espera en Agave 4.3, con objetivo en octubre de 2026. Es decir: los validadores que actualicen este mes ya llevarán el consenso nuevo encima, sin usarlo.
Alpenglow sustituye TowerBFT por un algoritmo de voto llamado Votor y apunta a una finalidad de unos 150 milisegundos frente a los 12,8 segundos que tarda hoy TowerBFT en dar un bloque por definitivo. El detalle más agresivo no es la cifra, es que elimina las transacciones de voto: los validadores se pasarán los votos directamente entre ellos en lugar de escribirlos en la cadena. El modelo de seguridad que la fundación describe tolera un 20% del stake caído más un 20% del stake actuando de mala fe.
El alquiler baja un 90% y eso es lo que se nota mañana
De los tres cambios que sí se activan, el de SIMD-0437 es el que más gente va a sentir sin enterarse. Recorta lamports_per_byte, la constante detrás del depósito reembolsable que hay que dejar para ocupar espacio en cadena, de 6.960 a 696. El depósito de una cuenta estándar de token SPL cae de unos 0,159 dólares a unos 0,0159.
Suena a calderilla y por eso es relevante: a ese precio, una empresa puede pagar el alquiler de cientos de miles de cuentas de sus usuarios sin que la partida aparezca en el presupuesto. Es la diferencia entre pedirle a alguien que llegue con saldo previo y abrirle la cuenta tú. El recorte no llega de una vez, va por cinco compuertas independientes para que los desarrolladores vigilen el crecimiento del estado en cada paso, y hay una compuerta de reserva que devuelve la constante al valor actual si algo se descontrola.
4.096 bytes: pruebas ZK y multifirmas en una sola transacción
SIMD-0296 sube el tamaño máximo de transacción de 1.232 a 4.096 bytes con un formato nuevo, la transacción v1. Los formatos v0 y legacy siguen funcionando igual y las aplicaciones se pasan al nuevo cuando quieren. Lo que cambia es qué cabe: pruebas de conocimiento cero, multifirmas grandes y esquemas de firma en cadena como BLS pueden aterrizar en una sola operación atómica en lugar de repartirse entre tablas de lookup y paquetes de transacciones.
Ese "atómica" es la parte que vale dinero. Una operación partida en tres transacciones tiene tres momentos en los que puede quedarse a medias y dejar el estado en una posición rara. Los indexadores, en cambio, tienen trabajo: quien decodifique bytes crudos de transacción tendrá que aprender el layout v1 o empezará a ver basura.
Medio segundo menos por bloque, con freno de mano
La reducción de slot de 400 a 200 milisegundos llega por SIMD-0525 en cuatro escalones de 50 milisegundos, cada uno en una época sucesiva. La condición que acordaron los validadores es explícita: la red no pasa al siguiente recorte si la tasa de bloques saltados está demasiado alta.
| Cambio | Antes | Después | Escalones |
|---|---|---|---|
| Alquiler (lamports/byte) | 6.960 | 696 | 5 + reserva |
| Tamaño de transacción | 1.232 B | 4.096 B | Opt-in v1 |
| Tiempo de slot | 400 ms | 200 ms | 4 de 50 ms |
| Finalidad (Alpenglow, 4.3) | 12,8 s | ~150 ms | Octubre |
La fundación vende el recorte como latencia, y lo es: confirmaciones al doble de velocidad, creadores de mercado cotizando spreads más estrechos. El argumento menos comentado es de resistencia a la censura. Cada líder tiene el monopolio de construir bloque durante su turno, y acortar el slot acorta ese monopolio. Combinado con la propuesta separada de reducir los slots consecutivos por líder, estrecha la ventana en la que un solo validador decide qué entra y qué no.
La otra cara: un calendario que ya se movió una vez
En mayo, Anatoly Yakovenko dijo en Consensus Miami que Alpenglow llegaría "el trimestre que viene". Estamos en agosto y lo que llega es el código apagado, con la activación apuntada a octubre. No es un fracaso, es lo normal en un cambio de consenso, pero conviene leer las fechas de este sector con esa constante de corrección incorporada. Los cuatro escalones del slot y las cinco compuertas del alquiler tienen la misma propiedad: si algo va mal, el calendario se estira.
Hay además una inconsistencia en la propia documentación que vale la pena tener delante. La ficha de Agave 4.2 marca la release como "sin cambios que rompan compatibilidad", mientras la ficha específica de la reducción de slots se marca a sí misma como cambio que sí rompe, con los cambios de indexación en "por determinar". Para un equipo que corre infraestructura sobre Solana, la respuesta útil está en la segunda ficha, no en el resumen.
El mercado, por su parte, no se ha inmutado. SOL cotiza sobre los 73 dólares con un movimiento de menos del 1% en 24 horas, en una semana en la que el bitcoin ronda los 63.400 y los ETF vienen de dos sesiones de salidas. Un upgrade escalonado, sin fecha de fuegos artificiales y con la parte llamativa desactivada, no da titular de precio. Que es más o menos como debería funcionar una actualización de infraestructura.
A qué estar atento
- La semana del 17 de agosto: cuántas de las compuertas se activan de verdad y en qué orden.
- La tasa de bloques saltados tras cada recorte de 50 ms. Es el freno acordado y el primer indicador de que el escalón siguiente se retrasa.
- Si alguna de las cinco compuertas del alquiler se para, o si se llega a usar la de reserva por crecimiento del estado.
- Adopción del formato v1: qué monederos e indexadores lo soportan antes de que las aplicaciones grandes empiecen a emitirlo.
- Los resultados del clúster de test comunitario con Alpenglow. De ahí sale, o no, la fecha de octubre para 4.3.
La lectura corta es que Solana está haciendo lo contrario de lo que se le suele reprochar. En lugar de encender el cambio grande y ver qué pasa, lo ha metido en el código con el interruptor bajado y ha dejado para este mes tres mejoras medibles, cada una con su manera de dar marcha atrás. El día que Alpenglow se active de verdad habrá titular. El 17 de agosto lo que hay es una cuenta de token que cuesta un céntimo y medio.
Datos: Solana Foundation (fichas de Agave 4.2, alquiler reducido y tiempos de slot reducidos), SIMD-0437, SIMD-0296 y SIMD-0525, calendario de release v4.2 de Anza, Bitfinex, CoinDesk, CoinGecko.