Historia completa de las interrupciones de Solana: causas, soluciones y lecciones aprendidas

Introducción

Como todos los sistemas distribuidos, Solana opera bajo una realidad: un solo error de implementación o un caso límite poco común puede provocar una falla en toda la red. Aunque causan trastornos, las interrupciones son una parte inevitable del mantenimiento de infraestructuras distribuidas complejas, ya sea en blockchains descentralizadas, exchanges centralizados o incluso grandes proveedores de servicios en la nube como Amazon o Microsoft.

La pregunta no es si ocurrirán fallas, sino cuándo y cómo evolucionará la red para adaptarse y reforzarse frente a futuros incidentes. A pesar de las rigurosas pruebas simuladas, una testnet con incentivos y un programa activo de recompensas por errores, ningún sistema, sin importar qué tan bien diseñado esté, puede anticipar todos los modos de falla posibles. Las lecciones más valiosas provienen de las operaciones en el mundo real.

Durante los últimos cinco años, Solana ha sufrido siete interrupciones distintas: cinco causadas por errores del cliente y dos por la incapacidad de la red para gestionar avalanchas de transacciones de spam. Las primeras versiones de Solana carecían de mecanismos clave para gestionar la congestión, como las tarifas de prioridad y los mercados locales de tarifas, que más tarde resultaron esenciales para mitigar la presión sobre la red. La falta de estos mecanismos provocó periodos prolongados de rendimiento degradado y congestión durante 2022, ya que la red básicamente incentivaba el spam.

Este artículo analizará en detalle cada interrupción de Solana, incluidas sus causas raíz, los eventos que la desencadenaron y las medidas tomadas para resolverla. También examinaremos los aspectos clave de los reinicios de red, los reportes de errores y los conceptos fundamentales de fallas de actividad y seguridad. Aunque lo ideal es leer estas secciones en orden, cada una está diseñada para entenderse por separado. Así, puedes ir directamente a los temas o incidentes que más te interesen.

Actividad y seguridad

Según el teorema CAP, también conocido como teorema de Brewer, un sistema distribuido solo puede lograr dos de estas tres propiedades:

• Consistencia - Cada lectura refleja todas las escrituras anteriores.
• Disponibilidad - Cada solicitud recibe una respuesta.
• Tolerancia a particiones - El sistema sigue funcionando a pesar de las particiones de red.

Para las blockchains, la tolerancia a particiones es esencial: las interrupciones de red son inevitables. Esto obliga a elegir entre AP (disponibilidad + tolerancia a particiones) y CP (consistencia + tolerancia a particiones). Como la mayoría de las cadenas PoS con finalización rápida, Solana prioriza la consistencia sobre la disponibilidad, por lo que es un sistema CP. Se detiene durante fallas críticas en lugar de entregar datos desactualizados o permitir escrituras inseguras. Aunque esto significa que el software de los nodos puede entrar en un estado irrecuperable que requiera intervención manual, también garantiza que los fondos de los usuarios permanezcan seguros.

Falla de actividad: ocurre cuando la blockchain deja de avanzar, lo que impide confirmar transacciones y producir bloques debido a la inactividad de validadores, particiones de red o bloqueos del consenso. En el contexto del teorema CAP, esto corresponde a una pérdida de disponibilidad.

Falla de seguridad: ocurre cuando el estado finalizado de la blockchain se modifica o bifurca de manera incorrecta. Esto puede generar historiales contradictorios o gastos dobles, a menudo debido a errores de consenso o ataques maliciosos. En el contexto del teorema CAP, esto corresponde a una pérdida de consistencia. 

Solana prioriza la seguridad sobre la actividad. Por eso, la red se detiene ante una presión extrema o una falla de consenso en lugar de arriesgarse a corromper el estado. Aunque las interrupciones causan trastornos y pueden afectar a aplicaciones, usuarios y validadores, son preferibles a las consecuencias catastróficas de un ledger inconsistente o corrupto.

Reinicios de la red

Reiniciar la red de Solana implica identificar el último slot de bloque confirmado de forma optimista y reiniciar los nodos desde una instantánea confiable del estado local de ese slot. Como el slot de reinicio no se determina on-chain, los operadores de validadores deben alcanzar un consenso off-chain para acordar un punto de reversión seguro. Esta coordinación ocurre públicamente en el canal #mb-validators del Discord de Solana Tech, donde los operadores profesionales de validadores se comunican en tiempo real. La mayoría cuenta con sistemas de alertas automatizados que les notifican en cuanto se detiene la producción de bloques, lo que permite responder con rapidez.

