En las últimas semanas, los usuarios del protocolo EOS blockchain han experimentado problemas periódicos con el acceso a la red. Un reciente artículo escrito por el seudónimo desarrollador de contratos inteligentes y el ingeniero de seguridad Dexaran describió la raíz aparente del problema: una técnica económica que permite a los piratas informáticos "congestionar" la red, o ponerla en un modo de baja eficiencia, con solo unos pocos dólares en EOS .
Aparentemente, esa hazaña permitió a un hacker robar más de $ 110,000 en criptomonedas de una aplicación de juego EOS, EOSPlay, a principios de septiembre. Sin embargo, los ejecutivos de la empresa matriz de EOS, Block.one, no están desconcertados, argumentando que la red está funcionando "correctamente".
Conceptos básicos de EOS: modo de gobierno, replanteo y congestión
EOS.io es un protocolo de contrato inteligente impulsado por blockchain para el desarrollo y alojamiento de aplicaciones descentralizadas (DApps). Emplea un modelo de consenso denominado prueba de participación delegada (DPoS) y se rige de conformidad con el Acuerdo de usuario de EOS (EUA)
Según el acuerdo, se pueden realizar cambios en la red cuando hay un consenso entre al menos 15 de los 21 productores de bloques, entidades independientes que son responsables de procesar bloques en la cadena de bloques EOS.
El protocolo es compatible con su criptomoneda nativa homónima, actualmente el séptimo activo más grande por capitalización de mercado total. Esos tokens son el núcleo del mecanismo de replanteo de recursos incorporado, una de las características distintivas de EOS. Cada vez que se envía una transacción a la red EOS, los productores de bloques deben procesarla.
El período de tiempo (medido en microsegundos) que requiere un productor de bloques para validar la transacción se denomina CPU. En pocas palabras, los usuarios y desarrolladores de EOS pueden obtener acceso a recursos de ancho de banda y CPU en toda la cadena al apostar sus tokens. Los bloques se producen cada 500 milisegundos. Cada productor de bloques tiene 200 milisegundos para validar el bloque. Los 300 milisegundos restantes se dejan para distribuir a través de la red.
En particular, dentro del límite de 200 milisegundos, también hay un umbral porcentual en el que comienza la limitación de velocidad en toda la red. En otras palabras, cuando un bloque alcanza el límite del 10% del total de 200 milisegundos de CPU permitidos por bloque, se disparadores el algoritmo de asignación de CPU para entrar en modo de "congestión".
"Antes de alcanzar este límite, todos los usuarios pueden realizar transacciones libremente en la red, ya que no está en" modo de congestión "," el autor del artículo explicado. "Una vez que se supera este límite, los usuarios vuelven a su cuota proporcional de la asignación total de CPU por estaca EOS".
Según otro articulo escrito por EOS Canada, un importante productor de bloques en la red de blockchain de EOS, si hubiera 1,000 tokens apostados para CPU en un momento dado, y una sola cuenta tuviera 20 tokens apostados, entonces esa cuenta tendría garantizado el 2% del total de la CPU capacidad de la red.
Sin embargo, si la red no ha alcanzado el umbral al que se activa la limitación de velocidad (no en modo de "congestión"), permite que la cuenta empuje las transacciones por encima de su cantidad garantizada del 2%. Una vez que se pasa ese umbral, la cuenta no puede exceder la asignación. Además, durante la fase de "congestión", la cantidad de CPU de cada usuario comienza a disminuir hasta que cada parte congestionada se queda sin CPU y deja de tomar acciones que consumen CPU.
Daniel Larimer, cofundador de EOS y director de tecnología de Block.one, se refiere a este mecanismo como un "beneficio gratuito" de la red:
“Poseer y replantear #eos brinda a los usuarios una parte prorrateada del ancho de banda disponible. Cuando las personas no usan su parte, se redirige a otros de forma prorrateada. Durante el uso intensivo, los usuarios ya no reciben este beneficio gratuito ".
Problema: el modo de congestión es demasiado fácil de activar
El problema, argumentó Dexaran, es que el modo de congestión es demasiado fácil de activar. Después del análisis, el desarrollador de contratos inteligentes notó importantes picos de uso de la CPU al comienzo de cada hora, supuestamente causados por un DApp de apuestas llamado EOSBetDice. Dexaran luego decidió evaluar la cantidad de CPU que se necesita para empujar la red a la congestión.
Para el experimento, el desarrollador apostó 7.156 EOS para CPU. Esa cantidad de EOS se puede tomar prestada de los intercambios de recursos al bajo costo de dos EOS por mes (menos de $ 6), enfatizó Dexaran. Para ver cómo la prueba afectaría a los usuarios promedio de la red EOS, el ingeniero de seguridad preseleccionó tres cuentas de usuario aleatorias que estaban en línea jugando a la aplicación EOSKnights DApp justo antes de que comenzara la sesión.
Luego, el desarrollador ejecutó un contrato que generó muchas transacciones diferidas con un retraso de un segundo, y cada transacción consumió "25 a 27 ms de CPU". Después de monopolizar la utilización de la CPU durante un minuto entero, el contrato llevó a la red EOS a la congestión modo. Como resultado, las tres cuentas de muestra estaban sin CPU y, por lo tanto, se "congelaron por completo", lo que básicamente significa que todos los usuarios casuales de EOS no pudieron interactuar con ninguna DApps en la red en ese momento.
Dos minutos más tarde, la EOSBetDice DApp mencionada anteriormente, que causaba picos regulares de CPU cada hora, independientem ente del experimento, comenzó a funcionar según el cronograma. Al consumir aún más CPU de la red en el momento en que ya estaba sobrecargado, contribuyó involuntariamente a la congestión iniciada por Dexaran. "Mientras más CPU consumas en una fila, mayor será el modo de congestión y más tardará la red en recuperarse a su modo normal", señaló el desarrollador.
Como resultado, la red EOS entró en una congestión aún más "profunda" y, según los informes, la disponibilidad de CPU se redujo en 35 veces para todos los usuarios de EOS. "No importa cuánto EOS haya apostado por la CPU, si ha usado más del 3%, entonces estaría congelado", observó Dexaran.
Después de que el contrato de Dexaran y EOSBetDice enfatizaron la red durante un total de cinco minutos, la red aparentemente quedó paralizada durante los siguientes 10 minutos. Después de que pasaron seis minutos más, se había recuperado en gran medida, pero el precio de préstamo de EOS en los intercambios de recursos aún era aproximadamente tres veces más alto de lo normal, lo que indica que la red requería grandes cantidades de tokens asignados en la CPU en el momento debido a la prueba de esfuerzo.
La red se restauró por completo solo 30 minutos después de la última acción "maliciosa". Eso les da a los usuarios "una ventana de 25 minutos hasta la próxima sesión de congestión", señaló Dexaran, ya que el ataque se puede realizar cada hora, según las estimaciones del desarrollador. "7000 EOS es suficiente para llevar la red EOS a un modo de congestión durante un tiempo decente", concluyó el investigador, y agregó:
“La sesión de congestión descrita solo causará problemas a (1) usuarios que gastaron una cierta parte de su ancho de banda de CPU, (2) usuarios con un ancho de banda de CPU muy bajo en juego. La sesión de congestión descrita no tiene impacto en (1) DApps que tienen mucha CPU disponible, (2) usuarios que no participan en ninguna actividad y tienen su CPU totalmente disponible (suponiendo que estos usuarios tengan suficiente CPU para hacer un solo tx ) ".
Además, Dexaran enfatizó que, si bien algunos usuarios de EOS podrían llamarlo "hacker" debido a una sobrecarga intencional de la red, "estoy haciendo exactamente lo contrario: estoy protegiendo mis inversiones y las suyas".
Notablemente, un par de días antes de la publicación de Dexaran sobre la congestión de EOS, el desarrollador Christoph Michel escribió una publicación de blog vinculando el reciente truco del casino EOSPlay con la congestión de la red, por lo tanto, muestra cómo se puede explotar el problema de la red para obtener ganancias.
Según Michel, el atacante alquiló tokens EOS de REX, un mercado de alquiler de recursos de CPU y NET, y luego los apiló para aumentar tanto su CPU como la de EOSPlay para garantizar que el casino permaneciera funcional, por lo tanto, puede pagar sus apuestas. Luego, el pirata informático envió spam a la red con transacciones similares a Dexaran, y jugó varios juegos de dados en EOSPlay, apostando por un resultado 50/50. Dado que EOSPlay mira el hash de bloque del bloque de resultados y toma los dos primeros caracteres, comenzando por la derecha y entre cero y nueve, como el dado, uno tiene que predecir el hash de bloque del bloque de resultados para ganar el juego.
"Las únicas incógnitas en la predicción son las transacciones incluidas en los bloques", explicó Michel. "¿Pero qué pasaría si uno pudiera simplemente enviar spam y congestionar la red para que nadie más pueda enviar transacciones?"
Según el desarrollador, esa es exactamente la razón por la cual el atacante tomó prestado EOS para enviar spam a la red: tener control sobre la red y, por lo tanto, ser capaz de predecir los bloqueos hashes y ganar la mayoría de sus apuestas. En caso de una predicción incorrecta, el atacante podría enviar otra transacción aleatoria al bloque y, por lo tanto, tener un "lanzamiento de moneda" adicional, mejorando en gran medida las probabilidades.
Finalmente, el hacker usó solo 300 EOS, con un valor de poco más de $ 1,000, que podría haber alquilado por un par de dólares. A cambio, la cantidad ganadora fija trajo más de 30,000 EOS, o alrededor de $ 110,000.
Los desarrolladores de EOS se aseguran de que la red esté "funcionando correctamente", no todos están de acuerdo
Los experimentos de congestión de Dexaran no han pasado desapercibidos, ya que varios usuarios han informado que tienen "problemas de CPU" en Gorjeo y Reddit. Denis Bredikhin, CEO de Graphene Lab, un equipo de desarrolladores de contratos inteligentes, confirmó a Cointelegraph que los usuarios de su aplicación de apuestas EOS basada en póker también ha experimentado problemas en las últimas semanas, aunque la aplicación en sí no se vio comprometida. Bredikhin dijo:
"En el pico del spam, los jugadores, incluso con 8-10 mil EOS asignados a la CPU, no podían realizar ninguna operación".
Según él, a partir del 1 de octubre, los jugadores deben asignar "hasta 10,000 EOS" en la CPU para que el juego no se detenga durante las sesiones de spam. Mientras tanto, Larimer de Block.one se ha dirigido a Twitter para asegurar a la comunidad que EOS está "funcionando correctamente". escribió:
"Esto no es diferente de cuando los atacantes inundan eth o bitcoin con spam de transacciones de altas tarifas. La red no se congeló para los titulares de tokens, simplemente no había ancho de banda adicional disponible para uso gratuito ".
Sin embargo, algunos miembros de la comunidad piden diferencias. "La diferencia entre este ataque en EOS y un correo no deseado de alta tarifa en BTC o ETH es que aún puede pagar más para enviar una transacción en BTC o ETH". argumentó Rob Finch, CEO del productor estadounidense de bloques EOS CypherGlass. Él agregó:
“Muchos usuarios de EOS no tenían suficiente CPU para alquilar más CPU, por lo que se congeló para ellos. Operar correctamente "no es la mejor respuesta de la OMI".
Otro usuario de EOS, el empresario de blockchain Jared Moore, confirmado que la red era inutilizable para DApps o su billetera. También se preguntó si Block.one "ayudaría a la comunidad EOS y publicaría pautas sobre cómo prevenir los ataques REX".
Cointelegraph se ha comunicado con Block.one para obtener más comentarios y actualizará el artículo una vez que se obtenga más información.