La crfiptomoneda centrada en pagos orientada a la privacidad, Dash se sometió a un ataque «buscado» seguido de una serie de pequeñas transacciones que totalizaron casi 1 millón de transacciones de 1 entrada/1 salida con una tarifa apenas superior a 1 duff por byte. Las transacciones no fueron anticipadas, lo que llevó a la mayoría de la comunidad a sospechar un ataque, pero nadie lo sabe con certeza. Según los desarrolladores de Dash Core, podría ser un intento de ataque o un desarrollador fuera de la Comunidad Dash que estaba realizando una prueba de estrés. De cualquier manera, causó estragos en la red con varias transacciones legítimas sin confirmar durante varias horas.
Después de este ataque, el Grupo Dash Core realizó una investigación improvisada para comprender la naturaleza del «ataque» y lanzó una serie de descubrimientos. El viernes, el DCG lanzó un parche para el software Dash para ayudar a abordar las vulnerabilidades que podrían haber permitido que el atacante causara el estancamiento de la red. Estas son algunas de las cosas que DCG descubrió sobre su red:
- Algunos grupos tienen un límite de bloques de 1 MB: varios grupos de minería en la red Dash habían implementado límites de tamaño de transacción de 1 MB, lo que llevó a la congelación después de la oleada de transacciones que la red experimentó el día 7.
- Algunos grupos parecen no estar vaciando la mempool y están produciendo bloques casi vacíos: los grupos mineros parecían priorizar el bajo tamaño y las bajas transacciones que realizaba el «atacante», mientras que varias de las transacciones legítimas se estancaban en la mempool.
- Algunos Masternodes se bloquearon debido a la falta de espacio de almacenamiento suficiente: debido al aumento significativo de las transacciones, varios nodos maestros alcanzaron sus límites de espacio de almacenamiento de aproximadamente 15-20 GB, ya que tuvieron que guardar los bloqueos InstantSend (IS) para cada transacción. Esto llevó a algunos de ellos a fallar debido a que los límites de espacio se maximizaban
- Algunos Masternodes prohibieron a otros Masternodes bajo una carga alta cuando se encontraba al borde de un nuevo quórum activo, similar al punto anterior, ya que algunos nodos maestros se bloquearon y pocos no tenían límites de espacio dejaron funcionar bajo un mayor estrés que llevó al agotamiento de los nodos. Como explicó el DCG, «este problema resultó en que algunos bloques no recibieran un ChainLock y algunas transacciones no recibieran IS Locks».
- Algunas transacciones de usuarios no se incluyeron en un bloque rápidamente ya que utilizaron la tarifa predeterminada: los usuarios de Dash Core Wallet predeterminados tuvieron sus transacciones durante el ‘ataque’ atascadas en la mempool mientras las transacciones se enviaban sin ajustes a los requisitos de tráfico de la red.
La nueva actualización, lanzada el viernes por DCG ayudará a abordar la mayoría de estas inquietudes y aquí hay un resumen de las soluciones presentes en Dash Core v.0.14.0.3.
- Mejoras en el uso del espacio de la base de datos
- Fallos de firma de DKG y LLMQ corregidos
- Binarios firmados para Windows
- MacOS: deshabilita AppNap durante la sincronización y la mezcla
- Nuevo comando RPC: quórum memberof <proTxHash>
- Más información sobre la cantidad de bloqueos InstantSend
No se informaron pérdidas después de que se abordara el ataque la semana pasada, pero los desarrolladores principales tuvieron el duro trabajo de despertar la red para garantizar que dicho ataque no se repita en el futuro. Dependiendo de cómo lo mire, este podría haber sido un pirata informático blanco que obligó a DCG a innovar y construir una red más segura o un intento fallido de causar estragos. De cualquier manera, la red es más segura ahora que antes del ataque, pero todavía hay margen para mejoras.
