#dusk Anoche comparé @Dusk con el análisis AEGIS y el repaso de seguridad que se publicó este año, y la sensación más evidente es que la seguridad no puede medirse solo por la cantidad de informes de auditoría. Dusk había publicado anteriormente varios informes de auditoría sobre criptografía, consenso, máquina virtual y contratos de migración, pero la revisión interna de 2026 aún corrigió 39 problemas, de los cuales 7 fueron clasificados como graves. Estos involucran el aislamiento de la máquina virtual, la deserialización, el vínculo entre las comisiones y los reembolsos de Phoenix, las firmas BLS y otros puntos fundamentales, afectando no solo a una página concreta, sino posiblemente a la coherencia de la ejecución, la integridad del suministro y la disponibilidad de la red.
La parte positiva es que el proyecto proporcionó las causas, las rutas de explotación y las direcciones de corrección, y afirmó que por el momento no se ha detectado que los problemas graves fueran explotados antes de ser reparados. La parte negativa también es clara: que una red principal haya salido al aire y haya pasado por varias rondas de auditoría no significa que las hipótesis críticas ya estén completamente agotadas. Especialmente cuando se combinan conocimiento cero, máquina virtual y consenso, un error en una comprobación de límites puede amplificarse a través de múltiples capas.
El incidente del puente merece analizarse por separado. El 16 de enero, lo comprometido fue la billetera de firmas utilizada por el servicio del puente, no el consenso de DuskDS; el importe robado que aparece en la cronología pública suma aproximadamente 1091万枚$DUSK , de los cuales unas 1,92 millones de monedas se transfirieron mediante el puente a BSC, y el último intento de puenteo de 8,91 millones de monedas falló después de que el servicio se detuviera. La posterior reorganización separó la firma, la recepción de eventos y la liberación de fondos, además de reducir la exposición de la billetera caliente. Esa dirección es razonable, pero también demuestra que “el protocolo no se rompió” no borra el riesgo económico real asumido por los servicios periféricos.
Por eso no voy a invalidar Dusk por un solo incidente, ni a cerrar el juicio con un simple “ya está corregido”. Lo que hay que vigilar después es la cobertura de las versiones corregidas, el límite de fondos del puente, el aislamiento de claves, la revisión externa y la velocidad de respuesta ante anomalías. La seguridad no consiste en tener o no tener informes, sino en si, después de un error, se puede cerrar de verdad la ruta de ese mismo tipo.
$CHIP $ETH
La parte positiva es que el proyecto proporcionó las causas, las rutas de explotación y las direcciones de corrección, y afirmó que por el momento no se ha detectado que los problemas graves fueran explotados antes de ser reparados. La parte negativa también es clara: que una red principal haya salido al aire y haya pasado por varias rondas de auditoría no significa que las hipótesis críticas ya estén completamente agotadas. Especialmente cuando se combinan conocimiento cero, máquina virtual y consenso, un error en una comprobación de límites puede amplificarse a través de múltiples capas.
El incidente del puente merece analizarse por separado. El 16 de enero, lo comprometido fue la billetera de firmas utilizada por el servicio del puente, no el consenso de DuskDS; el importe robado que aparece en la cronología pública suma aproximadamente 1091万枚$DUSK , de los cuales unas 1,92 millones de monedas se transfirieron mediante el puente a BSC, y el último intento de puenteo de 8,91 millones de monedas falló después de que el servicio se detuviera. La posterior reorganización separó la firma, la recepción de eventos y la liberación de fondos, además de reducir la exposición de la billetera caliente. Esa dirección es razonable, pero también demuestra que “el protocolo no se rompió” no borra el riesgo económico real asumido por los servicios periféricos.
Por eso no voy a invalidar Dusk por un solo incidente, ni a cerrar el juicio con un simple “ya está corregido”. Lo que hay que vigilar después es la cobertura de las versiones corregidas, el límite de fondos del puente, el aislamiento de claves, la revisión externa y la velocidad de respuesta ante anomalías. La seguridad no consiste en tener o no tener informes, sino en si, después de un error, se puede cerrar de verdad la ruta de ese mismo tipo.
$CHIP $ETH
