Yakovenko de Solana cuestiona la construcción de Alpenglow mientras las transacciones de voto salen

El cofundador de Solana, Anatoly Yakovenko, ha afirmado que Alpenglow podría haberse entregado en la mitad del tiempo a través de 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.
• La eliminación de las transacciones de voto de los validadores disminuirá los conteos de TPS sin necesariamente cambiar la actividad del usuario.
• Una tarifa de admisión de 0.8 SOL quemada por época reemplazará las tarifas de votación individuales.
• Algunos nodos RPC pueden recibir actualizaciones de finalización más tarde que el objetivo de 150 milisegundos de Alpenglow.

Yakovenko, en una publicación de X del 21 de octubre, hizo el comentario mientras citaba un comentario que celebraba la eliminación planificada de los votos en cadena y burlándose 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 entregado en la mitad del tiempo si simplemente hubieran cambiado el programa de votación al estado de la máquina 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 de la red principal está programada para el 21 de octubre, como informó anteriormente crypto.news mientras cubría la entrega planificada del consenso. 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 funciones de la entrega del 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 votos de los conteos de transacciones principales

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 conteo de transacciones y TPS porque las transacciones de voto desaparecerán de los bloques. Un total que incluya votos caerá incluso si los pagos, intercambios y otras transacciones que no son de voto 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 de votación 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 cambiado 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 los bloques candidatos en competencia separados hasta la confirmación, reteniendo el bloque seleccionado en lugar de combinar sus transacciones.

La documentación del operador de Anza explica cómo los complementos 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 de pie de página. Esas notificaciones mantienen su orden relativo a las notificaciones de entrada.

Bajo la misma documentación, el reloj de la cadena mantiene su formato existente y precisión de segundos completos. 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 se trasladan a un cargo de época separado

La documentación de tarifas de la Fundación Solana dice que la eliminación de los votos en cadena termina con las tarifas pagadas en transacciones de voto individuales. En su lugar, los validadores pagan un cargo fijo de 0.8 SOL por época, con la totalidad del monto quemado.

El dinero proviene de la cuenta de voto, reemplazando 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 alquiler de la cuenta, según la misma guía.

El pago se realiza una época por adelantado. El primer cargo al inicio de la época 1064 cubre la participación en la época 1065, y un validador que no puede 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 se volvió disponible en la red principal 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 de 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 la transferencia, según las instrucciones del operador de la Fundación.

Dos caminos de votación reemplazan a TowerBFT

Anza describe a Votor como que ejecuta dos caminos de votación al mismo tiempo. Uno finaliza un bloque en una sola ronda con respuestas del 80% de la participación, mientras que el segundo 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 dice que los validadores utilizan sus propios temporizadores para identificar a un líder no respondedor y votar para omitirlo.

La propuesta SIMD-0326 publicada documenta las alternativas consideradas durante el desarrollo. Un diseño sin finalización de una sola ronda ofrecía una operación más simple y una tolerancia a fallos bizantinos del 33%, pero sus autores enumeraron una peor latencia y menor resistencia a fallos entre las desventajas.

Otra alternativa utilizó un grafo acíclico dirigido, con posibles ahorros de ancho de banda. Los autores de la propuesta enumeraron la latencia y la dificultad de utilizar completamente el ancho de banda entre sus desventajas.

La propuesta limita el conjunto admitido a 2,000 validadores, priorizando a los operadores con mayor participación. Sus autores explican que el límite ayuda a mantener los certificados lo suficientemente pequeños para un solo mensaje UDP, mientras que los registros de participación apoyan recompensas para los validadores que votan activamente.

La aprobación de gobernanza precedió a la implementación. En septiembre de 2025, la propuesta Alpenglow pasó con un 98.27% de apoyo entre los votos emitidos, mientras que la participación representó el 52% del total, según las cifras publicadas de la boleta completada.

La entrega de RPC puede retrasarse respecto a la finalización del consenso

La documentación del operador de Anza califica el objetivo de finalización de aproximadamente 150 milisegundos explicando que los nodos fuera del conjunto de validadores admitidos pueden recibir el resultado más tarde.

A través del camino predeterminado, esos nodos aprenden la finalización a partir de certificados incluidos en un bloque posterior. Anza dice que eso puede sumar hasta un intervalo de bloque producido, con esperas más largas cuando se omiten o retrasan bloques.

Un validador admitido puede enviar mensajes de consenso directamente a un nodo asociado, dejando la latencia de red entre los socios como el principal retraso añadido. Si cada socio configurado se vuelve inalcanzable, el destinatario vuelve a aprender la finalización a partir de los pies de bloque posteriores.