Volví a revisar el incidente de los permisos de puente de mediados de enero de 2026 de Dusk. Después de que una cartera de firmas fuera tomada por control, los activos empezaron a salir a su ritmo: primero salieron unos cuantos millones, luego importes del orden de hasta decenas de millones, en transferencias sucesivas, hasta que el equipo cortó el servicio. Al final, el último intento más grande se detuvo. El problema quedó acotado a la capa de puentes; el consenso y el protocolo en sí no se vieron involucrados. Este resultado no fue inesperado, pero me empujó un paso hacia atrás en la confianza predeterminada que tenía en su diseño modular. @Dusk $DUSK
Desde el principio, Dusk separa a propósito el consenso, la liquidación y la ejecución externa; de forma intencional deja DuskDS y la liquidación nativa dentro de un ámbito controlable, y mantiene EVM lo más externo posible. En teoría, si falla una capa, no debería arrastrar directamente a las otras dos. Pero lo que realmente falló fue, precisamente, la ruta ligera que se dejó para ganar velocidad: la firma, los eventos y la red quedaron encadenados; y cuando se rompió un permiso, toda esa línea se detuvo. Cuanto más independiente es la arquitectura, más fácil se vuelve ignorar la zona de confianza humana en los límites. #dusk $BTC
Al revisar la cronología después, la acción de cierre fue efectiva y las pérdidas no se difundieron hasta la propia cadena. Esta “mala” situación, al quedar confinada y detenerse en la interfaz, resulta más fría de lo que esperaba. El aislamiento de Dusk al menos demuestra que la separación puede contener el problema. Pero, una vez que los activos se alejan de la liquidación nativa, vuelven a aparecer nuevas suposiciones de confianza. El coste en los límites no desaparece por un cierre exitoso una sola vez; pero al menos esta vez no se ha demostrado que sea totalmente inútil. Eso ya es suficiente para seguir observando.