Beep, beep, beep. Beep, beep, beep.

El sueño de Steven es interrumpido por el sonido áspero de su teléfono, sacándolo bruscamente de sus sueños. En la oscuridad, la pantalla brilla intensamente, vibrando furiosamente en su mesa de noche. Pitido, pitido, pitido. Gruñe, frotándose somnoliento los ojos, y alcanza el dispositivo. Entrecerrando los ojos al mirar el mensaje, su corazón se hunde: el nodo está caído. Sin dudarlo, se levanta de la cama, medio vestido, tambaleándose para desbloquear su teléfono mientras llegan más mensajes. Entonces cae en la cuenta: todo el clúster está caído.

En este preciso momento, en todo el mundo, en ciudades dispersas y husos horarios diferentes, cientos de operadores de nodos están mirando sus teléfonos con la misma realización: el momento que temen ha llegado, una interrupción.

Introducción

Como todos los sistemas distribuidos, Solana opera bajo la realidad de que un solo error de implementación o un caso límite oscuro puede provocar una falla en toda la red. Las interrupciones, aunque disruptivas, son una parte inevitable de mantener infraestructuras distribuidas complejas, ya sea en blockchains descentralizados, intercambios centralizados o incluso importantes proveedores de servicios en la nube como Amazon o Microsoft.

La pregunta no es si se producirán fallos, sino cuándo y cómo evoluciona la red para adaptarse y fortalecerse contra futuros incidentes. A pesar de las rigurosas pruebas simuladas, una red de prueba incentivada y un programa activo de recompensas por errores, ningún sistema, por muy bien diseñado que esté, puede anticipar todos los modos de falla posibles. Las lecciones más valiosas provienen de las operaciones del mundo real.

En los últimos cinco años, Solana ha experimentado siete incidentes separados de interrupción, cinco de los cuales fueron causados por errores de cliente y dos por la incapacidad de la red para manejar oleadas de spam de transacciones. Las primeras versiones de Solana carecían de mecanismos clave de gestión de congestión, como tarifas prioritarias y mercados de tarifas locales, que más tarde resultaron esenciales para mitigar el estrés en la red. La falta de tales mecanismos provocó períodos prolongados de rendimiento degradado y congestión a lo largo de 2022, ya que la red básicamente incentivaba el spam.

Casos históricos de interrupciones de Solana y rendimiento degradado

Este artículo analizará cada interrupción de Solana en detalle, examinando las causas raíz, los eventos desencadenantes y las medidas tomadas para resolverlos. Además, discutiremos los aspectos clave de reinicios de red, reportes de errores y los conceptos fundamentales de fallos de vitalidad y seguridad. Aunque estas secciones se leen mejor en orden, cada una está diseñada para ser independiente, lo que permite a los lectores saltar a los temas o incidentes de interrupción que les interesen más.

Vivacidad y Seguridad

De acuerdo con el teorema CAP, también conocido como Teorema de Brewer, un sistema distribuido solo puede lograr dos de tres propiedades:

• Consistencia: Cada lectura ve todas las escrituras anteriores.
• Disponibilidad: cada solicitud recibe una respuesta.
• Tolerancia de partición: el sistema sigue funcionando a pesar de las particiones de red.

Para blockchains, la tolerancia a particiones es esencial: las interrupciones de red son inevitables. Esto fuerza una elección entre AP (Disponibilidad + Tolerancia a Particiones) y CP (Consistencia + Tolerancia a Particiones). Al igual que la mayoría de las cadenas PoS con finalidad rápida, Solana prioriza la consistencia sobre la disponibilidad, convirtiéndola en un sistema CP. Se detiene durante fallas críticas en lugar de servir datos obsoletos o permitir escrituras inseguras. Si bien esto significa que el software del nodo puede entrar en un estado irreparable que requiere intervención manual, garantiza que los fondos de los usuarios permanezcan seguros.

La posición de Solana dentro de los compromisos comerciales del teorema CAP

Fallo de vida: se produce cuando la cadena de bloques deja de progresar, lo que impide que se confirmen las transacciones y se produzcan bloques debido al tiempo de inactividad del validador, las particiones de la red o los estancamientos del consenso. En el contexto del teorema CAP, esto corresponde a una pérdida de disponibilidad.

Falla de seguridad: ocurre cuando el estado final de la cadena de bloques se altera o bifurca incorrectamente. Esto puede dar lugar a historiales contradictorios o a un doble gasto, a menudo causado por 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 vitalidad. Por lo tanto, la red se detendrá en casos de estrés extremo en la red o fallas de consenso en lugar de arriesgar la corrupción del estado. Si bien las interrupciones son disruptivas y pueden afectar a las aplicaciones, usuarios y validadores, son preferibles a las consecuencias catastróficas de un libro mayor inconsistente o corrupto.