Una vez alcanzado el consenso sobre el slot de reinicio correcto, los operadores usan la herramienta de ledger para generar una nueva instantánea local, reiniciar sus validadores y esperar a que al menos el 80 % del stake total vuelva a estar en línea. Solo entonces la red reanuda la producción y validación de bloques. Verificar que como máximo el 20 % del stake esté fuera de línea cuando se reinicia el clúster garantiza un margen de seguridad suficiente para seguir operando si los nodos se bifurcan o vuelven a quedar fuera de línea inmediatamente después del reinicio.

Reporte de errores

Los programas de recompensas por errores premian a los investigadores de seguridad por identificar y reportar vulnerabilidades de software. Son una línea de defensa esencial, ya que ofrecen incentivos proactivos para detectar errores antes de que puedan explotarse. Se recomienda que los investigadores de seguridad y desarrolladores que identifiquen posibles vulnerabilidades en el cliente Agave las reporten mediante los canales de seguridad correspondientes. Puedes consultar las pautas detalladas de divulgación en el repositorio de Agave en GitHub. 

Se ofrecen recompensas por reportes válidos de vulnerabilidades críticas. Los pagos dependen de la gravedad:

• Pérdida de fondos: Hasta 25,000 SOL
• Infracciones de consenso o seguridad: Hasta 12,500 SOL
• Fallas de actividad o pérdida de disponibilidad: Hasta 5,000 SOL

Además, el cliente FireDancer tiene un programa independiente de recompensas por errores alojado en Immunefi, con una recompensa máxima de $500,000 USDC por hallazgos críticos.

Casos de interrupciones

Las siguientes secciones presentan un análisis cronológico y detallado de las interrupciones y los periodos de rendimiento degradado de Solana, desde el lanzamiento de Mainnet Beta el 16 de marzo de 2020. El análisis destacará los principales incidentes, sus causas raíz y las mejoras posteriores de la red. También mostrará cómo Solana ha evolucionado con el tiempo para mejorar su estabilidad y resiliencia.

Error de Turbine: diciembre de 2020

Tiempo de inactividad: Aproximadamente seis horas

Problema raíz: Error de propagación de bloques

Soluciones: 

• Rastrear bloques por hash en lugar de por número de slot
• Corregir los puntos de Turbine donde las fallas pueden detectarse antes
• Propagar la primera falla detectada a todos los validadores mediante gossip

Esta interrupción se debió a un problema ya conocido en la reparación de bloques y el procesamiento de código, desencadenado por un error no identificado en Turbine, el mecanismo de propagación de bloques de Solana. La falla ocurrió cuando un validador transmitió dos bloques distintos para el mismo slot y los propagó a dos particiones separadas (A y B), mientras una tercera partición detectaba la inconsistencia de forma independiente.

Como cada partición solo contenía una minoría del stake, ninguna pudo lograr el consenso de una supermayoría para hacer avanzar la cadena. El problema subyacente provenía de la forma en que las estructuras de datos internas de Solana rastreaban los bloques y su estado calculado. El sistema usaba el número de slot de Proof of History (PoH), un identificador u64, para hacer referencia al estado y al bloque de ese slot. Cuando la red se dividió en particiones, los nodos interpretaron erróneamente los bloques A y B como idénticos, lo que impidió su correcta reparación y sincronización.

Cada partición asumía que la otra tenía el mismo bloque, lo que provocó un conflicto fundamental:

• Los nodos que tenían el bloque A rechazaban las bifurcaciones derivadas del bloque B
• Los nodos que tenían el bloque B rechazaban las bifurcaciones derivadas del bloque A

Como las transiciones de estado diferían entre particiones, los validadores no podían reparar ni reconciliar las bifurcaciones, lo que impedía alcanzar la finalidad.

La solución para este problema fue permitir que los servicios rastrearan los bloques por hash en lugar de por número de slot. Si varios bloques del mismo slot crean particiones, se tratan igual que las particiones con bloques en slots distintos. Los nodos pueden reparar todas las bifurcaciones posibles y el consenso puede resolver las particiones.

