Solana se prepara para poner a prueba en su testnet pública un objetivo de finalidad dramáticamente más rápido. Anza, el estudio de desarrollo detrás del cliente de validador Agave, colocó a Alpenglow bajo "Pending Testnet Activation" en su feature-gate tracker oficial, actualizado el 22 de septiembre. El registro significa que la función ahora espera la activación en testnet pública, sin que se haya publicado ninguna época de activación hasta el momento.

La entrada identifica la función como "SIMD-0326: Alpenglow: new consensus algorithm" y la asigna a Agave v4.3.0. Los campos correspondientes a la época de activación en testnet y a la fecha de activación permanecen vacíos. Agave v4.3.0 también figura como el próximo piso de versión esperado para la testnet, es decir, la versión de software más antigua que los validadores pueden ejecutar manteniendo la compatibilidad con esa red. Anza describe su calendario como tentativo, por lo que el registro no garantiza una fecha de activación.

Qué mide realmente el objetivo de 150ms

Según la documentación oficial de actualizaciones de Solana, Alpenglow tiene como objetivo reducir la finalidad de aproximadamente 12,8 segundos a alrededor de 150 milisegundos. De lograrse, la finalidad sería unas 85 veces más rápida.

La finalidad es el punto en el que los validadores han alcanzado suficiente acuerdo para que un bloque se considere irreversible. No es simplemente el momento en que una transacción aparece por primera vez en la red. Hoy, una aplicación puede ver una transacción de Solana como "confirmada" antes de que reciba el estado más fuerte de "finalizada" de la red. Alpenglow está diseñado para hacer converger esas dos etapas, porque un certificado de finalización llegar aproximadamente en el período que hoy se asocia a una confirmación inicial.

Tres relojes pueden regir un pago

• Ejecución: la transacción se procesa y aparece inicialmente en un bloque.
• Finalidad del protocolo: los validadores establecen que el bloque ya no debe revertirse.
• Liberación del servicio: un exchange, bridge o comercio decide cuándo acreditar el depósito, liberar activos o completar el pedido.

Alpenglow acortaría el segundo reloj. Cada negocio seguiría controlando el tercero, lo que significa que un objetivo de protocolo de 150ms no garantizaría que cada pago dirigido al cliente se complete en 150 milisegundos.

Cómo Alpenglow cambia el consenso de Solana

La primera etapa de Alpenglow introduce Votor, un reemplazo del proceso de votación utilizado por el sistema de consenso TowerBFT actual de Solana. Actualmente, los validadores envían votos como transacciones y construyen la finalidad a lo largo de una secuencia de slots. Con Votor, intercambiarían votos directamente y los combinarían en certificados que demuestran que suficiente stake ha aprobado un bloque.

Un bloque podría finalizarse después de una ronda de votación cuando la participación llega rápidamente. Una segunda ronda estaría disponible cuando las condiciones de la red impidan la vía más rápida.

🚨 Testnet operators: Alpenglow activation on testnet only runs on Agave. If you're on Firedancer or Frankendancer today, switch over to an Agave node before the migration window so your stake counts toward activation. Details in the thread below 👇

— Anza (@anza_xyz) September 22, 2026

La actualización no cambia cómo se ejecutan los contratos inteligentes, cómo se calculan los saldos ni cómo los usuarios envían transacciones ordinarias. Cambia la forma en que los validadores acuerdan que el bloque resultante es final.

Solana también ha estado cambiando lo que pueden contener las transacciones. Su reciente aumento del tamaño máximo de transacción creó más espacio para firmas, instrucciones y pruebas. Esa actualización cambia qué cabe dentro de una transacción; Alpenglow cambia qué tan rápido la red puede considerarla irreversible.

Dónde podría marcar la diferencia una finalidad más rápida

• Exchanges: una plataforma podría acreditar antes un depósito de Solana, aunque las verificaciones de identidad, el escaneo de wallets y los controles internos de riesgo aún podrían retrasar el acceso a los fondos.
• Bridges: un bridge podría verificar antes el lado de Solana de una transferencia, pero sus relayers y la blockchain de destino seguirían operando en líneas de tiempo separadas.
• Comercios: si la finalidad de la blockchain es la parte más lenta del proceso de pago, un procesador de pagos podría confirmar antes un pago irreversible y comenzar a cumplir el pedido.

La mejora sería más visible donde un servicio actualmente espera la garantía deación más fuerte de Solana. Tendría menos efecto cuando las verificaciones de cumplimiento, otra blockchain o un sistema de pago fuera de la cadena ya causan el mayor retraso.

La activación registrada actualmente solo es compatible con Agave

Solana puede operarse mediante clientes de validador desarrollados de forma independiente. Agave es mantenido por Anza, mientras que Firedancer y Frankendancer ofrecen implementaciones alternativas. La entrada actual de Alpenglow asigna la función a Agave v4.3.0 y marca tanto a Firedancer como a Frankendancer como no compatibles.

La entrada describe el feature gate pendiente de testnet; no establece qué clientes admitirán Alpenglow para cuando se considere cualquier activación en mainnet. En el registro no aparece ninguna fecha para añadir soporte a ninguno de los clientes alternativos. Por lo tanto, su disponibilidad sigue siendo una cuestión abierta de despliegue y no una evidencia de que hayan sido excluidos de forma permanente.

Qué debe demostrar la activación en testnet

• Migración: ¿pueden los validadores cambiar de sistema de consenso sin interrumpir la producción de bloques?
• Velocidad observada: ¿la finalidad medida se acerca a 150ms en lugar de simplemente cumplir el objetivo en pruebas controladas?
• Retrasos de red: ¿se mantiene confiable la finalidad cuando los validadores o las conexiones a internet responden con lentitud?
• Entrega de infraestructura: ¿los proveedores de RPC y los indexadores reciben los nuevos datos de finalidad de forma rápida y consistente?
• Preparación de clientes: ¿cuándo podrán implementaciones adicionales de validadores admitir el nuevo sistema de consenso?

La cifra de 150ms es una expectativa, no una constante. La documentación de Solana indica que la finalidad puede variar según la distribución del stake y si un bloque requiere una o dos rondas de votación. Algunas infraestructuras también pueden enterarse de que un bloque se finalizó más tarde que los validadores que produjeron directamente el certificado.

Incluso un resultado exitoso en testnet no garantizaría un rendimiento idéntico en mainnet. La participación de los validadores, la distribución del stake y el tráfico de red pueden diferir entre los dos entornos.

Una época de activación iniciará la prueba real

El próximo hito verificable será una época de activación publicada o un aviso oficial de que el feature gate se ha abierto. Los datos públicos de testnet podrán mostrar entonces qué tan cerca está Alpenglow de su objetivo y qué tan rápido la señal de finalidad resultante llega a las wallets y a la infraestructura.

Para las empresas de pagos, un acuerdo más rápido entre validadores solo es útil si reciben esa información con la suficiente rapidez como para cambiar cuándo se liberan los fondos. La época de activación iniciará esa prueba; por sí sola no resolverá la cuestión.

Este artículo se proporciona únicamente con fines informativos. Los calendarios de la red, el soporte de clientes de validador y la finalidad medida pueden cambiar a medida que avance la prueba.

Fuente: Solana Prepares to Test 150ms Final — Coindoo