Reinicios de red

Reiniciar la red de Solana implica identificar el último bloque de ranura confirmado de manera optimista y reiniciar los nodos desde una instantánea de estado local confiable de esa ranura. Dado que la ranura de reinicio no está determinada en la cadena, los operadores validadores deben llegar a un consenso fuera de la cadena para acordar un punto seguro de retroceso. Esta coordinación ocurre públicamente en el canal #mb-validators en el Discord de Solana Tech, donde los operadores validadores profesionales comunican en tiempo real. La mayoría de los operadores tienen sistemas de alerta automatizados que los notifican en el momento en que la producción de bloques se detiene, asegurando una respuesta rápida.

Una vez que se llega a un consenso sobre la ranura de reinicio correcta, los operadores utilizan la herramienta de contabilidad para generar una nueva instantánea local, reiniciar sus validadores y esperar a que al menos el 80% de la participación total vuelva a estar en línea. Solo entonces la red reanuda la producción y validación de bloques. La verificación de que hay como máximo un 20 % de participación fuera de línea cuando el clúster se reinicia garantiza un margen de seguridad suficiente para permanecer en línea en caso de que los nodos se bifurquen o vuelvan a desconectarse inmediatamente después del reinicio.

Informes de errores

Los programas de recompensas por errores recompensan a los investigadores de seguridad por identificar y reportar vulnerabilidades de software. Esta es una línea de defensa crítica, ya que incentiva de manera proactiva Detectar errores antes de que puedan ser explotados. Se anima a los investigadores y desarrolladores de seguridad que identifiquen posibles vulnerabilidades en el cliente de Agave a que las informen a través de los canales de seguridad adecuados. Las pautas detalladas de divulgación se pueden encontrar en el repositorio de Agave en GitHub.

Se ofrecen recompensas por informes válidos de vulnerabilidades críticas, con pagos basados en la gravedad:

• Pérdida de fondos: Hasta 25,000 SOL
• Violaciones de consenso o seguridad: hasta 12,500 SOL
• Disponibilidad o Pérdida de Disponibilidad: Hasta 5,000 SOL

Adicionalmente el cliente FireDancer tiene un programa de recompensas separado para erroresalojado a través de Immunefi, ofreciendo una recompensa máxima de $500,000 USDC por hallazgos críticos.

Instancias de interrupción

Las siguientes secciones proporcionan un análisis detallado y cronológico de las interrupciones de Solana y los períodos de rendimiento degradado, a partir del lanzamiento de Mainnet Beta el 16 de marzo de 2020. Esta evaluación destacará los incidentes clave, sus causas raíz y las mejoras posteriores en la red, ofreciendo información sobre cómo Solana ha evolucionado para mejorar la estabilidad y la resiliencia con el tiempo.

Error de turbina: diciembre de 2020

Tiempo de inactividad: Aproximadamente seis horas

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

Fija:

• Realice un seguimiento de los bloques por hash en lugar de por número de ranura
• Corregir lugares en la turbina donde la detección de fallas se puede hacer antes
• Propagar la primera falla detectada a todos los validadores a través del chisme

Esta interrupción fue causada por un anteriormente conocido problema de reparación de bloques y procesamiento de códigodesencadenado por un error no identificado enMecanismo de propagación de bloques de Solana. La falla ocurrió cuando un validador transmitió dos bloques diferentes para el mismo espacio de tiempo y los propagó a dos particiones separadas (A y B) mientras que una tercera partición detectó independientemente la inconsistencia.

Dado que cada partición solo mantenía una participación minoritaria, ninguna pudo alcanzar un consenso de supermayoría para progresar en la cadena. El problema subyacente se originó en cómo las estructuras de datos internas de Solana rastrean los bloques y su estado computado. El sistema utilizaba el número de slot de Prueba de Historia (PoH) (un identificador u64) para hacer referencia al estado y al bloque en ese slot. Una vez que la red se dividió en particiones, los nodos interpretaron erróneamente los bloques A y B como idénticos, lo que impidió una reparación adecuada y la sincronización de bloques.

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

• Los nodos que tienen el bloque A rechazaron las bifurcaciones derivadas del bloque B
• Los nodos que tienen el bloque B rechazaron las bifurcaciones derivadas del bloque A

