Cómo Solana neutralizó un ataque de 6 Tbps utilizando un protocolo específico de modelado de tráfico que hace imposible escalar el spam

Cuando una red presume de su capacidad de procesamiento, en realidad está presumiendo de cuántos caos puede soportar antes de colapsar. Por eso, la parte más interesante de la última “prueba de estrés” de Solana es que, en realidad, no hay ninguna historia que contar.

Una red de entrega llamada Pipe publicó datos que situaban el reciente ataque contra Solana en aproximadamente 6 terabits por segundo, y los cofundadores de Solana respaldaron públicamente la validez general de estos datos. Si la cifra es correcta, se trata de un volumen de tráfico normalmente reservado para los mayores objetivos de internet, el tipo de cosas sobre las que Cloudflare escribe extensos artículos porque no se supone que sea algo normal.

Y, sin embargo, Solana siguió produciendo bloques. No hubo reinicio coordinado ni chats grupales de validadores convirtiéndose en una película de desastre nocturna.

El propio informe de CryptoSlate sobre el incidente indicó que la producción de bloques se mantuvo estable y las confirmaciones siguieron avanzando, sin un aumento significativo en las comisiones de usuario. Incluso hubo un contrapunto en la conversación: SolanaFloor señaló que un colaborador de Anza argumentó que la cifra de 6 Tbps fue un pico breve y no una pared constante de tráfico durante una semana, lo cual es relevante porque “pico” puede ser cierto y a la vez algo teatral.

Ese tipo de matiz está bien. En ataques de denegación de servicio en el mundo real, el pico suele ser el objetivo, porque un golpe corto aún puede derribar un sistema ajustado para un estado estable.

Los informes de amenazas de Cloudflare señalan cuántos ataques grandes terminan rápidamente, a veces demasiado rápido para que los humanos reaccionen, por lo que la defensa moderna debe ser automática. El último incidente de Solana ahora muestra una red que aprendió a hacer que el spam sea aburrido.

¿Qué tipo de ataque fue este y qué quieren realmente los atacantes?

Un DDoS es el arma más burda pero efectiva de internet: sobrecargar el tráfico normal de un objetivo inundándolo con tráfico basura desde muchas máquinas a la vez. La definición de Cloudflare es directa; es un intento malicioso de interrumpir el tráfico normal sobrecargando el objetivo o la infraestructura cercana con una avalancha de tráfico de internet, normalmente proveniente de sistemas comprometidos.

Esa es la versión web2, y es la versión a la que Pipe alude con un gráfico de terabits por segundo. Las redes cripto añaden una segunda variante, más nativa del sector: spam que no es tanto “paquetes basura en un sitio web” como “transacciones interminables en una cadena”, a menudo porque hay dinero al otro lado de la congestión.

La propia historia de caídas de Solana es como un manual sobre ese problema de incentivos. En septiembre de 2021, la cadena estuvo fuera de línea durante más de 17 horas, y el primer informe de Solana describió la avalancha de transacciones automatizadas como, en efecto, un evento de denegación de servicio vinculado a un IDO alojado en Raydium.

En abril de 2022, el informe oficial de la caída de Solana describió una pared de transacciones entrantes aún más intensa, 6 millones por segundo, con nodos individuales viendo más de 100 Gbps. El informe indicó que no había evidencia de una campaña clásica de denegación de servicio, y que las huellas parecían de bots intentando ganar una acuñación de NFT donde el primer llamante obtiene el premio.

La red dejó de producir bloques ese día y tuvo que coordinar un reinicio.

Entonces, ¿qué quieren los atacantes, además de atención y el placer de arruinarle el domingo a todos? A veces es una extorsión directa: págame o seguimos con el ataque.

A veces es daño reputacional, porque una cadena que no puede mantenerse en línea no puede alojar de forma creíble las aplicaciones que la gente quiere construir. A veces es manipulación de mercado, donde una experiencia de usuario rota crea precios extraños, liquidaciones retrasadas y desvíos forzados que benefician a quienes están preparados para el desorden.

En la versión de spam en cadena, el objetivo puede ser directo: ganar la acuñación, ganar la operación, ganar la liquidación, ganar el espacio en el bloque.

Lo que es diferente ahora es que Solana ha construido más formas de rechazar la invitación.

Los cambios de diseño que mantuvieron Solana en funcionamiento

Solana mejoró su capacidad de mantenerse en línea cambiando el lugar donde aparece el dolor. En 2022, los fallos tenían una forma familiar: demasiadas solicitudes entrantes, demasiada presión sobre los recursos de los nodos, poca capacidad para frenar a los actores maliciosos y efectos secundarios que convertían la congestión en problemas de disponibilidad.

