Desafíos y soluciones de la Web 3.0: spam de transacciones en blockchain por NKN #NKN mayo, 2022

mucho spam

Muchas cadenas de bloques públicas de capa 1 (Solana, Near, Avalanche, Harmony) que compiten contra Ethereum prometen la combinación de un rendimiento extremadamente alto (transacción por segundo), baja latencia (finalidad rápida) y bajo costo (tarifa de transacción baja). Por lo general, hay algunas trampas, por ejemplo, sacrificar la seguridad o la descentralización de acuerdo con el trilema de escalamiento de blockchain de Vitalik.

El spam de transacciones, o Tx spamming, es uno de los ataques de seguridad persistentes en estas cadenas de bloques de alto rendimiento que pueden causar estragos durante largos períodos de tiempo. Los atacantes pueden o no obtener algún beneficio financiero, pero ciertamente pueden hacer que la vida de todos sea bastante miserable a un costo relativamente bajo.

Inundaciones de muy bajo costo (Fuente: Wiki de Bitcoin)

Un ataque simplista que la gente suele intentar es enviar decenas de miles de transacciones de tarifa cero o muy baja a la vez. Esto hace que el número de “mempool” que muestran algunos sitios web suba masivamente, lo que a veces hace que la gente entre en pánico, pero en realidad es solo una pequeña pérdida de los recursos de ancho de banda de la red, y apenas es un problema. Las transacciones con tarifas muy bajas nunca se confirmarán y, por lo general, caducan de los mempools de los nodos ((una cola temporal de transacciones para procesar) después de unos días.

Además, el spam Tx también se puede considerar como una forma de denegación de servicio distribuida (DDOS).

Concurso de detección de metales en la playa

Las transacciones de spam pueden ser maliciosas o no intencionales (por ejemplo, error de código de contrato inteligente). Incluso podría ser una prueba de rendimiento de un tintineo curioso. Y no es factible erradicar el tráfico de spam. Entonces, ¿cómo detectamos que hay spam grave en la red?

Ignore los picos de tráfico a corto plazo, algunos de los síntomas de que la red está bajo ataques de spam son (en orden de gravedad):

El tráfico en cadena y el tamaño de la base de datos de blockchain están creciendo más rápido de lo habitual. Esto podría ser gradual y acumularse durante un período de tiempo, por ejemplo, semanas o meses. Lleva mucho más tiempo completar una transacción normal, por ejemplo, transferencia de activos. los nodos load y stressValidator pierden el consenso y ya no pueden producir bloques válidos, la cadena se detiene

Aunque no es posible predecir y prevenir todos los ataques de spam por adelantado, es importante que los diseñadores de protocolos y los desarrolladores de proyectos tengan un sistema activo de monitoreo y alerta temprana.

Alguien dijo que “no existe tal cosa como una transacción ilegal en blockchain”. Si una transacción se forma correctamente de acuerdo con la especificación, se aceptará en el mempool del nodo API, se transmitirá a la red, un minero potencialmente la empaquetará en un bloque, se validará y se aceptará en la cadena de bloques.

La pregunta clave es cómo priorizar las transacciones productivas sobre las transacciones de spam. Existen soluciones técnicas y económicas para el problema del spam Tx. Y aquí hay una lista de soluciones comunes. Tenga en cuenta que muchas cadenas de bloques ya implementan parte de la priorización de Tx, por lo que la solución puede ser una combinación de implementar nuevas funciones y ajustar los parámetros para las funciones existentes.

Prioridad basada en las tarifas de transacciónPrioridad basada en el rendimientoPrioridad basada en la reputaciónFiltrado posterior al hecho

Dado que la tercera solución no se usa mucho y la cuarta solución solo es relevante para los datos históricos, solo nos centraremos en las dos primeras soluciones en este artículo.

Guerra de subastas

La primera opción, aumentar la tarifa mínima de Tx, es una solución sencilla y natural. Dado que los spammers de Tx enviarán miles, millones o incluso miles de millones de transacciones de bajo costo o sin cargo, aumentar la tarifa mínima de Tx solo un poco podría volverse prohibitivamente costoso para el atacante. Si bien un aumento tan pequeño podría no tener ningún impacto material en los usuarios legítimos de la red.

Hay argumentos para no introducir una tarifa de transacción mínima distinta de cero, por ejemplo, para simplificar la incorporación de usuarios de dApps con una billetera de saldo cero. Sin embargo, los diseñadores de protocolos pueden introducir una cantidad máxima configurable de transacciones “gratuitas” que aceptará un nodo minero. Esto podría funcionar de alguna manera, pero se sabe que los spammers de Tx abusan de estas transacciones “gratuitas” y hacen que el esquema sea casi inútil.

Línea de procesamiento en fábrica de conservas

Nodos de consenso o nodos mineros, soportar la mayor parte de la carga para el procesamiento de transacciones. Aumentar su capacidad puede tener un impacto directo. Aumentar la potencia de procesamiento sin procesar, como más núcleos de CPU, más RAM, más almacenamiento SSD y más rápido y conexiones a Internet de mayor capacidad y menor latencia.

Algunos nodos de consenso en la red blockchain tienen funcionalidad adicional, como servidor RPC para el acceso a la API de la cadena de bloques, además de almacenar y proporcionar datos históricos para los navegadores de la cadena de bloques. Estos también pueden convertirse en cuellos de botella, si no se aprovisionan correctamente para la carga o si hay ineficiencias en la E/S, el esquema de la base de datos o la lógica comercial. Solucionar esos problemas puede mejorar la usabilidad de las dApps, que dependen de estos servicios, durante una tormenta de spam Tx.

Otra opción más es hacer priorizar las transacciones con un tamaño de datos más pequeño sobre un tamaño más grande, si las tarifas de Tx fueran más o menos iguales. De esta manera, podemos reducir la carga no solo en el tamaño final de la base de datos de blockchain, sino también reducir la carga de procesamiento en los nodos mineros.

Polígono/Matic

Qué pasó:

Con un precio bajo de 1 gwei en gasolina, se necesitan alrededor de $ 1,000 para llenar todos los bloques durante un día completo. Por lo tanto, dos bots comerciales de arbitraje han estado enviando spam a la red Polygon con aproximadamente 2 millones de transacciones diarias, lo que representa aproximadamente el 30 % del recuento total de transacciones de la red.

Según una investigación, los dos bots de arbitraje podrían estar obteniendo un promedio de $6800 en ganancias diarias de esta operación.

¿Qué hizo el equipo?

El equipo propuso aumentar la tarifa mínima de tx de 1 gwei a 30 gwei.

Secuelas

Poco después del ajuste, las transacciones de spam cayeron un 75 %, de 2 millones a solo 500 000 transacciones por día. Y las transacciones diarias totales en la red Polygon casi se redujeron a la mitad de aproximadamente 6 millones a 3 millones.

Protocolo Solana

Qué pasó:

El 14 de septiembre, la red de Solana estuvo desconectada durante 17 horas. Un tipo de DDOS que utiliza grandes cantidades de transacciones de spam fue el culpable.

“A las 12:00 UTC, Grape Protocol lanzó su IDO en Raydium y los bots generaron transacciones que inundaron la red. Estas transacciones crearon un desbordamiento de memoria, lo que provocó que muchos validadores fallaran, lo que obligó a la red a ralentizarse y, finalmente, bloquearse. La red se desconectó cuando la red del validador no pudo llegar a un acuerdo sobre el estado actual de la cadena de bloques, lo que impidió que la red confirmara nuevos bloques”.

Los datos forenses de red para el validador principal de Certus One indican picos de datos de transacciones sin procesar de >1 Gbps y 120 000 paquetes por segundo, esencialmente indistinguibles de un ataque DDoS volumétrico.

que hizo el equipo

La comunidad propuso una bifurcación dura de la red. Y dentro de la bifurcación dura, se implementaron varias correcciones:

Ignore los bloqueos de escritura en los programas, de modo que las transacciones se puedan procesar en paraleloAfine el comportamiento de reintento de RPC, lo que permite que las aplicaciones sean más inteligentes al reintentar transacciones. Prioriza las transacciones de voto (esencial para el algoritmo de consenso), lo que evita que las transacciones regulares “ahoguen” el voto transacciones. Aumente la memoria para los nodos de consenso, para evitar la falta de memoria que detuvo los nodos.

Secuelas

Después de dos reinicios, con el apoyo de la comunidad, la cadena de bloques de Solana restableció su consenso. No se perdieron fondos y la red volvió a su funcionalidad completa en menos de 24 horas.

Protocolo Harmony.One

Qué pasó

A partir del 5 de junio, la cadena de bloques Harmony ha estado recibiendo una gran cantidad de transacciones en nuestra cadena de balizas. Estas transacciones tienen las siguientes características:

Todas estas transacciones son llamadas de contrato inteligente con algunas llamadas estáticas anidadas en la ejecución del código. Aunque estas transacciones provienen de una gran cantidad de direcciones diferentes, las direcciones del receptor están limitadas a cuatro direcciones de contrato. Todas las transacciones no tienen ningún registro de transferencia de token, lo cual es lo más probable es que solo modifique algún valor dentro del almacenamiento del contrato. La cantidad de transacciones es enorme. Alcanzó un máximo de ~150/bloque, que son aproximadamente 40 transacciones por segundo, >5 veces el TPS en Ethereum.

A las 2:30 p. m. PST del 21 de junio de 2021, 4 direcciones habían recibido 18 311 525 transacciones.

Y los impactos son:

Haga que los bloques sean más grandes que nunca, lo que afecta el servicio de sincronización de RPC. En consecuencia, la cadena del fragmento 3 se rompió en el consenso y tuvo un tiempo de inactividad de aproximadamente 2 horas. El historial de transacciones de una sola cuenta puede volverse grande, lo que hace que sea difícil ponerse al día con la base de datos del explorador. Dado que todos los puntos RPC públicos también son nodos exploradores, esto da como resultado que los puntos RPC públicos experimenten cierto nivel de inestabilidad e inexactitud de los datos relacionados con la base de datos del explorador.

que hizo el equipo

El equipo de Harmony llevó a cabo tres actualizaciones de la red principal:

Aumente el límite de gas a 1 gWei para aumentar el costo de enviar spam a las transacciones. Una solución para agregando un caché en memoria para la base de datos del explorador (BD): Enlace. Esto sirve como una solución temporal para facilitar los recursos de la máquina. Un explorador cambio de esquema de base de datos que incluye una migración de base de datos y la nueva lógica de esquema. La idea detrás de esta solución es triturar la información de la dirección masiva en pequeñas entradas, cada una con una dirección y una transacción.

Secuelas

Con las tres correcciones implementadas, la red principal de Harmony vuelve a funcionar normalmente el 18 de junio de 2022.

Red principal de NKN.org

Qué pasó:

Desde principios de marzo, hay una gran cantidad de transacciones de spam con una tarifa de 1e-8 NKN txn. Aunque no detuvo la cadena de bloques ni creó una carga inusualmente alta para los nodos de minería, creó algunas molestias:

Se evitó que algunas transacciones legítimas se confirmaran y empaquetaran en la cadena de bloques. Por ejemplo, el nuevo nodo genera transacciones de identificación, así como transacciones de suscripción grupal. Esto a su vez resultó en: los nuevos nodos de minería no pueden iniciarse (aunque los nodos de minería existentes están bien) y los nuevos usuarios de nMobile y d-chat no pueden unirse al chat público o privado. grupos

que hizo el equipo

En realidad, todos los tipos de transacción afectados ya tienen la opción de especificar una tarifa de transacción distinta de cero. Sin embargo, se establecieron por defecto en cero para mejorar la experiencia del usuario. Así que el equipo implementó lo siguiente:

Cambie la tarifa de tx predeterminada a 0.01 NKN para generar el tipo de transacción de identificación. Aplicaciones nMobile y nConnect actualizadas para agregar una tarifa de Tx configurable por el usuario para suscribirse a un tema. Soporte agregado en la billetera web y móvil para reemplazar la transacción pendiente por una nueva transacción con tarifas de Tx más altas.

Secuelas

Aunque el spam no se detuvo hasta principios de mayo de 2022, no hubo impacto en la funcionalidad normal de la cadena de bloques de NKN ni en las principales aplicaciones que se ejecutan sobre la cadena de bloques de NKN.

Mejores prácticas

¿Existen soluciones integrales óptimas para los ataques de spam de Tx? Desafortunadamente, la respuesta es no. Tal vez ya exista la mejor opción: el mecanismo de tarifa de gas de Ethereum que solicita a cada transacción que pague su parte justa de los costos de computación y almacenamiento. Pero nuevamente volvemos al punto de partida, ¿cómo podemos obtener el alto rendimiento y el bajo costo para las dApps en crecimiento?

La mejor práctica es tener un sistema completo de monitoreo, alerta temprana y mitigación, con una combinación de herramientas que discutimos en este ensayo. Además de eso, los desarrolladores deben tener una comunicación oportuna y clara con todo el ecosistema, y ​​empoderar a la comunidad para ayudar a tomar decisiones económicas y técnicas que puedan minimizar el impacto del spam de transacciones.

¡Y feliz transacción!

https://en.bitcoin.it/wiki/Spam_transactions

https://blog.lopp.net/history-bitcoin-transaction-dust-spam-storms/

https://cryptobriefing.com/spam-attacks-cripto-strategies-for-surplus-transactions/

https://blog.harmony.one/a-defense-against-spamming-transaction-attack-on-harmony-network/

https://coinmarketcap.com/alexandria/article/the-money-making-machine-behind-the-polygon-spam-attacks

https://forum.nkn.org/t/generate-id-with-non-zero-transaction-fee/4628

https://solana.com/news/9-14-network-outage-initial-overview

https://jumpcrypto.com/reflexiones-sobre-el-14-de-septiembre-solana-outage/