Alpenglow de Solana: el relevo antes de una finalidad más rápida
Anza anuncia el 21 de octubre para la migración de Alpenglow a mainnet-beta. La clave está en el relevo: conservar un historial común antes de cambiar las reglas que lo hacen definitivo.
Ilustración conceptual generada con IA: dos operadores de señales se entregan el mismo bloque de registros entre sistemas de control. Representa la continuidad de un historial común, no personas reales ni un procedimiento manual de migración.
Puntos clave
- El 20 de octubre de 2026, la página oficial de Anza indicaba el 21 de octubre para mainnet-beta. Este artículo explica el plan anunciado; no informa de una migración ya completada.
- El diseño separa la activación de la función de un límite posterior de solo votos y establece el relevo con un certificado de génesis respaldado por al menos el 82% del stake.
- Votor cambia la votación y la finalidad. Rotor queda para una fase posterior; la mediana original de 150ms procedía de simulaciones, no de una garantía para cada transacción.
Cronología de los hechos
Anza introduce Votor y Rotor y explica las simulaciones que sustentan sus estimaciones de finalidad.
La página oficial de Anza marca testnet y devnet como completadas y muestra el 21 de octubre para mainnet-beta.
Fecha indicada por Anza a 20 de octubre. Una fecha programada no confirma que la transición haya ocurrido.
Antes de arrancar el nuevo motor
La página de Alpenglow de Anza ya muestra una fecha para la migración de Solana en mainnet-beta: el 21 de octubre. CoinYQ la consultó el 20 de octubre de 2026; testnet y devnet figuran como completadas. La finalización en mainnet sigue siendo un hecho que debe verificarse por separado. Antes de alcanzar la velocidad anunciada, los validadores necesitan cambiar las reglas del consenso sin dejar de compartir el historial que arrastran.[1]
Ese es el problema de SIMD-0384, la propuesta de migración. Su objetivo declarado es evitar revertir transacciones de usuarios confirmadas con TowerBFT. En la versión del repositorio consultada, tanto esta propuesta como la de Alpenglow aún llevan el estado «Review». Los documentos describen el diseño; la página actual de Anza aporta el calendario anunciado. Ninguno demuestra por sí solo la activación en mainnet.[2][3][1]
Un límite que deja de aceptar transacciones de usuarios
Según el procedimiento descrito, activar la función no cambia inmediatamente el consenso. El límite de migración se sitúa 5.000 slots después del slot de activación. A partir de ese límite, los bloques solo admiten transacciones simples de voto. También se suspenden las actualizaciones de compromiso de RPC y la fijación de raíces de TowerBFT. Así se abre un intervalo para acordar el relevo sin añadir transacciones ordinarias de usuarios a los bloques que podrían descartarse.[2]
Después, los validadores buscan un bloque situado en el límite o después de él cuyo hijo, en el slot inmediatamente siguiente, contenga votos a su favor de al menos el 82% del stake. Su ancestro más reciente anterior al límite pasa a ser candidato a génesis de Alpenglow. Un segundo acuerdo, mediante votos BLS de génesis que representen al menos el 82% del stake, forma el certificado de génesis. Este identifica el historial común desde el que arrancará el nuevo consenso.[2]
Un historial, otra forma de ponerse de acuerdo
Tras verificar el certificado, los validadores restablecen el estado en ese bloque de génesis, inician Votor y vuelven a admitir transacciones de usuarios. Los bloques iniciales de Alpenglow incluyen el certificado; reproducirlo también deja constancia de la migración en una cuenta on-chain. Hay, por tanto, algo más concreto que una cuenta atrás para comprobar el cambio. Anza espera un relevo de cientos de milisegundos, pero esa previsión no es una duración observada en mainnet.[2][1]
Los umbrales habituales de Votor son distintos del 82% de la migración. Una ronda puede finalizar un bloque con el 80% del stake; otra vía necesita dos rondas con el 60%. Ambas funcionan en paralelo. Los votos viajan directamente entre validadores y sus firmas pueden agregarse en certificados, en vez de exigir una transacción on-chain por cada voto de consenso. Cambia la forma de alcanzar un acuerdo, no solo la rapidez con que una cartera muestra una marca de confirmación.[3][4]
Lo que no resuelve la cifra de 150ms
La presentación original de mayo de 2025 estimaba una mediana de finalidad de unos 150 milisegundos. Aclaraba que se basaba en simulaciones con la distribución del stake de mainnet de entonces y sin contar el coste computacional. Una mediana no es un máximo. Y una latencia de consenso simulada no mide el recorrido completo de cada usuario por su cartera, servicio RPC y aplicación.[4]
El nombre Alpenglow también contiene una frontera de alcance. SIMD-0326 cubre Votor y conserva inicialmente Turbine para distribuir datos. Rotor, el sistema que lo sustituiría, queda excluido y requiere una propuesta posterior. La página actual de Anza también lo presenta como trabajo futuro. Leer la explicación original del rendimiento del protocolo completo como una promesa de que todos sus componentes llegan con esta migración borraría esa diferencia.[3][1][4]
Qué convertiría el plan en evidencia
Después de la fecha prevista, las preguntas útiles son concretas: ¿ha producido la red el certificado de migración y bloques finalizados con Alpenglow? ¿Qué muestran las mediciones con tráfico real? Lo primero establece el cambio de consenso; lo segundo contrasta el rendimiento. El diseño de migración describe pruebas para lo primero, mientras que el estudio original de rendimiento aporta una hipótesis que comparar con lo segundo.[2][4]
Por ahora, la noticia es una fecha oficial anunciada para mainnet-beta y un diseño público del relevo. La idea de fondo es que un acuerdo más rápido no puede partir de un pasado ambiguo. La transición de Alpenglow pide a los validadores fijar ese pasado común antes de confiar las decisiones futuras a Votor. Cumplir las expectativas de calendario y rendimiento sigue siendo algo que habrá que comprobar con los registros posteriores.[1][2][3]
Historias para seguir leyendo
Explora el tema a través de otros casos y contextos.
Fuentes y referencias
- [1]Fuente 1: Anza — Alpenglow launch and migration overviewAnzaConsultado 2026-10-20
- [2]Fuente 2: SIMD-0384 — Alpenglow migration, repository snapshotSolana Improvement DocumentsConsultado 2026-10-20
- [3]Fuente 3: SIMD-0326 — Alpenglow scope and votingSolana Improvement DocumentsConsultado 2026-10-20
- [4]Fuente 4: Alpenglow: A New Consensus for SolanaAnza · 2025-05-19Consultado 2026-10-20