Las mejoras más importantes se encuentran en el borde de la red, donde el tráfico llega a los validadores y líderes. Una es la transición a QUIC para la comunicación de red, que Solana luego incluyó como parte de su trabajo de estabilidad, junto con mercados de comisiones locales y calidad de servicio ponderada por stake.

QUIC no es magia, pero está diseñado para conexiones controladas y multiplexadas en lugar de los patrones de conexión antiguos que facilitan el abuso.

Más importante aún, la documentación para validadores de Solana describe cómo se utiliza QUIC dentro de la ruta de la Unidad de Procesamiento de Transacciones: límites en las conexiones QUIC concurrentes por identidad de cliente, límites en los flujos concurrentes por conexión y límites que escalan con el stake del remitente. También describe la limitación de la tasa de paquetes por segundo basada en el stake, y señala que el servidor puede cerrar flujos con un código de limitación, esperando que los clientes retrocedan.

Eso convierte el “spam” en “spam que se empuja al carril lento”. Ya no basta con tener ancho de banda y una botnet, porque ahora necesitas acceso privilegiado a la capacidad del líder, o compites por una porción más estrecha de ella.

La guía para desarrolladores de Solana sobre QoS ponderada por stake lo explica claramente: con la función activada, un validador con el 1% del stake tiene derecho a transmitir hasta el 1% de los paquetes al líder. Eso impide que los remitentes con poco stake saturen a los demás y aumenta la resistencia a Sybil.

En otras palabras, el stake se convierte en una especie de derecho de ancho de banda, no solo en peso de voto.

Luego está el lado de las comisiones, donde Solana intenta evitar que “una aplicación ruidosa arruine toda la ciudad”. Los mercados de comisiones locales y las comisiones prioritarias ofrecen a los usuarios una forma de competir por la ejecución sin convertir cada momento de alta demanda en una subasta a nivel de cadena.

La documentación de comisiones de Solana explica cómo funcionan las comisiones prioritarias a través de unidades de cómputo, permitiendo a los usuarios establecer un límite de unidades de cómputo y un precio opcional por unidad de cómputo, que actúa como una propina para incentivar la priorización. También señala un detalle práctico: la comisión prioritaria se basa en el límite de unidades de cómputo solicitado, no en el cómputo realmente utilizado, por lo que una configuración descuidada puede significar pagar por capacidad no utilizada.

Eso pone precio a los comportamientos computacionalmente intensivos y da a la red una herramienta para encarecer el abuso donde más duele.

Si juntas todas estas piezas, obtienes un modo de fallo diferente. En lugar de una avalancha de ruido entrante empujando a los nodos a espirales de muerte por memoria, la red tiene más formas de limitar, priorizar y contener.

La propia Solana, al mirar atrás a la era de 2022, describió QUIC, los mercados de comisiones locales y la QoS ponderada por stake como pasos concretos para evitar que la fiabilidad se sacrifique por la velocidad.

Por eso un fin de semana a escala de terabits puede pasar sin consecuencias reales: la cadena tiene más “no” automáticos en la puerta y más formas de mantener la fila avanzando para los usuarios que no intentan romperla.

Nada de esto significa que Solana sea inmune a días feos. Incluso quienes celebran la anécdota de los 6 Tbps discuten sobre lo que significa la cifra y cuánto duró, lo cual es una forma educada de decir que las mediciones en internet son confusas y los derechos de fanfarronear no vienen con un informe de auditoría.

Y las compensaciones no desaparecen. Un sistema que vincula un mejor tratamiento del tráfico al stake es, por diseño, más amigable para los operadores bien capitalizados que para los validadores aficionados. Un sistema que se mantiene rápido bajo carga aún puede convertirse en un lugar para bots dispuestos a pagar.

Aun así, el hecho de que la red estuviera tranquila importa. Las caídas anteriores de Solana no fueron “la gente notó un poco de latencia”. La producción de bloques se detuvo por completo, seguida de reinicios públicos y largas ventanas de coordinación, incluido el paro de abril de 2022 que tardó horas en resolverse.

En contraste, la historia de esta semana es que la cadena permaneció activa mientras el tráfico supuestamente alcanzaba una escala más propia de los informes de amenazas de Cloudflare que de la historia cripto.

Solana se comporta como una red que espera ser atacada y ha decidido que el atacante debe ser el primero en cansarse.

El artículo How Solana neutralized a 6 Tbps attack using a specific traffic-shaping protocol that makes spam impossible to scale apareció primero en CryptoSlate.