El equipo de Anza ha comenzado la activación de Alpenglow en la red de prueba pública de Solana. La actualización, presentada en el marco de SIMD-0326, debería reemplazar el mecanismo de consenso actual basado en TowerBFT y Proof-of-History y reducir el tiempo objetivo de finalización de bloque de aproximadamente 12,8 segundos a 150 ms. La primera etapa será Votor, que forma parte de Agave 4.3 y cambia la forma en que los validadores intercambian votos. En lugar de votos en forma de transacciones separadas, los participantes de la red intercambiarán mensajes directamente y los combinarán en certificados con firmas BLS. En condiciones favorables, un bloque podrá alcanzar la finalización en una sola ronda de votación. Si esto no es suficiente, el protocolo pasará a una ronda adicional y utilizará otro tipo de certificado. Cabe señalar que los 150 ms declarados se refieren específicamente a la finalización, no a la duración del slot, que se regula mediante cambios separados en el protocolo.
Para los usuarios comunes, la transición no debería cambiar los parámetros básicos de funcionamiento de la red: Alpenglow no afecta el SVM, el formato de transacciones, las comisiones o el modelo de cuentas. Cambios más notables se esperan en los servicios que trabajan directamente con los datos de la blockchain. Agave 4.3 añade a los flujos Geyser y gRPC el identificador bank_id, que permite distinguir varios bancos candidatos dentro de un mismo slot. Por lo tanto, los indexadores, exploradores y otros sistemas de infraestructura deberán tener en cuenta el par slot y bank_id al almacenar eventos en búfer. Después de la implementación del nuevo consenso, la diferencia entre los estados confirmed y finalized debería reducirse significativamente. Ambos estados se mantendrán en la API por ahora, pero se planea eliminar confirmed posteriormente. Las transacciones de voto dejarán de incluirse en los bloques, y Proof-of-History ya no determinará el ritmo de su producción. Un mecanismo separado, Rotor, que debería reemplazar a Turbine para la distribución de datos, no está incluido en la versión actual de la actualización y se implementará más adelante.
La transición al nuevo consenso se realizará por etapas. Hasta el límite de migración, la red continuará utilizando TowerBFT, y después de la activación del feature gate se contarán 5000 slots. Luego, las transacciones de los usuarios dejarán de incluirse temporalmente en los bloques hasta que los validadores alcancen el estado necesario para el cambio. Una vez que aparezca un bloque con confirmación optimista del 82% del stake, su antecesor hasta el límite de migración se convertirá en el punto de partida de la nueva cadena. Los validadores reunirán el certificado BLS, revertirán los bloques más recientes y cambiarán el consenso a Votor, después de lo cual se reanudará el procesamiento de transacciones de usuarios. Antes del lanzamiento en la red de prueba pública, la migración se probó durante varios meses en un cluster comunitario separado. Luego, etapas similares deben ser completadas por la red de desarrolladores y la versión beta de la mainnet. Este orden está diseñado para preservar las operaciones ya confirmadas durante el cambio de mecanismo de consenso.