El cofundador de Solana, Anatoly Yakovenko, ha dicho que Alpenglow podría haberse lanzado en la mitad del tiempo mediante un cambio más simple en el programa de votación, antes de la migración de consenso del 21 de octubre que eliminará las transacciones de voto de los validadores de los bloques.
Resumen
- Yakovenko dijo que un cambio más simple en el programa de votación podría haber reducido a la mitad el tiempo de desarrollo de Alpenglow.
- Eliminar las transacciones de voto de los validadores reducirá los recuentos de TPS principales sin necesariamente cambiar la actividad de los usuarios.
- Una tarifa de admisión de 0,8 SOL quemada por época reemplazará las tarifas de votación individuales.
- Algunos nodos RPC podrían recibir actualizaciones de finalidad más tarde que el objetivo de 150 milisegundos de Alpenglow.
Yakovenko, en una publicación en X del 21 de octubre, hizo el comentario mientras citaba un comentario que celebraba la eliminación planificada de los votos en cadena y se burlaba de la crítica recurrente de que la mayoría de las transacciones por segundo de Solana consisten en votos de validadores.
"Alpenglow se habría lanzado en la mitad del tiempo si simplemente hubieran cambiado el programa de votación a la máquina de estados ag"
El diseño publicado de Anza describe un reemplazo para TowerBFT, el sistema que los validadores han utilizado para acordar bloques, con votación directa y certificados compactos.
La migración a la mainnet ha sido programada para el 21 de octubre, como crypto.news informó previamente al cubrir el traspaso de consenso planificado. La guía actualizada de la Fundación Solana identifica la época 1064 como el desencadenante y estima su inicio aproximadamente a las 13:20 UTC.
La página de migración de Anza separa la activación de la función del traspaso de consenso. El límite de migración llega 5.000 slots después, cuando los bloques llevan temporalmente solo votos mientras los validadores completan la transición.
Alpenglow elimina los votos de los recuentos principales de transacciones
La guía de migración de la Fundación Solana indica a los exploradores y servicios de análisis que restablezcan las líneas base de recuento de transacciones y TPS porque las transacciones de voto desaparecerán de los bloques. Un total que incluya votos caerá incluso si los pagos, operaciones y otras transacciones no relacionadas con votos permanecen sin cambios.
La Fundación dice que los servicios que rastrean la participación de los validadores deben reemplazar su lectura de las instrucciones del programa Vote con datos de certificados en los pies de bloque. Su guía señala que el mensaje de pie de página gRPC de Yellowstone aún no reenvía esos certificados.
Los desarrolladores tuvieron acceso al comportamiento modificado cuando Alpenglow llegó a devnet en septiembre, después de la transición de testnet. La cobertura del 26 de septiembre describió cómo los exploradores deben mantener separados los bloques candidatos competidores hasta la confirmación, conservando el bloque seleccionado en lugar de combinar sus transacciones.
La documentación para operadores de Anza explica cómo los plugins obtienen los metadatos de reemplazo. Agave 4.3 proporciona una notificación opcional de pie de bloque, que los servicios deben habilitar e implementar si necesitan datos del pie de página. Esas notificaciones conservan su ordenamiento relativo a las notificaciones de entrada.
Según la misma documentación, el reloj de la cadena mantiene su formato existente y precisión de segundos enteros. Durante la ejecución de transacciones, su marca de tiempo estima cuándo terminó el bloque padre, y se indica a los operadores que sigan tratando ese valor como aproximado.
Las tarifas de los validadores pasan a un cargo de época separado
La documentación de tarifas de la Fundación Solana dice que eliminar los votos en cadena pone fin a las tarifas pagadas en transacciones de voto individuales. Los validadores en su lugar pagan un cargo de admisión fijo de 0,8 SOL por época, con el monto total quemado.
El dinero proviene de la cuenta de voto, reemplazando a la cuenta de identidad como fuente de pagos relacionados con la votación. Los operadores deben mantener el cargo por encima del mínimo exento de renta de la cuenta, según la misma guía.
El pago se realiza con una época de anticipación. El primer cargo al inicio de la época 1064 cubre la participación en la época 1065, y un validador que no pueda pagar pierde el permiso para votar o producir bloques en la época siguiente.
La Fundación dice que el registro de clave pública BLS estuvo disponible en la mainnet el 8 de julio, mientras que la función de admisión se activó el 22 de julio. Esos cambios preparatorios no activaron por sí mismos el consenso Alpenglow.
Antes de la migración, su lista de verificación requiere la versión 4.3.2 de Agave, Jito-Solana o Harmonic Salsa. Firedancer y Frankendancer no son compatibles durante el traspaso, según las instrucciones para operadores de la Fundación.
Dos rutas de votación reemplazan a TowerBFT
Anza describe a Votor como la ejecución de dos rutas de votación al mismo tiempo. Una finaliza un bloque en una sola ronda con respuestas del 80% del stake, mientras que la segunda utiliza dos rondas y umbrales del 60%.
Los votos se convierten en mensajes directos firmados con criptografía BLS, lo que permite combinar múltiples firmas en un certificado compacto. Anza afirma que los validadores utilizan sus propios temporizadores para identificar a un líder que no responde y votar para omitirlo.
La propuesta publicada SIMD-0326 documenta las alternativas consideradas durante el desarrollo. Un diseño sin finalidad de una sola ronda ofrecía una operación más simple y una tolerancia a fallas bizantinas del 33%, pero sus autores enumeraron una peor latencia y una menor resiliencia ante caídas entre las desventajas.
Otra alternativa utilizaba un grafo acíclico dirigido, con posibles ahorros de ancho de banda. Los autores de la propuesta enumeraron la latencia y la dificultad para utilizar el ancho de banda en su totalidad entre sus inconvenientes.
La propuesta limita el conjunto admitido a 2.000 validadores, priorizando a los operadores con mayor stake. Sus autores explican que el límite ayuda a mantener los certificados lo suficientemente pequeños para un único mensaje UDP, mientras que los registros de participación respaldan las recompensas para los validadores que votan activamente.
La aprobación de la gobernanza precedió a la implementación. En septiembre de 2025, la propuesta Alpenglow se aprobó con 98,27% de apoyo entre los votos emitidos, mientras que el stake participante representó el 52% del total, según las cifras publicadas de la votación completada.
La entrega por RPC puede retrasarse respecto a la finalidad del consenso
La documentación para operadores de Anza matiza el objetivo de finalidad de aproximadamente 150 milisegundos al explicar que los nodos fuera del conjunto de validadores admitidos pueden recibir el resultado más tarde.
A través de la ruta predeterminada, esos nodos conocen la finalidad a partir de los certificados incluidos en un bloque posterior. Anza afirma que eso puede añadir hasta un intervalo de bloque producido, con esperas más largas cuando los bloques se omiten o se retrasan.
Un validador admitido puede enviar mensajes de consenso directamente a un nodo asociado, dejando la latencia de red entre los asociados como el principal retraso añadido. Si todos los asociados configurados se vuelven inaccesibles, el receptor recurre a conocer la finalidad a partir de los pies de bloque posteriores.
