Alpenglow y Firedancer apuntan a una finalidad de 100 a 150 milisegundos en Solana, frente a los 12,8 segundos que tarda hoy una transacción en volverse irreversible. Conviene decirlo pronto: es un objetivo de diseño, no un dato ya conseguido. Ni el rediseño del consenso ni el segundo cliente validador han terminado su despliegue, y en el ecosistema nadie ha publicado todavía una fecha cerrada para verlo funcionando en producción.
Qué es la finalidad y por qué Solana tarda 12,8 segundos
Una transacción puede aparecer en un bloque y, aun así, ser reversible si la cadena se reorganiza. La finalidad es el punto exacto en el que eso deja de ser posible: cuando el pago ya es del receptor sin billete de vuelta. Solana maneja tres niveles de confirmación. El primero, processed, es casi inmediato. El segundo, confirmado, ronda los 400 milisegundos. El tercero, finalizado, exige el respaldo de 32 bloques consecutivos votados por la supermayoría de los validadores, y de ahí salen esos 12,8 segundos.
El cuello de botella no está en la ejecución. La red produce un bloque cada 400 milisegundos y es capaz de procesar miles de transacciones por segundo. El freno está en Tower BFT, el mecanismo de consenso heredado que ordena y confirma los votos, diseñado para la seguridad antes que para la inmediatez. Alpenglow propone reemplazarlo por otra arquitectura: una capa de votación que cierra el acuerdo en una o dos rondas, bautizada en la propuesta como Votor, y un sistema de propagación de bloques, Rotor, que reduce los viajes de ida y vuelta entre validadores.
Dicho de otro modo, no se trata de fabricar bloques más rápidos, sino de acortar el trámite que recorre un voto hasta volverse irrevocable. Si el objetivo se cumple, el salto es de dos órdenes de magnitud. Pasar de 12.800 milisegundos a 150 equivale a multiplicar por 85 la velocidad a la que un pago queda cerrado; bajar a 100, por 128. Las cuentas salen.
Firedancer, el segundo motor que reparte el riesgo
La otra pata tiene nombre propio. Firedancer es un cliente validador desarrollado desde cero por Jump Crypto, escrito en C++ y con una filosofía distinta a la del cliente oficial. Un cliente validador es el programa que ejecuta cada operador para participar en el consenso: si todos usan el mismo código y ese código tiene un fallo, la red entera tropieza a la vez. Hoy Agave, mantenido por Anza, concentra la práctica totalidad del stake, y ese es el riesgo estructural que Firedancer viene a romper.
El código está publicado en el repositorio oficial de Firedancer en GitHub, y su antecesor híbrido, Frankendancer, ya ha operado en mainnet combinando piezas de ambos clientes. La contribución no es solo de velocidad: es de tolerancia a fallos. Dos implementaciones independientes que llegan al mismo consenso significan que un error de software deja de ser un apagón y pasa a ser un incidente acotado. Para un operador que mueve millones en DeFi, la diferencia entre ‘la red se cae’ y ‘la red sigue’ no es abstracta.
La finalidad no se mide en milisegundos de folleto, sino en la certeza de que nadie puede deshacer un pago ya cobrado.
Ahí está el interés real del mercado. Los productos financieros tokenizados —acciones, deuda, fondos— necesitan algo más que transacciones baratas: necesitan que la liquidación sea definitiva antes de que un operador humano parpadee. Con 12,8 segundos, un sistema de pagos en punto de venta conserva una ventana incómoda. Con 150 milisegundos, esa ventana se parece más a la de una tarjeta.
Lo que ya hemos visto y lo que sigue sin resolverse
El ecosistema tiene memoria de lo que ocurre cuando la infraestructura falla. En septiembre de 2021, una avalancha de transacciones lanzadas por un bot durante el lanzamiento de un token dejó la red sin producir bloques durante horas. En junio de 2022, un fallo en la lógica de transacciones de una cuenta provocó un episodio parecido. Aquellos apagones son el origen político de todo esto: Firedancer se anunció en 2022 precisamente para que Solana dejara de depender de un único equipo de ingeniería.
El matiz importa. Alpenglow se canaliza a través del proceso de propuestas de mejora de la red, que puedes seguir en el repositorio público de las SIMD, y su despliegue completo es gradual. Firedancer, por su parte, depende de una sola empresa para mantener su implementación, algo que se parece bastante a lo que venía a corregir. Y el stake de Solana sigue concentrado: una minoría de operadores puede detener la cadena si se coordina, un problema de diseño que ni Alpenglow ni Firedancer resuelven por sí solos.
Hay además una incógnita que ningún anuncio aclara. Lograr 150 milisegundos en condiciones de laboratorio no es lo mismo que sostenerlos con miles de validadores repartidos por el mundo y latencia real mediante. La métrica que importará no será la del mejor caso, sino la del percentil 95 en una jornada de congestión. Otra cosa es probarlo.
Mientras tanto, el código de Agave sigue disponible para cualquiera que quiera auditar al cliente dominante en el repositorio de Anza en GitHub. La pregunta que queda abierta es sencilla y no tiene respuesta todavía: si la red alcanza esa finalidad de 150 milisegundos, qué aplicación financiera sería imposible hoy y viable entonces. La respuesta la pondrá el uso, no el anuncio.
