Solana activó Alpenglow en su red principal el 21 de octubre, un cambio de consenso que sustituye a TowerBFT y fija como objetivo reducir la finalización de las transacciones a unos 150 milisegundos. El protocolo también elimina la separación entre una operación confirmada y otra finalizada: ambas pasan a representar el mismo estado.
Un nuevo protocolo de consenso para Solana
La activación se produjo en el slot 459.653.000, el identificador técnico de la posición de la red en la que se ejecutó el cambio. Alpenglow reemplaza el mecanismo TowerBFT, hasta ahora utilizado por Solana para alcanzar el consenso entre los participantes de la cadena.
La principal meta anunciada para el nuevo diseño es una finalización cercana a los 150 milisegundos. La finalización es el momento en el que una operación deja de estar simplemente incluida o confirmada y pasa a considerarse irreversible dentro del protocolo.
Con Alpenglow, Solana equipara los conceptos de confirmación y finalización. El cambio busca simplificar el estado de las transacciones y reducir el tiempo que transcurre hasta que la red considera cerrado un registro.
La compensación bursátil también reduce las obligaciones de pago
El mismo contexto pone el foco en la operativa de los mercados tradicionales. En la Corporación Nacional de Compensación de Valores de Estados Unidos (NSCC), la compensación multilateral reduce el valor de las obligaciones de pago asociadas a las acciones.
Este mecanismo agrupa las operaciones de distintos participantes y compensa las posiciones que se deben entre sí, de modo que no es necesario mover el importe bruto de cada transacción. La fuente señala que la reducción se calcula como un promedio, aunque no especifica en el material disponible cuál es la cifra exacta.
La comparación apunta a dos formas distintas de hacer más eficiente la liquidación: Solana actúa sobre el tiempo necesario para cerrar las operaciones dentro de una red de cadena de bloques, mientras que la NSCC reduce el efectivo que debe desplazarse mediante la compensación de las obligaciones. En ambos casos, el objetivo descrito es limitar la fricción operativa, aunque se trata de sistemas con arquitecturas y funciones diferentes.