Aunque el error fue la causa inicial de la interrupción, la mayor parte del tiempo de inactividad se debió a la espera hasta que regresara suficiente peso de stake, ya que Solana necesita al menos un 80 % de participación del stake para reanudar la producción de bloques.

La IDO de Grape Protocol: septiembre de 2021

Tiempo de inactividad: Diecisiete horas 

Problema raíz: Desbordamiento de memoria causado por transacciones de bots

Soluciones: 

• Ignorar los bloqueos de escritura en programas
• Límites de frecuencia para el reenvío de transacciones
• Comportamiento configurable de reintentos de RPC
• Priorización de transacciones de voto de la TPU

El 14 de septiembre de 2021, Solana sufrió una importante paralización de la red tras el lanzamiento de la oferta inicial de DEX (IDO) on-chain de Grape Protocol en la plataforma de financiamiento colectivo Raydium AcceleRaytor. Doce minutos después de comenzar la IDO, una avalancha sin precedentes de transacciones generadas por bots saturó la red, que dejó de producir slots arraigados. En la práctica, estos bots ejecutaron un ataque distribuido de denegación de servicio (DDoS) que elevó la carga de transacciones por encima de la capacidad de la red.

En el punto máximo de congestión:

• Algunos validadores recibían más de 300,000 transacciones por segundo.
• Los datos sin procesar de las transacciones superaban 1 Gbps, con 120,000 paquetes por segundo.
• En ocasiones, el tráfico superaba los límites físicos de las interfaces de red y provocaba pérdida de paquetes en el puerto del switch antes de que llegaran a los validadores.

Uno de los bots estructuró sus transacciones para bloquear la escritura de 18 cuentas clave, incluidos el programa global de tokens SPL y el programa ya descontinuado Serum DEX. Esto bloqueó todas las transacciones que interactuaban con esas cuentas y redujo drásticamente la capacidad de procesamiento paralelo de Solana. En lugar de ejecutar las transacciones de forma independiente, la red quedó limitada por un cuello de botella y comenzó a procesarlas secuencialmente, lo que agravó la congestión.

Ya se había desarrollado una solución que ignoraba los bloqueos de escritura en programas y estaba programada para publicarse. Posteriormente, el reinicio de la red permitió implementar esta actualización y eliminar de forma permanente este vector de ataque.

Durante la IDO, los validadores recibieron una avalancha de transacciones generadas por bots y reenviaron las transacciones excedentes al siguiente líder, lo que amplificó la congestión. El reinicio de la red introdujo límites de frecuencia para el reenvío de transacciones con el fin de evitar que futuras tormentas de transacciones saturaran a los líderes.

Los nodos RPC de Solana reintentan automáticamente las transacciones fallidas, una función diseñada para mejorar la confiabilidad. Sin embargo, bajo una congestión extrema, este mecanismo de reintentos agravó la avalancha de transacciones al mantener transacciones antiguas en circulación en lugar de permitir que la red se recuperara. Solana 1.8 introdujo un comportamiento configurable de reintentos de RPC, lo que permitió a las aplicaciones optimizar los reintentos con tiempos de expiración más cortos y estrategias de espera exponencial.

Bajo una congestión intensa, los líderes de Solana no lograron incluir las transacciones de voto, que son esenciales para mantener el consenso. Como resultado, la falta de votos confirmados paralizó el consenso y detuvo la producción de nuevos bloques raíz. Versiones posteriores del cliente de Solana introdujeron un mecanismo para priorizar las transacciones de voto y evitar que las transacciones normales las desplazaran en eventos futuros.

Un segundo error: desbordamiento de enteros

Durante el reinicio de la red apareció un segundo problema. Los validadores reportaron cantidades de stake activo que fluctuaban drásticamente. El problema provenía de un error que multiplicaba incorrectamente por 100 el porcentaje de stake, lo que excedía el valor máximo posible. El mecanismo de inflación había creado tantos tokens SOL nuevos que desbordó un entero sin signo de 64 bits. El error se identificó y corrigió rápidamente antes de un segundo reinicio.

Congestión elevada: enero de 2022

Tiempo de inactividad: Ninguno

Causa raíz: Exceso de transacciones duplicadas Solución parcial:

• Versiones 1.8.12 y 1.8.14 de Solana
• Optimización de la deduplicación de SigVerify
• Mejoras en el rendimiento de la caché del ejecutor

