Estudio revela fallas críticas en Algorand, Aptos, Avalanche, Redbelly y Solana

Una investigación comparó la resistencia de cinco blockchains en producción frente a cinco tipos de ataques de comunicación y encontró debilidades concretas en todas. El trabajo concluye que Aptos, Avalanche y Solana presentan vulnerabilidades especialmente delicadas bajo ciertas condiciones, mientras que el protocolo de transporte también influye de forma decisiva en la recuperación de la red.
***

• El estudio evaluó Algorand, Aptos, Avalanche, Redbelly y Solana frente a ataques de carga dirigida, fallas transitorias, pérdida de paquetes, parada y aislamiento de líder.
• Aptos resultó vulnerable a ataques de carga dirigida y aislamiento de líder, mientras Avalanche mostró problemas ante fallas transitorias y Solana ante ataques de parada y de líder.
• Los autores observaron que Solana resistió mejor la pérdida de paquetes gracias a QUIC y erasure coding, mientras varias redes basadas en TCP sufrieron degradaciones severas.

Las redes blockchain suelen evaluarse por su velocidad, costos o descentralización, pero una parte menos visible también define su seguridad: la forma en que sus nodos se comunican. Un nuevo análisis comparativo centró la atención en ese punto y puso a prueba a cinco blockchains modernas bajo escenarios adversos de red, con resultados que exponen debilidades operativas muy distintas entre sí.

El trabajo, titulado Blockchain Communication Vulnerabilities y firmado por Andrei Lebedev y Vincent Gramoli, examinó empíricamente los protocolos de comunicación de Algorand, Aptos, Avalanche, Redbelly y Solana. La investigación aplicó cinco ataques diseñados de manera agnóstica, es decir, sin depender de una cadena específica, para medir cómo reaccionan estas infraestructuras cuando la red deja de comportarse de forma ideal.

Los resultados apuntan a un mapa de fragilidad desigual. Algorand fue señalado como vulnerable a ataques por pérdida de paquetes. Aptos mostró vulnerabilidad frente a ataques de carga dirigida y aislamiento del líder. Avalanche fue afectada por fallas transitorias. Redbelly vio afectado su rendimiento por pérdida de paquetes. Solana, por su parte, fue identificada como vulnerable a ataques de parada y también de aislamiento del líder.

Para un lector nuevo en el tema, el punto de fondo es simple. Aunque una blockchain pueda tener un buen diseño de consenso, sigue dependiendo de que sus nodos intercambien mensajes en tiempos razonables. Si esa comunicación se degrada, se corta o se manipula, la red puede ralentizarse, perder transacciones o incluso quedar detenida.

Cinco ataques, una misma vara de medición

Los autores optaron por comparar a las cinco redes bajo un marco experimental común. En vez de repetir ataques históricos diseñados solo para una blockchain en particular, derivaron cinco modalidades generales: ataque de carga dirigida, ataque de falla transitoria, ataque de pérdida de paquetes, ataque de parada y ataque de aislamiento del líder.

El ataque de carga dirigida consistió en enviar tráfico continuo a un solo nodo. El de falla transitoria simuló la caída temporal de una parte pequeña de la red. El de pérdida de paquetes dejó caer parte de los mensajes entre dos segmentos. El ataque de parada desconectó una fracción amplia de nodos para intentar frenar el servicio. El de aislamiento del líder apuntó a separar al nodo que coordina el progreso en blockchains con liderazgo explícito.

Para probarlos, el equipo desplegó redes de 25 máquinas virtuales con Ubuntu 24.04.1 LTS. Cada nodo operó con 4 vCPU y 8 GB de memoria. El entorno incluyó 20 nodos blockchain, 5 nodos de benchmark y hasta 20 clientes enviando transacciones nativas. La tasa de envío se fijó en 200 TPS, limitada por la capacidad de Avalanche, cuya configuración también obligó a desactivar la escalada dinámica de comisiones para evitar que el experimento se sesgara por el mecanismo de tarifas.

Ese detalle no es menor. Los autores subrayaron que, en Avalanche, una carga sostenida podía hacer subir las comisiones base hasta frenar el procesamiento. Por eso desactivaron esa escalada en la génesis de sus pruebas, con el fin de aislar el comportamiento del protocolo de comunicación y no mezclarlo con el diseño de tarifas.

Aptos destacó por su cuello de botella bajo carga dirigida

