Solana ha llevado su actualización de consenso Alpenglow hacia el 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 alrededor de 150 milisegundos.
Resumen
- La actualización Alpenglow de Solana se traslada a la testnet pública con el objetivo de reducir la finalidad de las transacciones de aproximadamente 13 segundos a alrededor de 150 milisegundos.
- Alpenglow reemplaza TowerBFT con Votor, permitiendo a los validadores alcanzar un acuerdo mediante una o dos rondas de votación directa.
- Se requiere Agave 4.3 para la prueba, mientras que Firedancer y Frankendancer aún no admiten Alpenglow.
- El 28 de septiembre está listado para la activación tentativa de la función Agave 4.3 en la mainnet, pero no es una fecha de lanzamiento confirmada de Alpenglow.
Según github, la etapa de testnet permitirá a los desarrolladores probar la migración en el entorno de pruebas establecido de Solana antes de que el sistema de consenso pueda ser considerado para la red principal.
La finalidad se refiere al punto en que una transacción se vuelve irreversible bajo 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.
Solana actualmente depende de TowerBFT para el consenso, con los validadores registrando votos en la cadena 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 un acuerdo después de una o dos rondas de votación. El cambio elimina la secuencia más larga de votos de consenso en la cadena requerida bajo TowerBFT mientras deja la ejecución de transacciones en gran medida sin cambios para aplicaciones y usuarios.
Solana Alpenglow pasa a la testnet pública
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. Mover la actualización a la testnet pública establecida de Solana la expone a un grupo más grande 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 los fondos de la mainnet.
Anza trasladó por primera vez Alpenglow a las pruebas de validadores comunitarios en mayo, describiendo la actualización como el mayor cambio de consenso en la historia de Solana. Como crypto.news informó anteriormente, el clúster comunitario permitió a los operadores de validadores probar el nuevo diseño de consenso antes del despliegue en toda 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 dependiendo de la participación de los validadores. Especificaciones anteriores indicaban que un bloque podría liquidarse después de una ronda cuando participa suficiente stake, mientras que una segunda ronda proporciona otra ruta hacia la finalidad bajo una participación menor.
El resultado esperado es una reducción drástica del tiempo de finalidad existente de Solana. Anza ha estimado una finalidad mediana de alrededor de 150 milisegundos, con simulaciones anteriores situándola tan baja como 100 milisegundos en condiciones favorables.
Los desarrolladores no han cambiado cómo las aplicaciones ejecutan transacciones como parte de la actualización. Los usuarios de billeteras continuarán enviando transacciones a través de las mismas interfaces, mientras que los principales cambios ocurren en cómo los validadores se comunican y acuerdan el estado permanente de la blockchain.
Agave 4.3 lleva el código de Alpenglow
Los validadores que participan en la prueba de Alpenglow necesitan ejecutar Agave 4.3, la última rama del software principal de validadores mantenido por Anza.
Anza recomendó Agave 4.3 para adopción general entre los validadores de la mainnet el 21 de septiembre. El despliegue había pasado previamente por etapas controladas, primero pidiendo a los operadores responsables del 10% del stake de la mainnet que actualizaran antes de expandir la recomendación al 25%.
El desarrollo de Alpenglow ha estado vinculado a los lanzamientos de Agave durante meses. En agosto, el objetivo de finalidad de 150 milisegundos se esperaba que llegara a través de Agave 4.3 después de que el código subyacente de Alpenglow ya se hubiera incluido para pruebas en la rama de software anterior.
La fecha del 28 de septiembre indicada en el calendario de Agave 4.3 de Anza se refiere a la reanudación tentativa de la activación de funciones de la mainnet. Anza declara que sus fechas de lanzamiento están sujetas a cambios, mientras que su rastreador de puertas de funciones aún listaba la activación de la testnet de Alpenglow como pendiente para el miércoles temprano.
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 mejoras de rendimiento de Solana han estado avanzando a través de calendarios de activación separados. La finalidad de las transacciones, la producción de slots y la capacidad de transacciones están controladas por diferentes cambios de red, aunque cada uno puede afectar la rapidez con la que las aplicaciones interactúan con Solana.
Solana ya ha reducido los tiempos de slot a 250 ms
Solana redujo recientemente su tiempo de slot objetivo 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 líder 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 aumentó la capacidad de procesamiento general en la misma proporción.
Una etapa final bajo SIMD-0525 tiene como objetivo slots de 200 milisegundos, lo que llevaría la red a cinco slots objetivo por segundo. Los desarrolladores no han establecido una fecha de activación en mainnet confirmada para esa etapa.
El tiempo de slot y la finalidad miden diferentes 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 llegan a un acuerdo de que un bloque es irreversible.
Solana comenzó la secuencia actual de reducciones de slots en agosto, cuando su objetivo cayó a 350 milisegundos desde la configuración de 400 milisegundos utilizada desde el lanzamiento de la red. SIMD-0525 estableció objetivos sucesivos de 350, 300, 250 y finalmente 200 milisegundos.
Alpenglow sigue un camino separado a través de SIMD-0326 y reemplaza TowerBFT con Votor en lugar de modificar la duración de los slots individuales.
Firedancer permanece fuera de la primera prueba de Alpenglow
Firedancer y Frankendancer, clientes validadores desarrollados por Jump Crypto, actualmente no admiten la prueba de Alpenglow, dejando la migración inicial dependiente de Agave.
La diversidad de clientes brinda 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 después de 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 sirve como una implementación híbrida que combina componentes de Firedancer con el software existente de Solana. Ninguna de las implementaciones figura como compatible con la función pendiente SIMD-0326 Alpenglow en el rastreador de puertas de funciones actual de Anza.
Agave 4.3 es, por lo tanto, el cliente compatible para la primera migración pública a la testnet. El rastreador de Anza lista Alpenglow como una activación pendiente en testnet bajo SIMD-0326, mientras que los campos de soporte para Firedancer y Frankendancer permanecen marcados como no disponibles.
