Solana ha avanzado su actualización de consenso Alpenglow hacia su despliegue en la testnet pública, mientras los desarrolladores se preparan para probar un diseño destinado a reducir la finalidad de las transacciones de aproximadamente 13 segundos a cerca de 150 milisegundos.
Según github, la etapa de testnet permitirá a los desarrolladores probar la migración en el entorno de pruebas ya establecido de Solana antes de que el sistema de consenso pueda ser considerado para la red principal.
La finalidad se refiere al momento en que una transacción se vuelve irreversible según las reglas de consenso de la red. Los exchanges normalmente esperan la finalidad antes de acreditar depósitos, mientras que los puentes blockchain la utilizan antes de liberar activos en otra red.
Actualmente, Solana depende de TowerBFT para el consenso, con validadores registrando votos onchain y acumulando suficientes votos a lo largo de 32 slots antes de que un bloque alcance la finalidad. Alpenglow reemplaza ese proceso con un protocolo llamado Votor, que permite a los validadores intercambiar votos directamente.
Bajo el nuevo diseño, los validadores pueden alcanzar consenso tras una o dos rondas de votación. El cambio elimina la secuencia más larga de votos de consenso onchain requerida bajo TowerBFT, mientras deja la ejecución de transacciones en gran medida sin cambios para aplicaciones y usuarios.
Alpenglow ya ha pasado más de cuatro meses operando en un clúster comunitario más pequeño creado específicamente para probar el sistema de consenso. Llevar la actualización a la testnet pública ya establecida de Solana la expone a un grupo más amplio de validadores, proveedores de infraestructura y servicios ya conectados a la red.
La testnet pública utiliza tokens sin valor monetario, lo que permite a los desarrolladores reiniciar la red, probar procedimientos de migración e investigar problemas sin poner en riesgo fondos de mainnet.
Anza llevó por primera vez Alpenglow a pruebas comunitarias de validadores en mayo, describiendo la actualización como el mayor cambio de consenso en la historia de Solana. Como informó anteriormente crypto.news, el clúster comunitario permitió a los operadores de validadores probar el nuevo diseño de consenso antes de su despliegue en la infraestructura de pruebas existente de Solana.
Votor está diseñado para alcanzar la finalidad a través de una de dos rutas de votación según la participación de los validadores. Especificaciones anteriores indicaban que un bloque podía confirmarse tras una ronda cuando participaba suficiente stake, mientras que una segunda ronda ofrece otra vía hacia la finalidad con menor participación.
El resultado esperado es una reducción drástica frente al tiempo de finalidad actual de Solana. Anza ha estimado una finalidad mediana de alrededor de 150 milisegundos, y simulaciones anteriores la situaban en apenas 100 milisegundos en condiciones favorables.
Los desarrolladores no han cambiado la forma en que las aplicaciones ejecutan transacciones como parte de la actualización. Los usuarios de wallets seguirán enviando transacciones mediante las mismas interfaces, mientras que los principales cambios se producen en cómo los validadores se comunican y acuerdan el estado permanente de la blockchain.
Los validadores que participen en la prueba de Alpenglow deben ejecutar Agave 4.3, la rama más reciente del software principal de validadores mantenido por Anza.
Anza recomendó Agave 4.3 para adopción general entre los validadores de mainnet el 21 de septiembre. El despliegue había avanzado previamente por etapas controladas, primero pidiendo a los operadores responsables del 10% del stake de mainnet que actualizaran antes de ampliar la recomendación al 25%.
El desarrollo de Alpenglow ha estado vinculado a los lanzamientos de Agave durante meses. En agosto, se esperaba que el objetivo de finalidad de 150 milisegundos llegara a través de Agave 4.3 después de que el código subyacente de Alpenglow ya hubiera sido incluido para pruebas en la rama anterior del software.
La fecha del 28 de septiembre que figura en el calendario de Agave 4.3 de Anza se refiere a la reanudación tentativa de la activación de funciones en mainnet. Anza afirma que sus fechas de lanzamiento están sujetas a cambios, mientras que su rastreador de feature gates seguía mostrando la activación de Alpenglow en testnet como pendiente a primera hora del miércoles.
Por lo tanto, el 28 de septiembre no representa una fecha confirmada para que Alpenglow comience a operar en la mainnet de Solana.
La distinción surge mientras varias actualizaciones de rendimiento de Solana avanzan con calendarios de activación separados. La finalidad de las transacciones, la producción de slots y la capacidad de transacciones están controladas por cambios distintos en la red, aunque cada uno puede afectar la rapidez con la que las aplicaciones interactúan con Solana.
Recientemente, Solana redujo su tiempo objetivo de slot de 300 milisegundos a 250 milisegundos bajo SIMD-0525, llevando la red a un objetivo de cuatro slots por segundo.
La actualización de slot de 250 milisegundos redujo la ventana de liderazgo de cuatro slots de cada validador de 1,2 segundos a un segundo. Los límites de procesamiento de la red se ajustaron junto con los slots más cortos, lo que significa que el cambio no elevó la capacidad general de procesamiento en la misma proporción.
Una etapa final bajo SIMD-0525 apunta a slots de 200 milisegundos, lo que llevaría a la red a cinco slots objetivo por segundo. Los desarrolladores no han fijado una fecha confirmada de activación en mainnet para esa etapa.
El tiempo de slot y la finalidad miden distintas partes de la red. El tiempo de slot determina con qué frecuencia Solana puede producir nuevos slots, mientras que Alpenglow cambia cómo los validadores alcanzan consenso sobre que un bloque es irreversible.
Solana comenzó la secuencia actual de reducciones de slot en agosto, cuando su objetivo cayó a 350 milisegundos desde la configuración de 400 milisegundos usada desde el lanzamiento de la red. SIMD-0525 estableció objetivos sucesivos de 350, 300, 250 y eventualmente 200 milisegundos.
Alpenglow sigue una ruta separada a través de SIMD-0326 y reemplaza TowerBFT por Votor en lugar de modificar la duración de los slots individuales.
Firedancer y Frankendancer, clientes validador desarrollados por Jump Crypto, actualmente no son compatibles con la prueba de Alpenglow, dejando la migración inicial dependiente de Agave.
La diversidad de clientes ofrece a los validadores de Solana diferentes implementaciones de software para participar en la misma red. Si hay clientes separados disponibles, una falla de software que afecte a una implementación no necesariamente afecta a todos los validadores.
Firedancer comenzó a producir bloques en mainnet a principios de este año tras años de desarrollo por parte de Jump Crypto. El equipo recomendó inicialmente un despliegue gradual mientras continuaban las auditorías de seguridad, con el cliente construido de forma independiente destinado a reducir la dependencia de las implementaciones de validadores existentes de Solana.
Frankendancer funciona como una implementación híbrida que combina componentes de Firedancer con software existente de Solana. Ninguna de las dos implementaciones figura como compatible con la función pendiente de Alpenglow bajo SIMD-0326 en el rastreador actual de feature gates de Anza.
Por lo tanto, Agave 4.3 es el cliente compatible para la primera migración a la testnet pública. El rastreador de Anza enumera a Alpenglow como una activación pendiente en testnet bajo SIMD-0326, mientras que los campos de compatibilidad para Firedancer y Frankendancer siguen marcados como no disponibles.
ETH
SOL