Uno de los hallazgos más notorios apareció con Aptos. Cuando un solo cliente envió transacciones a 200 TPS hacia un único nodo, la red necesitó 4 minutos y 15 segundos para confirmar todas las operaciones. En comparación, Avalanche con la tarifa base desactivada y Redbelly tardaron menos de 3 segundos, Algorand tomó 10 segundos y Solana 27 segundos.

La mediana de latencia en Aptos superó los 2 minutos y 30 segundos, una cifra muy por encima del resto. Según el análisis, el problema no fue simplemente falta de hardware. El diseño de Quorum Store elimina parte del cuello de botella del líder, pero traslada la presión hacia el validador que recibe las transacciones, ya que ese nodo debe procesarlas, agruparlas, difundir lotes y recolectar firmas de más de 2n/3 validadores para formar la prueba de almacenamiento.

La investigación encontró además un fuerte desbalance de tráfico. El nodo atacado en Aptos concentró 25,7% del tráfico saliente total por nodo, contra niveles mucho menores en las demás redes. Esa asimetría convierte a un solo validador en un punto de presión claro para un atacante.

Distribuir la carga tampoco resolvió del todo el problema. El mejor resultado apareció cuando 30% de los validadores recibían transacciones, con una mediana de latencia de 2,27 segundos. Sin embargo, al repartir el flujo entre 60% y 100% de los nodos, Aptos empezó a perder transacciones. En una prueba donde todos los nodos recibían carga, solo 50% de las transacciones enviadas fueron confirmadas.

Avalanche sufrió por la combinación de fallas y throttling

En el caso de Avalanche, la vulnerabilidad más clara emergió con las fallas transitorias. Al desconectar temporalmente 10% de los nodos desde el segundo 133 hasta el 266, la red perdió de manera permanente cerca de 60% de las transacciones. Solo 40% terminó siendo confirmado, incluso después de que los nodos afectados regresaran.

El problema, según los autores, estuvo en el mecanismo de throttling. Esta defensa intenta limitar el procesamiento de mensajes cuando detecta consumo elevado de recursos. Pero durante la falla temporal, los nodos sanos seguían intentando muestrear nodos caídos para el consenso, generando mucho tráfico improductivo. El sistema interpretó eso como sobrecarga maliciosa y empezó a limitar colas de mensajes legítimos.

Cuando los investigadores repitieron la prueba con el throttling desactivado, Avalanche recuperó el servicio y confirmó 100% de las transacciones. Eso sugiere que la defensa, al menos en estas condiciones, agravó el fallo en vez de contenerlo. Con 25% de nodos afectados, el deterioro fue todavía mayor, en línea con el umbral probabilístico de tolerancia de n/5 citado en el estudio.

Avalanche también mostró un estado de casi parada cuando las fallas transitorias afectaron 30% de la red. La combinación de pérdidas, huecos de nonce, mempool limitado y throttling dejó a la cadena con throughput muy bajo incluso después de la recuperación. Los autores indicaron que elevar el tamaño del pool de transacciones y desactivar temporalmente el throttling durante la recuperación ayudó a mitigar este comportamiento.

Las pérdidas de paquetes golpearon con fuerza a las redes basadas en TCP

Otro frente relevante fue la pérdida de paquetes. Los investigadores dejaron caer entre 25% y 75% de los paquetes intercambiados entre un grupo de nodos y el resto de la red. En estas pruebas se observó una diferencia marcada entre protocolos de transporte.

Algorand, Aptos, Avalanche y Redbelly, que dependen de TCP para buena parte de su comunicación, exhibieron degradaciones pronunciadas. En Algorand y Redbelly, por ejemplo, el ancho de banda promedio entre pares durante un ataque de 50% de pérdida cayó más de 95%. En Avalanche y Aptos también se registraron descensos superiores a 80%.

Algorand fue descrita como particularmente afectada incluso con 25% de pérdida de paquetes. Los autores vincularon esa sensibilidad a tres factores. Primero, las transacciones quedan atascadas en una cola de difusión que puede llenarse. Segundo, tras restablecerse la conectividad, la red aún necesita tiempo adicional para retomar el procesamiento. Tercero, su mecanismo de sincronización basado en Bloom filters puede omitir la recuperación de ciertas transacciones perdidas por falsos positivos.

Redbelly también sufrió un impacto visible en rendimiento por su dependencia de TCP, aunque el estudio matizó que la red seguía siendo más resistente a otros ataques. En contraste, Solana destacó por sostener su tasa de transmisión prácticamente intacta durante ataques severos de pérdida de paquetes, gracias al uso combinado de QUIC, propagación jerárquica Turbine y erasure coding.

