Durante este tiempo he estado siguiendo de cerca el incidente de seguridad del puente de Dusk, y cuanto más investigo, más puntos encuentro que merecen un análisis profundo.
El ataque del 16 de enero de 2026 consistió, en esencia, en que el atacante obtuvo acceso a los permisos de la cartera de firmas del puente entre Dusk y EVM. Aquí es importante delimitar claramente lo ocurrido: el problema afectó a los permisos de la cartera caliente del puente, no se vulneró la capa de consenso de DuskDS ni había una vulnerabilidad de código en el protocolo subyacente. @Dusk La postura oficial también fue clara: no se trató de un fallo de consenso ni de un defecto de seguridad del protocolo nativo de Dusk.
Dusk siempre ha destacado su arquitectura por capas: la capa de consenso DuskDS, la capa de liquidación y la capa de ejecución EVM son independientes. Este diseño modular parece flexible y ofrece redundancia de seguridad. Sin embargo, el riesgo en este caso no estuvo en esos módulos centrales de la cadena, perfeccionados una y otra vez, sino en los puntos de conexión donde se mueven los activos: los servicios del puente entre cadenas, las carteras de firmas y los entornos de ejecución.
El ataque comenzó oficialmente esa noche a las 21:28. El atacante fue transfiriendo fondos de forma sostenida en varias operaciones: 2,74 millones, 1,91 millones y 8,06 millones de DUSK fueron sustraídos sucesivamente. No fue hasta que el equipo recibió un aviso interno de actividad anómala, a las 23:12, que cerró urgentemente el servicio del puente. Así se bloqueó la última operación entre cadenas, de 8,91 millones de DUSK. Según lo divulgado, parte de los fondos robados ya había llegado a una dirección de Binance a través de BSC.
Lo más interesante de este caso es que cuanto más estratificada y modular es la arquitectura de un sistema, más independientes son los modelos de riesgo de sus componentes y, paradójicamente, más fácil resulta que queden puntos ciegos de confianza en las zonas de conexión. El puente entre cadenas afectado se creó precisamente como un servicio integrado y ligero para agilizar las operaciones entre cadenas y simplificar los procesos. Los permisos de firma, la monitorización de eventos y la interacción con la red estaban concentrados en un mismo flujo. En cuanto se perdió el control de la cartera de firmas, toda la vía de transferencia de fondos quedó completamente comprometida. $DUSK
La pregunta más importante es: cuando los activos salen de la capa de liquidación nativa y se conectan con sistemas externos, ¿cuántos supuestos de confianza centralizada nuevos se incorporan? Los puentes entre cadenas, las carteras de custodia y los servicios de middleware —esos «componentes periféricos» que parecen insignificantes— son precisamente los que vuelven a situar los activos descentralizados en una zona de riesgo basada en la confianza humana. ¿Qué opinas, frente a otras ventajas que suelen promocionarse, como la privacidad y el rendimiento?
#dusk @Dusk $DUSK
El ataque del 16 de enero de 2026 consistió, en esencia, en que el atacante obtuvo acceso a los permisos de la cartera de firmas del puente entre Dusk y EVM. Aquí es importante delimitar claramente lo ocurrido: el problema afectó a los permisos de la cartera caliente del puente, no se vulneró la capa de consenso de DuskDS ni había una vulnerabilidad de código en el protocolo subyacente. @Dusk La postura oficial también fue clara: no se trató de un fallo de consenso ni de un defecto de seguridad del protocolo nativo de Dusk.
Dusk siempre ha destacado su arquitectura por capas: la capa de consenso DuskDS, la capa de liquidación y la capa de ejecución EVM son independientes. Este diseño modular parece flexible y ofrece redundancia de seguridad. Sin embargo, el riesgo en este caso no estuvo en esos módulos centrales de la cadena, perfeccionados una y otra vez, sino en los puntos de conexión donde se mueven los activos: los servicios del puente entre cadenas, las carteras de firmas y los entornos de ejecución.
El ataque comenzó oficialmente esa noche a las 21:28. El atacante fue transfiriendo fondos de forma sostenida en varias operaciones: 2,74 millones, 1,91 millones y 8,06 millones de DUSK fueron sustraídos sucesivamente. No fue hasta que el equipo recibió un aviso interno de actividad anómala, a las 23:12, que cerró urgentemente el servicio del puente. Así se bloqueó la última operación entre cadenas, de 8,91 millones de DUSK. Según lo divulgado, parte de los fondos robados ya había llegado a una dirección de Binance a través de BSC.
Lo más interesante de este caso es que cuanto más estratificada y modular es la arquitectura de un sistema, más independientes son los modelos de riesgo de sus componentes y, paradójicamente, más fácil resulta que queden puntos ciegos de confianza en las zonas de conexión. El puente entre cadenas afectado se creó precisamente como un servicio integrado y ligero para agilizar las operaciones entre cadenas y simplificar los procesos. Los permisos de firma, la monitorización de eventos y la interacción con la red estaban concentrados en un mismo flujo. En cuanto se perdió el control de la cartera de firmas, toda la vía de transferencia de fondos quedó completamente comprometida. $DUSK
La pregunta más importante es: cuando los activos salen de la capa de liquidación nativa y se conectan con sistemas externos, ¿cuántos supuestos de confianza centralizada nuevos se incorporan? Los puentes entre cadenas, las carteras de custodia y los servicios de middleware —esos «componentes periféricos» que parecen insignificantes— son precisamente los que vuelven a situar los activos descentralizados en una zona de riesgo basada en la confianza humana. ¿Qué opinas, frente a otras ventajas que suelen promocionarse, como la privacidad y el rendimiento?
#dusk @Dusk $DUSK