Dado que las transiciones de estado difieren entre particiones, los validadores no pudieron reparar o reconciliar las bifurcaciones, lo que impidió la finalidad.

La solución para este problema fuepermitir que los servicios rastreen bloques por hash en lugar de número de ranuraSi cualquier número de bloques para el mismo slot crea particiones, se tratan de la misma manera que las particiones con bloques que ocupan slots diferentes. Los nodos podrán reparar todas las bifurcaciones posibles, y el consenso podrá 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 de que suficiente peso de participación volviera a estar en línea, ya que Solana requiere al menos un 80% de participación para reanudar la producción de bloques.

El IDO del Protocolo Grape: septiembre de 2021

Tiempo de inactividad: Diecisiete horas

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

Correcciones:

• Ignorar bloqueos de escritura en programas
• Límites de tasa en el reenvío de transacciones
• Comportamiento de reintentos de RPC configurable
• Priorización de transacciones de votación de TPU

El 14 de septiembre de 2021, Solana experimentó un importante bloqueo de red tras el lanzamiento del Protocolo Grape de su oferta inicial de intercambio descentralizado (IDO) en la plataforma de crowdfunding Raydium AcceleRaytor. En los 12 minutos posteriores al IDO, la red se vio abrumada por una inundación sin precedentes de transacciones impulsadas por bots y dejó de producir ranuras enraizadas. Estos bots ejecutaron efectivamente un ataque de denegación de servicio distribuido (DDoS), llevando las cargas de transacciones más allá de la capacidad de la red.

En el pico de congestión:

• Algunos validadores estaban recibiendo más de 300,000 transacciones por segundo.
• Los datos brutos de las transacciones superaron 1 Gbps, con 120.000 paquetes por segundo.
• A veces, el tráfico superaba los límites físicos de las interfaces de red, lo que provocaba la pérdida de paquetes en el puerto del switch antes de llegar siquiera a los validadores.

Tragamonedas de Solana por segundo durante la interrupción de Grape IDO del 14 de septiembre de 2021 (Fuente de datos: Jump Crypto)

Uno de los bots estructuró sus transacciones para bloquear por escritura 18 cuentas clave, incluido el programa global de tokens SPL y el ahora desaparecido programa Serum DEX. Esto bloqueó todas las transacciones que interactuaban con estas cuentas, lo que redujo gravemente la capacidad de procesamiento paralelo de Solana. En lugar de ejecutar transacciones de forma independiente, la red se convirtió en un cuello de botella, procesando las transacciones secuencialmente, lo que exacerbó la congestión.

Ya se ha desarrollado una solución que ignora los bloqueos de escritura en los programas y se ha programado su lanzamiento. Más tarde, el reinicio de la red habilitó esta actualización, eliminando permanentemente este vector de ataque.

Durante el evento IDO, los validadores recibieron una avalancha de transacciones impulsadas por bots y, a su vez, reenviaron las transacciones excesivas al siguiente líder, amplificando la congestión. El reinicio de la red introdujo límites de tasa en el reenvío de transacciones para evitar que futuras tormentas de transacciones abrumen a los líderes.

Los nodos RPC de Solana vuelven a intentar automáticamente las transacciones fallidas, una función diseñada para mejorar la fiabilidad. Sin embargo, este mecanismo de reintento exacerbó la inundación de transacciones en situaciones de extrema congestión, manteniendo transacciones antiguas en circulación en lugar de permitir que la red se recupere. Solana 1.8 introdujo un comportamiento de reintento de RPC configurable, lo que permite a las aplicaciones optimizar los reintentos con tiempos de caducidad más cortos y estrategias de retroceso exponencial.

Bajo una congestión intensa, los líderes de Solana no lograron incluir transacciones de voto, que son críticas para mantener el consenso. Como resultado, la falta de votos confirmados llevó a un estancamiento del consenso, deteniendo la producción de nuevos bloques raíz. Versiones posteriores del cliente de Solana introdujeron un mecanismo para priorizar las transacciones de voto, evitando que se ahoguen por transacciones regulares en eventos futuros.

Un segundo error: desbordamiento de enteros

Durante el reinicio de la red, surgió un segundo problema. Los validadores informaron de cantidades de participación activa que fluctuaban salvajemente. Este problema se originó a partir de un error en el que el porcentaje de participación se multiplicaba incorrectamente por 100, superando el valor máximo posible. El mecanismo de inflación había creado tantos nuevos tokens SOL que desbordó un entero sin signo de 64 bits. Este error fue identificado rápidamente y corregido antes de un segundo reinicio.

