Solana lleva la actualización de consenso Alpenglow a la testnet pública

Solana ha comenzado a desplegar su actualización de consenso Alpenglow en la testnet pública, un hito que abre el cambio a la comunidad más amplia de validadores de la red antes de un rediseño destinado a reducir la finalidad de las transacciones a una fracción de su duración actual.

Anza, la firma de desarrollo detrás del cliente de validación Agave, publicó Agave v4.3.0 el 18 de septiembre como una versión estable que considera adecuada para testnet, devnet y mainnet beta. Tras enviar primero la versión a operadores que controlaban el 10% y luego el 25% del SOL en staking, Anza instruyó a todos los validadores de mainnet a ejecutar la versión el 21 de septiembre. La actualización figura entre las más trascendentes de Solana en años: busca acortar la finalidad de aproximadamente 12,8 segundos a unos 150 milisegundos.

Cómo cambia el modelo de consenso

La finalidad es el punto en el que una transacción ya no puede revertirse. Es la condición que los exchanges esperan antes de acreditar depósitos y que los puentes esperan antes de liberar fondos. Reducir esa espera de segundos a milisegundos acorta directamente la retención de depósitos y transferencias entre cadenas.

Actualmente, Solana alcanza la finalidad mediante TowerBFT, que apila los votos de los validadores registrados on-chain a lo largo de 32 slots antes de considerar asentado un bloque. Alpenglow reemplaza ese mecanismo por Votor, un protocolo en el que los validadores transmiten votos directamente entre sí y pueden ponerse de acuerdo sobre un bloque en una o dos rondas. Eliminar la prolongada cadena de votación on-chain, que representa la mayor parte del retraso, reduce la espera a unos 150 milisegundos.

Un camino escalonado hacia la red principal

El nuevo código se ha ejecutado durante más de cuatro meses en una red separada y más pequeña configurada específicamente para la actualización. Trasladarlo a la testnet pública de Solana, donde los tokens no tienen valor real, pone a prueba si el conjunto completo de computadoras y servicios que ya operan la cadena puede migrar de manera coordinada.

El 28 de septiembre figura en el calendario de Anza como fecha tentativa para habilitar las funciones de Agave 4.3 en la red principal. Anza no ha confirmado un lanzamiento, y su tablero de seguimiento todavía marcaba como pendiente el propio cambio a testnet el miércoles por la mañana. A partir de aquí, los indicadores a seguir son que el tablero elimine su estado pendiente y si Anza confirma el 28 de septiembre como fecha de habilitación.

Preparación de los clientes y qué cambia para los usuarios

Las aplicaciones seguirán procesando transacciones como lo hacen ahora, y los holders no necesitan cambiar de billetera ni la forma en que mueven sus fondos.

La primera migración de Alpenglow se ejecutará íntegramente a través de Agave, porque Firedancer y Frankendancer, los dos clientes de validación alternativos desarrollados por Jump Crypto, aún no son compatibles con la prueba. Esas alternativas existen para reducir la dependencia de Solana de una única de código, de modo que un error en Agave no afecte a todos los validadores a la vez. Su ausencia deja la primera migración concentrada en una sola base de código, justamente la dependencia que los clientes alternativos fueron creados para aliviar.

El cambio sigue a una serie constante de mejoras en la red, que van desde un tamaño máximo de transacción mayor hasta tiempos de slot más rápidos en la testnet. Alpenglow llega más a fondo: en lugar de ajustar límites o tiempos, reemplaza el mecanismo mediante el cual la red asienta los bloques.