La actualización Alpenglow de Solana ha llegado a su red pública para desarrolladores, lo que permite a los equipos de aplicaciones probar un sistema diseñado para reducir la finalidad de las transacciones de unos 12,8 segundos a aproximadamente 150 milisegundos.
Según la página de actualizaciones de la Solana Foundation, Alpenglow ya está activo en devnet y testnet, pero aún no ha sido activado en mainnet. Anza, que desarrolla el software central de validadores de Solana, anunció el cambio en devnet el 25 de septiembre, un día después de que testnet completara su transición.
Las dos redes cumplen funciones distintas dentro 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 testnet ofrece a validadores y operadores de infraestructura un entorno para probar el software de la red en condiciones más exigentes.
Para los desarrolladores, esta nueva etapa en devnet significa que pueden verificar sus aplicaciones frente a Alpenglow sin esperar a que el sistema llegue a la blockchain que maneja los fondos de los usuarios. El mainnet de Solana sigue usando TowerBFT, por lo que la cifra de 150 milisegundos sigue siendo un objetivo de la actualización prevista, y no un tiempo de finalidad disponible hoy para los usuarios.
Bajo TowerBFT, los validadores envían votos como transacciones que aparecen dentro de los bloques. Deben acumularse suficientes votos a lo largo de 32 slots antes de que un bloque sea final, lo que actualmente tarda alrededor de 12,8 segundos, según la Fundación.
La primera fase de Alpenglow, llamada Votor, hace que los validadores se envíen votos directamente entre sí. La Fundación afirma que un bloque puede alcanzar la finalidad tras una ronda de votación si validadores que representan al menos el 80% del stake votan por aceptarlo. Una segunda ronda ofrece 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 la suficiente solidez como para que ya no pueda revertirse bajo sus reglas de consenso. Un resultado más rápido podría ser relevante para un exchange de EE. UU. al decidir cuándo acreditar un depósito de Solana, o para un proveedor de pagos al decidir cuándo considerar completada una venta de un comercio. Cada servicio aún puede aplicar sus propias verificaciones antes de liberar fondos o confirmar un pago a un cliente.
La Fundación distingue entre finalidad y el tiempo que tarda en producirse un bloque. En septiembre, Solana redujo su objetivo de tiempo por slot de 300 milisegundos a 250 milisegundos, con una reducción adicional a 200 milisegundos prevista en una actualización aparte. Los 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 testnet el 23 de septiembre, cuando los desarrolladores estaban preparando 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 usan habitualmente para el desarrollo.
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 comisiones 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 en competencia para el mismo slot antes de que la red seleccione uno. La Fundación indica a los proveedores de datos que mantengan esos candidatos por separado y luego conserven el bloque que alcance la confirmación. Combinar transacciones de distintos 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 las transacciones de usuarios como los votos de validadores mostrará un total de transacciones más bajo tras la activación, incluso si los usuarios realizan la misma cantidad de pagos y operaciones. La Fundación ha indicado a los proveedores de datos que reinicien las comparaciones y alertas construidas sobre las cifras anteriores.
Algunos servicios también leen la participación de los validadores a partir de las transacciones de voto. Bajo Alpenglow, la Fundación dice que esa información pasa a certificados adjuntos a los datos del bloque, lo que exige que esos servicios cambien de dónde la obtienen. Los operadores que usan los flujos de datos Geyser o gRPC de Solana también deben tener en cuenta los identificadores que distinguen a los bloques candidatos dentro de un slot.
Estos cambios hacen que las pruebas en devnet sean relevantes para exchanges, exploradores y otras firmas que dependen de registros de transacciones, incluidos servicios en EE. UU. conectados a Solana. Sus reglas de depósito siguen siendo una decisión operativa propia; la actualización de la red no cambia automáticamente cuándo una plataforma pone fondos a disposición.
La hoja de ruta anterior de Alpenglow de Solana vinculaba el despliegue propuesto en mainnet a Agave 4.3 y a un objetivo para octubre. Ni la transición de testnet ni la activación en devnet establecen una fecha confirmada para el cambio en la red en vivo.
El calendario de software de Anza permite tentativamente que las activaciones de funciones en mainnet 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 sigue mostrando la actualización como inactiva en mainnet.
La Fundación describe a Votor como la primera fase de Alpenglow. Una fase posterior, Rotor, está prevista para reemplazar el sistema utilizado para propagar bloques a través de la red. El despliegue actual se refiere a los cambios en votación y finalidad, mientras que el objetivo de aproximadamente 150 milisegundos proviene de pruebas y simulaciones, más que de transacciones liquidadas en condiciones reales de mercado.
SOL