La actualización Alpenglow de Solana ha llegado a su red pública de desarrolladores, permitiendo a los equipos de aplicaciones probar un sistema diseñado para reducir la finalidad de las transacciones de aproximadamente 12,8 segundos a unos 150 milisegundos.
Resumen
- Alpenglow está activo en la devnet y la testnet de Solana, mientras que la mainnet sigue utilizando el sistema de consenso actual.
- La actualización reemplaza las transacciones de voto de los validadores en la cadena por votos directos que pueden finalizar un bloque en una o dos rondas.
- Las aplicaciones que solo envían transacciones y leen saldos no necesitan migración, pero los servicios de datos de bloques deben actualizar sus sistemas.
- Anza no ha anunciado una fecha firme para la activación de Alpenglow en la mainnet.
Según la página de actualizaciones de la Fundación Solana, Alpenglow ahora está activo en devnet y testnet, pero no se ha activado en la mainnet. Anza, que desarrolla el software principal de validadores de Solana, anunció el cambio a devnet el 25 de septiembre, un día después de que la testnet completara su transición.
Las dos redes sirven a diferentes partes del despliegue. Los equipos de aplicaciones pueden usar devnet para comprobar cómo se comporta su software con tokens que no tienen valor real, mientras que la testnet ofrece a los validadores y operadores de infraestructura un lugar para probar el software de la red en condiciones más exigentes.
Para los desarrolladores, la nueva etapa de devnet significa que pueden probar aplicaciones con Alpenglow sin esperar a que el sistema llegue a la cadena de bloques que maneja los fondos de los usuarios. La mainnet de Solana sigue utilizando TowerBFT, por lo que la cifra de 150 milisegundos sigue siendo un objetivo para la actualización planificada en lugar de un tiempo de finalidad disponible para los usuarios hoy.
Alpenglow de Solana cambia cómo los validadores finalizan los bloques
Con TowerBFT, los validadores envían votos como transacciones que aparecen dentro de los bloques. Se deben acumular suficientes votos a lo largo de 32 slots antes de que un bloque sea final, lo que actualmente tarda unos 12,8 segundos, según la Fundación.
La primera fase de Alpenglow, llamada Votor, hace que los validadores envíen votos directamente entre sí. La Fundación afirma que un bloque puede alcanzar la finalidad después de una ronda de votación si los validadores que representan al menos el 80% del stake votan para aceptarlo. Una segunda ronda proporciona otra vía cuando la primera no alcanza ese umbral.
La finalidad es el punto en el que la red ha acordado una transacción con suficiente firmeza como para que ya no pueda revertirse según sus reglas de consenso. Un resultado más rápido podría importar a un exchange estadounidense que decide cuándo acreditar un depósito en Solana o a un proveedor de pagos que decide cuándo considerar completa la venta de un comerciante. Cada servicio aún puede aplicar sus propias verificaciones antes de liberar fondos o confirmar un pago a un cliente.
La Fundación separa la finalidad del tiempo que se tarda en producir un bloque. En septiembre, Solana redujo su tiempo de slot objetivo de 300 milisegundos a 250 milisegundos, con una reducción adicional a 200 milisegundos planificada bajo una actualización separada. Slots más cortos cambian la frecuencia con la que la red puede producirlos; Alpenglow cambia cómo los validadores acuerdan que un bloque es final.
Un informe anterior de crypto.news cubrió los preparativos de la testnet el 23 de septiembre, cuando los desarrolladores preparaban Agave 4.3 para la prueba pública. El paso a devnet ahora da a los equipos de aplicaciones acceso al sistema de consenso actualizado en la red que suelen usar para el desarrollo.
Los servicios de datos de bloques enfrentan cambios antes de la mainnet
Para una aplicación que envía transacciones y lee saldos de cuentas, la Fundación dice que Alpenglow no requiere migración. La ejecución de transacciones, las tarifas y los formatos utilizados para enviar transacciones siguen siendo los mismos bajo la actualización de consenso.
Los servicios que construyen historiales de transacciones tienen más trabajo por hacer. Alpenglow puede exponer bloques candidatos competidores para el mismo slot antes de que la red seleccione uno. La Fundación indica a los proveedores de datos que mantengan esos candidatos separados y luego conserven el bloque que alcanza la confirmación. Combinar transacciones de diferentes candidatos podría dejar a un explorador u otro servicio con un registro incorrecto.
Los votos de los validadores también desaparecerán de los bloques porque ya no se enviarán como transacciones. Como resultado, un gráfico que cuente tanto transacciones de usuarios como votos de validadores mostrará un total de transacciones menor después de la activación, incluso si los usuarios realizan la misma cantidad de pagos e intercambios. La Fundación ha dicho a los proveedores de datos que restablezcan las comparaciones y alertas construidas sobre las cifras antiguas.
Algunos servicios también leen la participación de los validadores a partir de transacciones de voto. Con Alpenglow, la Fundación afirma que esa información pasa a certificados adjuntos a los datos de bloque, lo que exige que esos servicios cambien el lugar donde la obtienen. Los operadores que utilizan los flujos de datos Geyser o gRPC de Solana también deben tener en cuenta los identificadores que distinguen los bloques candidatos dentro de una ranura.
Los cambios hacen que las pruebas en devnet sean relevantes para exchanges, exploradores y otras empresas que dependen de los registros de transacciones, incluidos los servicios estadounidenses conectados a Solana. Sus reglas de depósito siguen siendo su propia decisión operativa; la actualización de la red no cambia automáticamente cuándo una plataforma pone fondos a disposición.
La activación en la red principal aún no tiene fecha firme
La hoja de ruta anterior de Alpenglow de Solana vinculaba el despliegue propuesto en la red principal con Agave 4.3 y un objetivo para octubre. Ni la transición a la testnet ni la activación en devnet establecen una fecha confirmada para el cambio a la red en vivo.
El calendario de software de Anza permite tentativamente que las activaciones de funciones en la red principal se reanuden el 28 de septiembre. El calendario no identifica ese día como la fecha de activación de Alpenglow, y la página de estado de la Fundación todavía enumera la actualización como inactiva en la red principal.
La Fundación describe Votor como la primera fase de Alpenglow. Está prevista una fase posterior, Rotor, para reemplazar el sistema utilizado para difundir bloques por la red. El despliegue actual se refiere a los cambios de votación y finalidad, mientras que el objetivo de aproximadamente 150 milisegundos proviene de pruebas y simulaciones, no de transacciones liquidadas en condiciones de mercado en vivo.