Solana resistió mejor la pérdida de paquetes, pero no los ataques de parada

La investigación describe a Solana como el caso más robusto frente a pérdidas de paquetes, pero no frente a fallas masivas. En las pruebas, la red logró seguir difundiendo bloques bajo condiciones muy adversas, apoyada en QUIC para evitar el bloqueo por línea de cabeza y en fragmentos redundantes que permiten reconstruir bloques aunque una parte importante de los datos se pierda en tránsito.

Sin embargo, cuando 90% de los nodos experimentó una falla transitoria simultánea, Solana entró en una detención completa y no se recuperó por sí sola. La causa señalada fue un bloqueo de vivacidad relacionado con su mecanismo de vote lockout. Tras un reinicio masivo, los líderes esperaban un rooted vote de una supermayoría antes de producir bloques, pero esa condición no podía cumplirse con la mayoría aún fuera de línea o bloqueada.

El estudio afirma que esa vulnerabilidad no parece ser fundamental al consenso en sí, sino más bien a una configuración por defecto. Al activar la opción –no-wait-for-vote-to-start-leader, la red pudo recuperarse tras el ataque, ya que permitió a los líderes comenzar a producir bloques sin esperar ese rooted vote reciente.

Los autores también observaron un comportamiento de repropagación continua de transacciones no confirmadas a través del mecanismo de forwarding, lo que generó picos persistentes de ancho de banda hasta la recuperación. Con el ajuste mencionado, ese patrón se normalizó una vez procesado el rezago.

El aislamiento de un solo líder frenó a Aptos y Solana

El ataque de aislamiento del líder introdujo otro ángulo crítico. En blockchains donde un nodo tiene un papel coordinador predecible, aislarlo mediante pérdida de 75% de paquetes entrantes y salientes durante su turno bastó para detener o degradar el progreso global.

En Aptos, el efecto fue severo. La red dejó de confirmar transacciones poco después de iniciarse el ataque y permaneció así hasta que terminó la ventana de aislamiento. Luego apareció un fuerte pico de tráfico saliente y una recuperación lenta, señal de que el sistema había acumulado un importante rezago. Los registros mostraron mensajes de presión en Quorum Store y ausencia de ejecución de bloques durante el aislamiento.

El paper Blockchain Communication Vulnerabilities, de Andrei Lebedev y Vincent Gramoli, sostiene que el sistema de selección de líderes basado en reputación no impidió este problema, porque los líderes sucesivos podían predecirse y atacarse uno a uno. En otras palabras, comprometer temporalmente a un solo nodo por turno terminó siendo suficiente para ralentizar a toda la red.

Solana también se detuvo mientras su líder era aislado. La diferencia es que logró recuperarse con rapidez una vez terminado el ataque, ya que el siguiente líder de la programación pudo reanudar la producción y limpiar el rezago. Avalanche, en cambio, no se detuvo por completo bajo este ataque, pero sí sufrió aumentos de latencia y persistencia de degradación después del evento.

Qué significa este estudio para el sector

El trabajo deja una conclusión central: no existe una sola blockchain claramente inmune a condiciones adversas de red. Cada arquitectura presenta compensaciones distintas. Algunas ocultan a sus validadores, otras los exponen pero aplican límites, y otras privilegian la velocidad de propagación con técnicas más avanzadas. Aun así, todas mostraron algún punto débil bajo al menos uno de los ataques aplicados.

También resalta la importancia de la capa de transporte. Solana, con QUIC y erasure coding, mantuvo una resiliencia superior ante pérdida de paquetes en comparación con varias redes basadas en TCP. Ese hallazgo podría influir en futuros diseños de infraestructura blockchain, sobre todo en entornos donde la conectividad es irregular o puede ser objeto de manipulación.

Los autores notificaron sus hallazgos a los equipos de desarrollo y seguridad de Algorand, Aptos, Avalanche, Solana y Redbelly antes de la publicación. Según el estudio, Anza confirmó que Solana experimenta vulnerabilidades. El sistema experimental empleado por los investigadores fue descrito como open source.

Para el ecosistema cripto, la lectura es clara. Medir TPS o costo por transacción ya no basta si la conversación gira en torno a seguridad operativa real. En redes abiertas, la comunicación entre nodos es parte del perímetro de defensa. Y cuando ese perímetro falla, la promesa de disponibilidad puede desvanecerse mucho más rápido de lo que sugieren los documentos técnicos.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín