La actualización Alpenglow de Solana llega a devnet con un objetivo de finalización de 150 ms

La actualización Alpenglow de Solana ha llegado a su red de desarrolladores pública, permitiendo a los equipos de aplicaciones probar un sistema diseñado para reducir la finalización de transacciones de aproximadamente 12.8 segundos a aproximadamente 150 milisegundos.

Resumen

• Alpenglow está activo en devnet y testnet de Solana, mientras que mainnet aún utiliza el sistema de consenso actual.
• La actualización reemplaza las transacciones de voto de validadores en cadena con votos directos que pueden finalizar un bloque en una o dos rondas.
• Las aplicaciones que solo envían transacciones y leen saldos no necesitan migrar, 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 mainnet.

Según la página de actualización de la Fundación Solana, Alpenglow ahora está activo en devnet y testnet, pero no ha sido activado en mainnet. Anza, que desarrolla el software de validadores central de Solana, anunció el cambio a devnet el 25 de septiembre, un día después de que testnet completara su transición.

Las dos redes sirven a diferentes partes del despliegue. Los equipos de aplicaciones pueden usar devnet para verificar cómo se comporta su software con tokens que no tienen valor real, mientras que testnet proporciona a los validadores y operadores de infraestructura un lugar para probar el software de la red bajo condiciones más exigentes.

Para los desarrolladores, la nueva etapa de devnet significa que pueden verificar aplicaciones contra Alpenglow sin esperar a que el sistema llegue a la cadena de bloques que maneja los fondos de los usuarios. La mainnet de Solana continúa 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 finalización disponible para los usuarios hoy.

Los cambios de Alpenglow en cómo los validadores finalizan bloques

Bajo TowerBFT, los validadores envían votos como transacciones que aparecen dentro de los bloques. Deben acumular suficientes votos a través de 32 espacios antes de que un bloque se vuelva final, lo que actualmente toma aproximadamente 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 dice que un bloque puede alcanzar la finalización después de una ronda de votación si los validadores que representan al menos el 80% de la participación votan para aceptarlo. Una segunda ronda proporciona otro camino cuando la primera no cumple con ese umbral.

La finalización es el punto en el que la red ha acordado una transacción con suficiente fuerza como para que ya no pueda ser revertida bajo sus reglas de consenso. Un resultado más rápido podría ser importante para un intercambio de EE. UU. que decide cuándo acreditar un depósito de Solana o para un proveedor de pagos que decide cuándo tratar la venta de un comerciante como completa. Cada servicio aún puede aplicar sus propios controles antes de liberar fondos o confirmar un pago a un cliente.

La Fundación separa la finalización del tiempo que lleva producir un bloque. En septiembre, Solana redujo su tiempo objetivo de espacio de 300 milisegundos a 250 milisegundos, con una reducción adicional a 200 milisegundos planificada bajo una actualización separada. Espacios más cortos cambian con qué frecuencia 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 movimiento a devnet ahora da a los equipos de aplicaciones acceso al sistema de consenso actualizado en la red que comúnmente utilizan para el desarrollo.

Los servicios de datos de bloques enfrentan cambios antes de 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, tarifas y los formatos utilizados para enviar transacciones permanecen iguales 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 espacio antes de que la red seleccione uno. La Fundación dice a los proveedores de datos que mantengan esos candidatos separados, luego retengan 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 cuenta tanto las transacciones de usuarios como los votos de validadores mostrará un total de transacciones más bajo después de la activación, incluso si los usuarios realizan el mismo número de pagos y operaciones. 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 de las transacciones de voto. Bajo Alpenglow, la Fundación dice que esa información se mueve a certificados adjuntos a los datos de bloques, lo que requiere que esos servicios cambien de dónde la obtienen. Los operadores que utilizan Geyser de Solana o flujos de datos gRPC también deben tener en cuenta los identificadores que distinguen los bloques candidatos dentro de un espacio.

Los cambios hacen que las pruebas en devnet sean relevantes para intercambios, exploradores y otras empresas que dependen de registros de transacciones, incluidos los servicios de EE. UU. 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 hace que los fondos estén disponibles.

La activación de mainnet aún no tiene fecha firme

La hoja de ruta anterior de Alpenglow de Solana vinculaba el despliegue propuesto de mainnet a Agave 4.3 y un objetivo de octubre. Ni la transición de testnet ni la activación de devnet establecen una fecha confirmada para el cambio de red en vivo.

El cronograma de software de Anza permite tentativamente que las activaciones de funciones de mainnet se reanuden el 28 de septiembre. El cronograma no identifica ese día como la fecha de activación de Alpenglow, y la página de estado de la Fundación aún lista la actualización como inactiva en mainnet.

La Fundación describe Votor como la primera fase de Alpenglow. Una fase posterior, Rotor, está planeada para reemplazar el sistema utilizado para distribuir bloques a través de la red. El despliegue actual se refiere a los cambios de votación y finalización, mientras que el objetivo de aproximadamente 150 milisegundos proviene de pruebas y simulaciones en lugar de transacciones liquidadas bajo condiciones de mercado en vivo.

Este contenido se ofrece únicamente con fines informativos generales y no constituye asesoramiento financiero, de inversión, legal ni fiscal. Cualquier evento, recompensa, promoción en línea o información relacionada que se mencione en el presente documento no debe considerarse como una recomendación, solicitud o invitación a comprar, vender, tradear o de negociar de otra manera con cualquier criptoactivo. Los criptoactivos son sumamente volátiles y pueden provocar pérdidas. La disponibilidad de los servicios, productos y eventos relacionados de WEEX puede variar según la región. Tienes la responsabilidad de asegurarte de que tu participación esté de acuerdo con las leyes y regulaciones locales vigentes.