Entre el 6 y el 12 de enero de 2022, la mainnet de Solana sufrió una fuerte congestión que provocó un rendimiento degradado e interrupciones parciales. Los bots enviaban un exceso de transacciones duplicadas, lo que redujo significativamente la capacidad de la red. Los bloques tardaban más de lo esperado en procesarse, por lo que el siguiente líder se bifurcaba y reducía aún más el rendimiento. En el punto máximo, las tasas de éxito de las transacciones cayeron hasta un 70 %. El cliente tuvo dificultades para gestionar las transacciones cada vez más complejas y exigentes en cómputo, lo que dejó en evidencia sus limitaciones para satisfacer la demanda.

Entre el 21 y el 23 de enero se produjo inestabilidad adicional y la congestión continuó. El 22 de enero, el endpoint RPC público (https://api.mainnet-beta.solana.com) quedó fuera de línea debido a abusos, ya que las llamadas RPC por lotes enviadas como spam saturaron el sistema.

Para resolver estos problemas, la versión 1.8.12 de Solana abordó específicamente el agotamiento de la caché de programas, mientras que la versión 1.8.14 introdujo mejoras en la caché de Sysvar, el descarte de SigVerify y la deduplicación de SigVerify.

Spam de Candy Machine: abril/mayo de 2022 

Tiempo de inactividad: Ocho horas

Problema raíz: Spam de transacciones de cuentas de bots

Soluciones:

• Impuesto para bots en el programa Candy Machine
• Mejoras de memoria en Solana v1.10

El 30 de abril de 2022, Solana sufrió un aumento sin precedentes en las solicitudes de transacciones. Algunos nodos reportaron hasta seis millones de solicitudes por segundo, lo que generó más de 100 Gbps de tráfico por nodo. El aumento fue causado por bots que intentaban obtener NFT recién acuñados mediante el programa Metaplex Candy Machine. Este mecanismo de acuñación operaba por orden de llegada, lo que creaba un fuerte incentivo económico para inundar la red con transacciones y ganar la acuñación.

Cuando el volumen de transacciones se disparó, los validadores agotaron su memoria y fallaron, lo que terminó paralizando el consenso. El rendimiento insuficiente de los votos impidió finalizar bloques anteriores, por lo que no pudieron eliminarse las bifurcaciones abandonadas. Como resultado, los validadores quedaron saturados por la enorme cantidad de bifurcaciones que debían evaluar. Esto superó su capacidad incluso después de los reinicios y requirió intervención manual para restaurar la red.

Aunque esta interrupción tuvo similitudes con el incidente de septiembre de 2021, Solana demostró una mayor resiliencia. A pesar de recibir un 10,000 % más de solicitudes de transacciones que en la interrupción anterior, la red siguió funcionando durante mucho más tiempo. Esto reflejó las mejoras que la comunidad de validadores había implementado para responder a los desafíos de escalabilidad anteriores.

El reinicio de la red tardó menos de 1.5 horas después de acordarse la instantánea canónica. Solana v1.10 incluyó mejoras en el uso de memoria para prolongar el tiempo que los nodos pueden soportar un consenso lento o paralizado. 

Sin embargo, algunos problemas fundamentales seguían sin resolverse. El líder aún procesaba por orden de llegada las transacciones que competían por los mismos datos de cuenta, sin una prevención eficaz del spam. Esto impedía que los usuarios indicaran la urgencia de sus transacciones. Para resolverlo, se propusieron tres mecanismos a largo plazo como soluciones prácticas.

Adopción de QUIC: Anteriormente, Solana usaba el protocolo de red UDP (User Datagram Protocol) para enviar transacciones mediante Gulf Stream desde los nodos RPC hasta el líder actual. Aunque UDP es rápido y eficiente, no usa conexiones y carece de control de flujo y confirmaciones de recepción. Por eso, no existe una forma eficaz de desalentar o mitigar el comportamiento abusivo. Para controlar el tráfico de red, se volvió a implementar con QUIC el protocolo de recepción de transacciones del validador, es decir, la etapa Fetch de la TPU.

QUIC intenta ofrecer lo mejor de TCP y UDP. Facilita una comunicación rápida y asíncrona similar a UDP, pero con las sesiones seguras y las estrategias avanzadas de control de flujo de TCP. Esto permite limitar las fuentes individuales de tráfico para que la red pueda concentrarse en procesar transacciones legítimas. QUIC también incorpora flujos separados, por lo que descartar una transacción no bloquea las demás. QUIC se integró finalmente en el cliente de Solana Labs con la versión 1.13.4.

Calidad de servicio ponderada por stake (SWQoS): Se introdujo un nuevo sistema que prioriza el tráfico de red según el stake de los validadores, lo que permite que quienes tengan más stake envíen transacciones con mayor eficiencia. Con este mecanismo, un validador que tenga el 3 % del stake total puede enviar hasta el 3 % del total de paquetes al líder. SWQoS funciona como una medida de resistencia Sybil y dificulta que actores maliciosos inunden la red con transacciones de baja calidad. Este enfoque reemplaza el modelo anterior de orden de llegada, que aceptaba transacciones de manera indiscriminada sin considerar su origen.

Introducción de tarifas de prioridad: Una vez recibidas, las transacciones siguen compitiendo por acceder a datos de cuenta compartidos. Antes, esta contención se resolvía por orden de llegada, sin que los usuarios pudieran indicar la urgencia de sus transacciones. Como cualquiera puede enviar transacciones, la ponderación por stake no es adecuada para priorizarlas en esta etapa. Para solucionarlo, se añadió una nueva instrucción al programa Compute Budget que permite a los usuarios especificar una tarifa adicional, cobrada al ejecutar e incluir la transacción en un bloque. La relación entre la tarifa y las unidades de cómputo determina la prioridad de ejecución de una transacción, lo que garantiza un enfoque más dinámico y basado en el mercado para ordenar las transacciones.

Impuesto para bots de Candy Machine

Metaplex introdujo rápidamente un impuesto fijo para bots de 0.01 SOL sobre las transacciones de acuñación que interactuaban con el programa Candy Machine para combatir el spam generado por bots. Este mecanismo antispam imponía una tarifa mínima para desalentar la actividad maliciosa sin penalizar a los usuarios legítimos que cometieran errores accidentales. El impuesto se aplicaba en situaciones específicas, entre ellas:

• Intentar acuñar cuando Candy Machine no estaba activa
• Intentar acuñar cuando ya no quedaban artículos
• Transacciones donde acuñar o establecer la colección no era la instrucción final
• Usar un ID de colección incorrecto
• Instrucciones Set Collection que no coincidían
• Una discrepancia entre el firmante-pagador de las instrucciones para establecer la colección y acuñar
• Transacciones sospechosas que involucraban programas no permitidos
• Intentar acuñar desde una Candy Machine protegida por AllowList sin tener el token de allowlist requerido

Este factor económico disuasorio resultó muy eficaz. Los fondos de los bots de acuñación se agotaron rápidamente y la actividad de spam cesó. Durante los primeros días, sus operadores perdieron en conjunto más de 426 SOL.

Error de nonce duradero: junio de 2022 

Tiempo de inactividad: Cuatro horas y media

Problema raíz: Error de nonce duradero que provocó una falla de consenso 

Soluciones: 

• Desactivación temporal de las transacciones con nonce duradero
• Actualización Solana 1.10.23

Un error de runtime permitía procesar dos veces ciertas transacciones con nonce duradero: primero como una transacción normal y luego como una transacción con nonce, si usaban un blockhash reciente en lugar de un nonce duradero en el campo recent_blockhash. Esto provocó un comportamiento no determinista entre los validadores, ya que algunos nodos rechazaban la segunda ejecución y otros la aceptaban. Lo más importante es que, como más de un tercio de los validadores aceptaron el bloque, se impidió que la mayoría requerida de dos tercios alcanzara el consenso.

A diferencia de las transacciones estándar, las transacciones con nonce duradero no expiran y requieren un mecanismo único para impedir la doble ejecución. Se procesan en serie mediante un valor nonce on-chain asociado a cada cuenta, que se rota cada vez que se procesa una transacción con nonce duradero. Una vez rotado, la misma transacción con nonce no debería volver a ser válida.

Para mitigar el problema, se desactivaron temporalmente las transacciones con nonce duradero. Más tarde se implementó una solución en Solana 1.10.23 que impedía la ejecución duplicada al separar los dominios de nonce y blockhash. La actualización garantizó que, al avanzar las cuentas nonce, el blockhash se procesara mediante hash junto con una cadena fija, lo que hacía que un blockhash no fuera válido como valor nonce. Como resultado, una transacción ejecutada una vez como transacción normal no puede volver a ejecutarse como transacción duradera y viceversa. Además, un nuevo tipo DurableNonce reemplazó los valores de blockhash anteriores en el estado de la cuenta nonce, lo que añadió seguridad de tipos y evitó problemas similares en el futuro.

Lee nuestro artículo anterior del blog de Helius para obtener más información sobre los nonces duraderos y sus usos.

Error de bloques duplicados: septiembre de 2022

Tiempo de inactividad: Ocho horas y media

Problema raíz: Un error en las reglas de selección de bifurcaciones provocó una falla de consenso

Solución: 

• Parche del cliente

Esta interrupción se produjo cuando un validador generó por error bloques duplicados a la misma altura de bloque. Esto ocurrió porque tanto el nodo principal del validador como su nodo de respaldo se activaron al mismo tiempo. Ambos usaban la misma identidad de nodo, pero proponían bloques distintos. Esta situación persistió durante al menos 24 horas antes de la interrupción. Durante ese tiempo, la red gestionó correctamente los slots de líder duplicados del validador.

El clúster terminó deteniéndose cuando la red encontró una bifurcación irrecuperable debido a un error en la lógica de selección de bifurcaciones. Este error impedía que los productores de bloques construyeran sobre el bloque anterior, lo que provocó una falla de consenso.

Las bifurcaciones son habituales en Solana y los validadores suelen resolverlas alineándose con la bifurcación que tiene la mayoría de los votos, es decir, la bifurcación más pesada. Cuando un validador selecciona la bifurcación incorrecta, debe cambiar a la más pesada para mantenerse sincronizado con la red. Sin embargo, en este caso, los validadores no podían volver al banco más pesado si su slot coincidía con el último slot por el que habían votado. Este defecto dejó a los validadores atascados, impidió el avance del consenso y terminó deteniendo la red.

En el ejemplo anterior, el validador defectuoso C produce bloques duplicados en sus slots de líder del 5 al 8. Cuando el validador G asume como siguiente líder, solo observa uno de los duplicados y amplía su bifurcación a partir de este. Sin embargo, el líder siguiente, el validador D, detecta ambos bloques duplicados del validador C y decide descartarlos. En su lugar, construye su bifurcación sobre el slot 4.

A medida que avanza la red, la bifurcación creada por el validador G recibe los votos de la mayoría del stake y se establece como la cadena canónica. Al reconocer que su bifurcación está perdiendo, el validador D intenta cambiar a la bifurcación del validador G. Sin embargo, la transición falla debido a un error en la lógica de selección de bifurcaciones. El problema aparece porque el ancestro común de las dos bifurcaciones, un bloque duplicado en el slot 5, no se gestionó correctamente. Esto impide que el validador D reconozca la bifurcación mayoritaria. Como resultado, permanece atascado en su propia bifurcación y no puede reincorporarse a la cadena principal.

El problema se resolvió después de que el equipo principal lo revisara. Se integró un parche en la rama master y se adaptó a todas las ramas de versiones anteriores.

Un bloque grande satura Turbine: febrero de 2023

Tiempo de inactividad: Casi 19 horas

Problema raíz: Falla de la lógica de deduplicación en los servicios de reenvío de shreds

Soluciones:

• Varias mejoras en la lógica de deduplicación y el filtrado de Turbine
• Añadir un parche al cliente que obligue a los productores de bloques a cancelar el proceso si generan bloques grandes

El servicio personalizado de reenvío de shreds de un validador falló y transmitió durante su slot de líder un bloque excepcionalmente grande, de casi 150,000 shreds, varios órdenes de magnitud mayor que un bloque estándar. Esto saturó los filtros de deduplicación de los validadores y provocó que los datos se reenviaran continuamente. El problema se agravó a medida que se producían nuevos bloques y terminó saturando el protocolo.

El aumento del tráfico de red anómalo saturó Turbine y obligó a transmitir los datos de los bloques mediante el protocolo alternativo Block Repair, que es mucho más lento. Aunque Turbine está diseñado para resistir bloques grandes mediante su filtrado, los servicios de reenvío de shreds operan antes de esta lógica de filtrado, lo que reduce su eficacia. Durante el periodo de rendimiento degradado, los líderes de bloques cambiaron automáticamente al modo de solo votos, un mecanismo de seguridad en el que excluyen las transacciones económicas que no sean votos.

La causa raíz fue una falla en la lógica de deduplicación de los servicios de reenvío de shreds, que no impedía la retransmisión redundante de shreds. Además, el filtro de deduplicación del proceso de retransmisión no se diseñó originalmente para evitar bucles dentro del árbol de Turbine, lo que agravó el problema.

La red se reinició manualmente tras volver a la última versión estable conocida del software de validadores. Para mitigar estos problemas, Solana v1.13.7 y v1.14.17 introdujeron mejoras en la lógica de deduplicación, lo que mejoró su capacidad para evitar la saturación de filtros y garantizó un rendimiento de red más sólido.

Bucle infinito de recompilación: febrero de 2024

Tiempo de inactividad: Casi cinco horas

Problema raíz: Un error que provocaba un bucle infinito de recompilación en la caché JIT

Soluciones: 

• Desactivar el loader heredado en v1.17.20

El validador Agave compila justo a tiempo (JIT) todos los programas antes de ejecutar las transacciones que los referencian. Para optimizar el rendimiento, se almacena en caché la salida JIT de los programas usados con frecuencia, lo que reduce las recompilaciones innecesarias. Como parte de Agave v1.16, el mecanismo de caché existente, LoadedPrograms, se reemplazó por una nueva implementación llamada ExecutorsCache, que introdujo varias mejoras de eficiencia.

LoadedPrograms proporcionaba una vista global de los programas almacenados en caché que tenía en cuenta las bifurcaciones. Esto reducía la duplicación de datos contables y permitía que los hilos de ejecución de transacciones cargaran nuevos programas de forma cooperativa, lo que evitaba conflictos de compilación. Una función clave de este sistema era rastrear el slot en el que se activaba un programa, conocido como altura efectiva del slot, para detectar invalidaciones de caché cuando se actualizaban los datos on-chain del programa.

La altura efectiva del slot de la mayoría de los programas se derivaba del slot de implementación almacenado en su cuenta on-chain. Sin embargo, los programas implementados mediante loaders heredados no conservaban este slot en sus cuentas. Como solución provisional, LoadedPrograms asignaba a estos programas una altura efectiva del slot de cero.

Se producía una excepción al detectar una instrucción de implementación que indicaba que se había reemplazado el bytecode de un programa. En ese caso, LoadedPrograms insertaba temporalmente una entrada con la altura efectiva del slot correcta. Sin embargo, como ninguna transacción hacía referencia a esta entrada, era muy susceptible a ser expulsada. Al expulsarla, se descartaba la salida JIT y el programa se marcaba como no cargado, pero se conservaba la altura efectiva del slot.

Si más tarde una transacción hacía referencia a este programa no cargado, LoadedPrograms volvía a compilarlo e insertaba otra entrada en su altura efectiva del slot. Normalmente, esto hacía que el programa estuviera disponible para ejecutarse en la siguiente iteración. Sin embargo, en los programas con loaders heredados, se asignaba a la nueva salida JIT la altura de slot centinela de cero, lo que la colocaba detrás de la entrada no cargada anterior. Como resultado, LoadedPrograms nunca reconocía el programa como cargado y activaba un bucle continuo de recompilación en cada iteración.

En Agave v1.16, LoadedPrograms no admitía carga cooperativa, lo que permitía incluir en un bloque la transacción que desencadenaba el problema. Después, el bloque se propagaba por la red, por lo que cada validador lo reproducía y entraba en el mismo bucle infinito de recompilación. Como más del 95 % del stake del clúster ejecutaba Agave v1.17 durante la interrupción, la mayoría de los validadores quedó atascada en este bloque y la red se detuvo.

Este error se había identificado la semana anterior durante la investigación de una interrupción del clúster de Devnet, y ya se había programado la implementación de un parche. La mitigación elegida fue adaptar los cambios a Agave v1.17 y eliminar de inmediato una puerta de función al reiniciar la red. Esto desactivó el loader heredado que desencadenaba el error y evitó que volviera a ocurrir.

Parche coordinado de una vulnerabilidad: agosto de 2024

Tiempo de inactividad: Ninguno

Problema raíz: Suposición incorrecta sobre la alineación de direcciones ELF

Soluciones: 

• Actualización del parche 

El 5 de agosto, los ingenieros principales de Anza recibieron una alerta sobre una vulnerabilidad del cliente Agave reportada por un investigador externo. Un atacante podría haber aprovechado esta falla para hacer que los validadores líderes fallaran y detener toda la red. En respuesta, los ingenieros de Anza desarrollaron rápidamente un parche, que luego auditaron varias empresas de seguridad externas.

Los programas de Solana se compilan con LLVM en el formato Executable and Linkable Format (ELF). La vulnerabilidad se debía a una suposición incorrecta sobre la alineación de direcciones en estos archivos ELF generados. Aunque el saneamiento de ELF suele imponer varias comprobaciones de integridad, no validaba la alineación de la sección .text. Este descuido podría haber permitido que un archivo ELF creado con fines maliciosos definiera una sección .text mal alineada, lo que haría que la máquina virtual saltara a una dirección no válida. Esto provocaría un fallo de segmentación en el host y haría que el validador fallara.

Un atacante podría haber aprovechado esta vulnerabilidad de la siguiente manera:

• Crear un programa malicioso de Solana que usara el opcode CALL_REG.
• Manipular el archivo ELF para desalinear la sección .text.
• Implementar e invocar el programa en la red para provocar fallas en los validadores.

Proceso de actualización del parche

Cualquier parche publicado revelaría inmediatamente la vulnerabilidad a todo el mundo. Esto podría dar a un atacante tiempo suficiente para aplicar ingeniería inversa a la vulnerabilidad y detener la red antes de que se actualizara una cantidad suficiente de stake. Para evitar esa situación, una masa crítica de validadores tendría que adoptar cualquier parche lo antes posible.

Para el 7 de agosto, varios miembros de la Solana Foundation se habían comunicado con los validadores mediante mensajes privados en distintas plataformas. Les informaron sobre un próximo parche crítico y compartieron un mensaje con hash que confirmaba la fecha y el identificador único del incidente. Varios miembros destacados de Anza, Jito y Solana Foundation compartieron este hash en X, GitHub y LinkedIn para verificar la autenticidad del mensaje. Ejemplo del hash compartido: 

trent.sol

@trentdotsol

07ff4f17c96a632726e209b4afbbcf4e6ba089989cb485b8abbe85da3f558cd9

7 ago 2024, 2:35 p.m.

Durante el día siguiente, los miembros principales siguieron comunicándose con los validadores y destacaron la importancia de actuar con urgencia y confidencialidad. A la hora predeterminada, las 2 p. m. UTC del 8 de agosto, los operadores de validadores recibieron otro mensaje con instrucciones para descargar, verificar y aplicar el parche. El parche estaba alojado en el repositorio de Github de un ingeniero conocido de Anza, no en el repositorio principal de Agave. Las instrucciones incluían verificar los archivos descargados del parche comparándolos con los shasums proporcionados.

Para las 8 p. m. UTC del 8 de agosto, una supermayoría del stake ya había instalado el parche, lo que garantizaba la seguridad de la red. Después, la vulnerabilidad y su parche se divulgaron públicamente, junto con una solicitud para que todos los validadores restantes se actualizaran.

La distribución discreta del parche y la coordinación tras bastidores de los validadores generaron inquietudes sobre la descentralización de Solana. Poco después del incidente, Dan Albert, director ejecutivo de Solana Foundation, respondió a estas críticas en una entrevista con los medios.

“Creo que es importante no confundir la centralización con la capacidad de coordinación. Hay 1,500 nodos productores de bloques en todo el mundo, operados por casi la misma cantidad de personas... La capacidad de comunicarse voluntariamente con ellos, o con algunos de ellos, no debe confundirse con la centralización”.

Conclusión

Al momento de escribir este artículo, Solana lleva más de un año sin interrupciones. Esto cumple un hito clave para eliminar la etiqueta “beta” de mainnet-beta. La frecuencia de las interrupciones parece disminuir a medida que la red madura, y se espera que la introducción de Firedancer mejore la diversidad de clientes y reduzca el riesgo de que errores desconocidos o casos límite provoquen la detención completa del clúster. Sin embargo, algunos líderes de la comunidad, incluido Mert Mumtaz, fundador de Helius, han predicho que las interrupciones continuarán. El tiempo lo dirá.

Muchas gracias a Zantetsu (Shinobi Systems) y OxIchigo por revisar versiones anteriores de este trabajo.

Recursos adicionales

• Disponibilidad y estado de Solana