Alta congestión: enero de 2022

Tiempo de inactividad: Ninguno

Causa raíz: Transacciones duplicadas excesivas

Corrección parcial:

• Versiones de Solana 1.8.12 y 1.8.14
• 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 red principal de Solana experimentó una grave congestión de la red, lo que provocó un rendimiento degradado e interrupciones parciales. La interrupción fue impulsada por bots que enviaron spam a transacciones duplicadas excesivas, lo que redujo significativamente la capacidad de la red. Los bloques tardaron más de lo esperado en procesarse, lo que provocó que el siguiente líder se bifurcara y redujera aún más el rendimiento. En su punto álgido, las tasas de éxito de las transacciones se redujeron hasta en un 70%. El cliente luchaba por manejar las transacciones cada vez más complejas y de alta computación de la red, exponiendo limitaciones en su capacidad para satisfacer la demanda.

Se produjo una inestabilidad adicional del 21 al 23 de enero, con congestión persistente. El 22 de enero, el punto final RPC público (https://api.mainnet-beta.solana.com) se desconectó debido a abusos, ya que las llamadas RPC por lotes no deseadas abrumaron el sistema.

Para abordar estos problemas, el Lanzamiento de Solana 1.8.12 dirigido específicamente a la agotamiento de la memoria caché del programa, mientras la versión 1.8.14 introdujo mejoras en la caché de Sysvar, descarte de SigVerify y deduplicación de SigVerify.

Candy Machine Spam: abril / mayo de 2022

Tiempo de inactividad: Ocho horas

Problema principal: Spam de transacciones de cuentas de bots

Correcciones:

• Impuesto del bot en el programa de la máquina de dulces
• Mejoras de memoria en Solana v1.10

El 30 de abril de 2022, Solana experimentó un aumento sin precedentes en las solicitudes de transacción. Algunos nodos informaron que alcanzaron seis millones de solicitudes por segundo, generando más de 100 Gbps de tráfico por nodo. Este aumento fue impulsado por bots que intentaban asegurar NFT recién acuñados a través del programa Metaplex Candy Machine. Este mecanismo de acuñación operaba en base al principio de 'el primero en llegar, será el primero en ser atendido', creando un fuerte incentivo económico para inundar la red con transacciones y ganar la acuñación.

30 de abril / 1 de mayo de 2022, cierre de la máquina de dulces, paquetes por segundo de entrada (Fuente de datos: Jump Crypto)

A medida que el volumen de transacciones se disparaba, los validadores se quedaron sin memoria y se bloquearon, lo que finalmente paralizó el consenso. La insuficiente capacidad de votación impidió la finalización de bloques anteriores, lo que evitó que se limpiaran las bifurcaciones abandonadas. Como resultado, los validadores se vieron abrumados por la gran cantidad de bifurcaciones que tenían que evaluar, superando su capacidad incluso después de reinicios y requiriendo intervención manual para restaurar la red.

Si bien esta interrupción compartió similitudes con el incidente de septiembre de 2021, Solana demostró una mayor resistencia. A pesar de experimentar un 10.000% más de solicitudes de transacciones que en la interrupción anterior, la red siguió operativa durante mucho más tiempo, lo que refleja las mejoras realizadas por la comunidad de validadores en respuesta a desafíos de escalabilidad anteriores.

30 de abril / 1 de mayo de 2022, falla de la máquina de dulces, validadores activos(Fuente de datos: Jump Crypto)

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

Sin embargo, los problemas fundamentales seguían sin resolverse. El líder aún procesaba transacciones que competían por los mismos datos de cuenta en base al orden de llegada, sin una prevención efectiva de spam, dejando a los usuarios incapaces de priorizar la urgencia de sus transacciones. Para abordar esto, se propusieron tres mecanismos a largo plazo como soluciones prácticas.

La Adopción de QUIC: Anteriormente, Solana dependía del protocolo de red UDP (User Datagram Protocol) para enviar transacciones a través de Gulf Stream desde nodos RPC al líder actual. Si bien es rápido y eficiente, UDP es sin conexión, carece de control de flujo y de acuses de recibo. En consecuencia, no hay una forma significativa de desalentar o mitigar el comportamiento abusivo. Para controlar el tráfico de red, el protocolo de ingestión de transacciones del validador (es decir, la Etapa de Recuperación del TPU) se implementó nuevamente con QUIC.

QUIC intenta ofrecer lo mejor de TCP y UDP. Facilita una comunicación rápida y asincrónica similar a UDP pero con las sesiones seguras y las estrategias avanzadas de control de flujo de TCP. Esto permite establecer límites en las fuentes de tráfico individuales para que la red pueda centrarse en procesar transacciones genuinas. QUIC también tiene un concepto de flujos separados, por lo que si una transacción se cae, no bloquea las restantes. QUIC finalmente se integró en el cliente de Solana Labs con el lanzamiento 1.13.4.

Calidad de Servicio Ponderada por Participación (SWQoS): Se introdujo un nuevo sistema que prioriza el tráfico de red en función de la participación que tienen los validadores, asegurando que aquellos con una participación mayor puedan enviar transacciones de manera más eficiente. Bajo este mecanismo, un validador con el 3% del total de la participación puede enviar hasta el 3% de los paquetes totales al líder. SWQoS actúa como una medida de resistencia Sybil, lo que dificulta que los actores malintencionados inunden la red con transacciones de baja calidad. Este enfoque reemplaza al modelo anterior de primero en llegar, primero en ser servido, que aceptaba transacciones indiscriminadamente sin considerar su origen.

Introducción de tarifas prioritarias:Una vez que las transacciones son ingeridas, aún compiten por acceder a los datos de cuenta compartidos. Anteriormente, esta contención se resolvía según un simple criterio de llegada, sin dar a los usuarios ninguna forma de señalar la urgencia de sus transacciones. Dado que cualquiera puede enviar transacciones, la ponderación de la participación no es adecuada para la priorización en esta etapa. Para abordar esto, se agregó una nueva instrucción al programa de Presupuesto de Cómputo, permitiendo a los usuarios especificar una tarifa adicional recolectada al momento de la ejecución y la inclusión en el bloque. La relación tarifa-unidad-de-cómputo determina la prioridad de ejecución de una transacción, asegurando un enfoque más dinámico y orientado al mercado para la ordenación de transacciones.

Impuesto del Bot de Máquina de Dulces

Metaplex introdujo rápidamente un impuesto de bot codificado duro de 0.01 SOL en transacciones de creacióninteractuar con el programa Candy Machine para combatir el spam impulsado por bots. Este mecanismo anti-spam impuso una tarifa mínima para disuadir la actividad maliciosa sin penalizar a los usuarios legítimos que cometieron errores accidentales. El impuesto se aplicó en escenarios específicos, incluyendo:

• Intento de acuñar cuando la Máquina de Dulces no estaba activa
• Intentando crear cuando no quedan elementos
• Transacciones donde la acuñación o la configuración de la colección no fue la instrucción final
• Uso de ID de colección incorrecta
• Instrucciones de colección de conjuntos desparejados
• Una discrepancia entre el firmante-pagador en el conjunto de colección e instrucciones de acuñación
• Transacciones sospechosas que involucran programas no permitidos
• Intentando acuñar desde una Máquina de Dulces protegida por AllowList sin tener el token de allowlist requerido

Este impedimento económico resultó muy efectivo. Los snipers de Mint fueron rápidamente drenados, y la actividad de spam cesó. En los primeros días, los botters perdieron colectivamente más de 426 SOL.

Error de nonce duradero: junio de 2022

Tiempo de inactividad: Cuatro horas y media

Problema raíz: error de número duradero que conduce a un fallo de consenso

Correcciones:

• Desactivación temporal de transacciones de nonce duraderas
• Actualización de Solana 1.10.23

Un error en tiempo de ejecución permitió que ciertas transacciones de número duradero se procesaran dos veces: una vez como transacción regular y nuevamente como transacción de número si usaban un blockhash reciente en lugar de un número duradero en el campo recent_blockhash. Esto llevó a un comportamiento no determinista entre los validadores, ya que algunos nodos rechazaron la segunda ejecución mientras que otros la aceptaron. Críticamente, dado que más de un tercio de los validadores aceptaron el bloque, impidió que la mayoría requerida de dos tercios alcanzara un consenso.

A diferencia de las transacciones estándar, las transacciones nonce duraderas no caducan y requieren un mecanismo único para evitar la doble ejecución. Se procesan en serie utilizando un valor nonce en cadena vinculado a cada cuenta, que se rota cada vez que se procesa una transacción nonce duradera. Una vez rotada, la misma transacción nonce no debería volver a ser válida.

Para mitigar el problema, las transacciones duraderas de nonce fueron desactivadas temporalmente.Una corrección se implementó más tarde en Solana 1.10.23, lo que evitaba la ejecución duplicada al separar los dominios nonce y blockhash. La actualización garantizó que, al avanzar en las cuentas nonce, el hash de bloque se hashea con una cadena fija, lo que hace que un hash de bloque no sea válido como valor de nonce. Como resultado, una transacción ejecutada una vez como una transacción normal no se puede volver a ejecutar como una transacción duradera, y viceversa. Además, un nuevo tipo DurableNonce reemplazó los valores de hash de bloque anteriores en el estado de la cuenta nonce, lo que agregó seguridad de tipos y evitó problemas similares en el futuro.

Lea nuestro artículo de blog anterior de Helius paracomprender más sobre duraderos números aleatorios y sus usos.

Error de bloque duplicado: septiembre de 2022

Tiempo de inactividad: Ocho horas y media

Problema raíz: Un error en las reglas de elección de bifurcación llevó a un fallo en el consenso

Solucionar:

• Cliente parche

Esta interrupción fue desencadenada por un validador que produjo erróneamente bloques duplicados en la misma altura de bloque. Esto ocurrió porque tanto el nodo principal del validador como su nodo de repuesto de respaldo se activaron simultáneamente, utilizando la misma identidad de nodo pero proponiendo bloques diferentes. Esta condición persistió durante al menos 24 horas antes de la interrupción, durante las cuales la red manejó correctamente las ranuras de líder duplicadas del validador.

El clúster finalmente se detuvo cuando la red encontró una bifurcación irrecuperable debido a un error en la lógica de selección de bifurcación. Este error impedía que los productores de bloques construyeran sobre el bloque anterior, lo que provocaba un fallo en el consenso.

Los forks son un suceso rutinario en Solana, y los validadores típicamente los resuelven al alinearse en el fork con la mayoría de votos (el fork más pesado). Cuando un validador selecciona el fork incorrecto, debe cambiar al fork más pesado 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 su último slot votado. Esta falla causó que los validadores quedaran atascados, impidiendo que el consenso progresara y, en última instancia, llevando a la detención de la red.

Error de bloque duplicado, elección de bifurcación, septiembre de 2022 (Fuente: Laine, Michael Hubbard)

En el ejemplo anterior, el validador defectuoso C produce bloques duplicados para sus ranuras de líder del 5 al 8. Cuando el validador G asume como el próximo líder, solo observa uno de los duplicados y extiende su bifurcación en consecuencia. Sin embargo, el siguiente líder, el validador D, detecta ambos bloques duplicados del validador C y decide desecharlos, en su lugar construyendo su bifurcación sobre la ranura 4.

A medida que avanza la red, la bifurcación construida por el validador G obtiene votos de la mayoría de las participaciones, estableciéndose como la cadena canónica. Reconociendo 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 la bifurcación. Este problema surge porque el ancestro común de las dos bifurcaciones, un bloque duplicado en la ranura 5, no se manejó correctamente, lo que impidió que el validador D reconociera la bifurcación mayoritaria. Como resultado, el validador D permanece atascado en su propia bifurcación, incapaz de volver a unirse a la cadena principal.

El problema se resolvió después de una revisión por parte del equipo principal. Se fusionó un parche en la rama principal y se volvió a portar a todas las ramas de lanzamiento.

Un bloque grande abruma a la turbina: febrero de 2023

Tiempo de inactividad: Casi 19 horas

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

Fija:

• Múltiples mejoras en la lógica de deduplicación y filtrado de Turbine
• Agregue un parche de cliente que obligue a los productores de bloques a abortar si generan bloques grandes

El servicio de reenvío de trituración personalizado de un validador no funcionó correctamente, transmitiendo un bloque excepcionalmente grande (casi 150.000 fragmentos), varios órdenes de magnitud más grande que un bloque estándar, durante su ranura líder. Esto desbordó los filtros de deduplicación del validador, lo que provocó que los datos se reenviaran continuamente. El problema se agravó a medida que se producían nuevos bloques, lo que finalmente saturó el protocolo.

Gran bloque de apagón, fragmentos por bloque, febrero de 2023 (Fuente: Laine, Michael Hubbard)

El aumento en el tráfico de red anormal abrumó a Turbine, obligando a que los datos de bloque se transmitieran a través del protocolo de Reparación de Bloque de recuperación significativamente más lento. Aunque Turbine está diseñado para resistir bloques grandes filtrándolos, los servicios de reenvío de fragmentos funcionan aguas arriba de esta lógica de filtrado, disminuyendo su efectividad. Durante el período degradado, los líderes de bloque pasaron automáticamente al modo solo de voto, un mecanismo de seguridad en el que los líderes excluyen transacciones económicas de no voto.

La causa raíz del problema fue una falla en la lógica de deduplicación dentro de los servicios de reenvío de fragmentos, lo que evitó la retransmisión redundante de fragmentos. Además, el filtro de deduplicación en la tubería de retransmisión no fue diseñado originalmente para evitar el bucle dentro del árbol de Turbina, exacerbando el problema.

La red se reinició manualmente con un retroceso a la última versión conocida estable del software del validador. Para mitigar estos problemas, Solana v1.13.7 y v1.14.17 introdujeron mejoras en la lógica de deduplicación, mejorando su capacidad para prevenir la saturación del filtro y garantizando un rendimiento de red más sólido.

Bucle de recompilación infinita: febrero de 2024

Tiempo de inactividad: casi cinco horas

Problema raíz: Error que causa un bucle de recompilación infinito en la caché JIT

Correcciones:

• Deshabilitar el cargador heredado v1.17.20

El validador de Agave compila justo a tiempo (JIT) todos los programas antes de ejecutar transacciones que los referencian. Para optimizar el rendimiento, la salida JIT de los programas de uso frecuente se almacena en caché, reduciendo las recompilaciones innecesarias. Como parte de Agave v1.16, el mecanismo de almacenamiento en caché existente, LoadedPrograms, fue reemplazado por una nueva implementación llamada ExecutorsCache, que introdujo varias eficiencias.

LoadedPrograms proporcionaba una vista global y compatible con bifurcaciones de los programas almacenados en caché, lo que reducía la duplicación de datos contables y permitía que los subprocesos de ejecución de transacciones cargaran nuevos programas de forma cooperativa, lo que evitaba conflictos de compilación. Una característica clave de este sistema era el seguimiento de la ranura donde un programa se activa (conocida como la altura efectiva de la ranura) para detectar invalidaciones de caché cuando se actualizan los datos del programa en cadena.

La altura efectiva de la ranura de la mayoría de los programas se derivaba de su ranura de implementación, que se almacenaba en su cuenta en cadena. Sin embargo, los programas implementados con cargadores heredados no conservaron esta ranura de implementación en sus cuentas. LoadedPrograms asignó a estos programas una altura de ranura efectiva de cero como solución alternativa.

Se producía una excepción cuando se detectaba una instrucción de implementación, lo que indicaba que se había reemplazado el código de bytes de un programa. En este caso, LoadedPrograms insertó temporalmente una entrada con la altura de ranura efectiva correcta. Sin embargo, debido a que una transacción nunca hizo referencia a esta entrada, era muy susceptible de ser desalojada. Cuando se expulsaba, la salida JIT se descartaba y el programa se marcaba como descargado, pero se conservaba la altura efectiva de la ranura.

Si una transacción posterior hace referencia a este programa descargado, LoadedPrograms lo vuelve a compilar y vuelve a insertar una entrada en su altura de espacio efectiva. Normalmente, esto haría que el programa esté disponible para su ejecución en la siguiente iteración. Sin embargo, para programas de carga antiguos, la nueva salida JIT se asignaba la altura de espacio centinela cero, colocándola detrás de la entrada descargada anterior. Como resultado, LoadedPrograms nunca reconoció el programa como cargado, lo que desencadenaba un bucle continuo de recompilación en cada iteración.

En Agave v1.16, LoadedPrograms no admitía la carga cooperativa, lo que permitía que la transacción desencadenante se empaquetara en un bloque. Este bloque se propagaba entonces por la red, haciendo que cada validador lo volviera a reproducir y entrara en el mismo bucle de recompilación infinita. Dado que más del 95% de la participación en el clúster estaba ejecutando Agave v1.17 durante la interrupción, la mayoría de los validadores quedaron detenidos en este bloque, lo que paralizó la red.

Este error se identificó la semana anterior durante una investigación sobre una interrupción del clúster de Devnet y se programó la implementación de un parche. @jeff.washington/2024-02-06-solana-mainnet-beta-outage-report-619bd75b3ce0">La mitigación elegida fue retroceder los cambios a Agave v1.17 y eliminar inmediatamente una puerta de enlace de funciones al reiniciar la red. Esto deshabilitó el cargador heredado responsable de desencadenar el error, evitando futuras ocurrencias.

Parche de vulnerabilidad coordinado: agosto de 2024

Tiempo de inactividad: Ninguno

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

Correcciones:

• Actualización del parche

El 5 de agosto, Los ingenieros centrales de Anza fueron alertados de una vulnerabilidad en el cliente de Agave, reportada por un investigador externo. Un atacante podría haber explotado esta falla para hacer que los validadores líderes se bloquearan, lo que llevaría a una parada en toda la red. Como respuesta, los ingenieros de Anza desarrollaron rápidamente un parche, que luego fue auditado por varias empresas de seguridad externas.

Los programas de Solana se compilan usando LLVM en Formato Ejecutable y Enlazable (ELF). La vulnerabilidad se originó a partir de una suposición incorrecta de alineación de direcciones dentro de estos archivos ELF generados. Si bien la desinfección de ELF normalmente impone varias verificaciones de integridad, no validó la alineación de la sección .text. Esta omisión podría haber permitido que un archivo ELF maliciosamente elaborado definiera una sección .text desalineada, lo que llevaría a la máquina virtual a saltar a una dirección no válida. Esto resultaría en una falla de segmentación del host, provocando la caída del validador.

Un atacante podría haber explotado esta vulnerabilidad mediante:

• Creación de un programa malicioso de Solana que utiliza el código de operación CALL_REG.
• Manipular el archivo ELF para desalinear la sección .text.
• Desplegar e invocar el programa en la red, desencadenando accidentes de validación.

Proceso de Actualización de Parches

Cualquier actualización de parche publicada públicamente aclararía inmediatamente la vulnerabilidad para todos. 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 haya actualizado una cantidad suficiente de participación. Una masa crítica de validadores necesitaría adoptar cualquier versión de parche lo más rápido posible para evitar tal escenario.

Para el 7 de agosto, varios miembros de la La Fundación Solana se había puesto en contacto con los validadores a través de mensajes privados en varias plataformas de comunicación, informándoles de un próximo parche crítico y compartiendo un mensaje con hash que confirmaba la fecha y el identificador único del incidente. Varios miembros destacados de Anza, Jito y la Fundación Solana compartieron este hash en X, GitHub y LinkedIn para verificar la precisión del mensaje. Ejemplo de hash compartido:

Durante el próximo día, los miembros principales continuaron contactando a los validadores, subrayando la importancia de la urgencia y la confidencialidad. En el momento preestablecido, el 8 de agosto, a las 14:00 UTC, los operadores de validadores recibieron un mensaje adicional que contenía instrucciones para descargar, verificar y aplicar el parche. El parche se alojó en el repositorio Github de un ingeniero Anza conocido, no en el repositorio principal de Agave. Las instrucciones incluían la verificación de los archivos de parche descargados contra los shasums suministrados.

A las 8 p.m. UTC del 8 de agosto, se había parcheado una gran mayoría de la participación, lo que garantizaba la seguridad de la red. A raíz de esto, la vulnerabilidad y su parche correspondiente se dieron a conocer públicamente, acompañados de un llamamiento a todos los validadores restantes para que se actualizaran.

La distribución silenciosa del parche y la coordinación entre bastidores de los validadores plantearon preocupaciones sobre la descentralización de Solana. Poco después del incidente, el director ejecutivo de la Fundación Solana, Dan Albert, abordó estas críticas en una entrevista con los medios de comunicación.

"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 que son operados por casi la misma cantidad de individuos. La capacidad de comunicarse con ellos, o con algunos de ellos, voluntariamente, no debe confundirse con la centralización".

Semana de la cadena de bloques de Corea (KBW) 2024

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 que son operados por casi la misma cantidad de individuos. La capacidad de comunicarse con ellos, o con algunos de ellos, voluntariamente, no debe confundirse con la centralización.

Conclusión

En el momento de escribir este artículo, Solana ha pasado más de un año sin interrupciones, cumpliendo un hito clave para eliminar la etiqueta "beta" de la red principal beta. La frecuencia de las interrupciones parece estar disminuyendo a medida que la red madura, y se espera que la introducción de Firedancer mejore la diversidad de clientes, reduciendo el riesgo de errores no descubiertos o casos extremos que provoquen un cierre completo de todo el clúster. Sin embargo, algunos líderes comunitarios, incluido el fundador de Helius, Mert Mumtaz, han pronosticado que los apagones continuarán. El tiempo lo dirá.

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

Renuncia:

1. Este artículo es una reimpresión de [Helius]. Todos los derechos de autor pertenecen al autor original [Lostin]. Si hay objeciones a esta reimpresión, por favor contacte al Aprender de gateequipo y lo resolverán rápidamente.
2. Descargo de responsabilidad: Las opiniones y puntos de vista expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. El equipo de gate Learn realiza traducciones del artículo a otros idiomas. Está prohibido copiar, distribuir o plagiar los artículos traducidos a menos que se mencione.