Solana casi se congela: un error de enrutamiento sacó de línea el 29% del stake de la red
Un error de enrutamiento en el proveedor Teraswitch dejó fuera de línea el 29% del stake de Solana, con finalidad retrasada y menor rendimiento, aunque la red evitó una detención total.
Haznos tu fuente preferida en Google
Un fallo de enrutamiento en la infraestructura del operador Teraswitch dejó fuera de línea cerca del 29% del stake de Solana, un incidente que empujó a la red al borde de una detención sin llegar a cruzar el umbral crítico. La red siguió produciendo bloques, pero la telemetría independiente registró finalidad retrasada y una caída pronunciada en el rendimiento durante el episodio.
El punto clave es cuán cerca estuvo Solana de un problema mayor. Solana requiere que al menos dos tercios del stake vote para confirmar la finalidad de los bloques. Cuando una porción significativa de validadores queda incomunicada, ese margen se estrecha. Con un 29% del stake desconectado, la red operó peligrosamente próxima al umbral en el que la finalidad se detiene por completo, aunque no lo alcanzó.
Cómo un error de enrutamiento sacó de línea el 29% del stake de Solana
Según el postmortem publicado por Teraswitch, el origen del incidente fue un único error de enrutamiento en su infraestructura de red. Ese fallo bastó para dejar incomunicada a una franja considerable de validadores que dependían del proveedor, cortando su capacidad de participar en el consenso.
La concentración es la parte incómoda del episodio. Que un solo operador aloje una fracción tan grande del stake convierte cualquier tropiezo técnico suyo en un riesgo para toda la cadena. No hizo falta un ataque ni un error en el propio protocolo de Solana: bastó una falla de infraestructura en un tercero para poner en jaque la finalidad.
El análisis técnico independiente de Metrika sobre el incidente documentó los efectos medibles: la finalidad se retrasó y el throughput —el volumen de transacciones procesadas por segundo— cayó con fuerza mientras la red intentaba avanzar con una porción reducida de validadores activos.
Por qué importa la finalidad y qué mostró la telemetría
La finalidad es la garantía de que un bloque confirmado ya no puede revertirse. En una cadena de alto rendimiento como Solana, retrasos en la finalidad significan que las aplicaciones que dependen de confirmaciones rápidas —intercambios, protocolos de préstamos, liquidaciones— operan con menos certeza sobre el estado real de la red.
Durante el incidente, la cadena mantuvo la producción de bloques, lo que evitó una parálisis total. Pero el margen fue estrecho. Si más validadores hubieran caído, Solana podría haber cruzado el umbral en el que la finalidad se detiene, un escenario que obligaría a una coordinación manual para reiniciar el consenso.
El contraste con episodios recientes en otras redes ayuda a dimensionar la gravedad. Casos como la caída de aelf, cuya blockchain estuvo detenida siete días y borró recompensas de staking de sus validadores, muestran lo que ocurre cuando una red cruza la línea que Solana logró esquivar esta vez.
El problema de fondo: dependencia de pocos proveedores
El episodio reabre una discusión recurrente sobre la descentralización real de las redes de prueba de participación. En teoría, miles de validadores distribuyen el poder de decisión. En la práctica, muchos de esos validadores se apoyan en un puñado de proveedores de infraestructura y centros de datos, lo que crea puntos únicos de falla que no aparecen en las métricas de descentralización más citadas.
Cuando el 29% del stake depende de la conectividad de un solo operador, la resistencia de la red frente a fallos técnicos es menor de lo que sugiere el número total de validadores. Es un riesgo que los desarrolladores de varias cadenas vienen señalando, pero que suele quedar en segundo plano hasta que un incidente lo expone.
Qué sigue para Solana tras el susto
Solana ha trabajado en los últimos años para mejorar la resiliencia de su red, después de una serie de interrupciones que afectaron su reputación entre 2021 y 2022. Este incidente, al mantenerse por debajo del umbral de detención, puede leerse como una señal de que esas mejoras funcionaron parcialmente: la red se dobló pero no se rompió.
Aun así, el episodio deja tareas pendientes. Reducir la concentración de stake en proveedores individuales, mejorar la redundancia de la infraestructura de validación y afinar los mecanismos de recuperación ante fallos de conectividad figuran entre las prioridades que la comunidad técnica deberá abordar.
Para los usuarios y desarrolladores que construyen sobre Solana, la lección es directa: la estabilidad de una cadena no depende solo de su código, sino también de la salud de la infraestructura que la sostiene. Un margen tan ajustado como el de este incidente es una advertencia difícil de ignorar.



