Fui a ver el flujo de migración del puente Dusk esperando que la parte interesante fuera el contrato EVM. Resultó que detrás de eso estaba el firmante.
El contrato de migración en sí era bastante sencillo. Los usuarios bloquearon ERC20 o BEP20 DUSK y se emitió un evento de migración. Pero ese evento no creó mágicamente DUSK nativo. Un servicio externo tuvo que observarlo y volver a emitir los fondos en Dusk.
Esa distinción importa más de lo que parece al principio.
La arquitectura más amplia de Dusk se estaba moviendo hacia un modelo de puente nativo, en el que el valor pudiera moverse entre DuskDS y DuskEVM sin activos envueltos ni custodios externos. Sin embargo, la ruta de migración más antigua todavía dependía de una wallet de firma operativa para convertir un evento EVM observado en una transacción real de Dusk.
Los datos del incidente hacen visible esa dependencia. El 16 de enero, un atacante comprometió esa wallet y luego movió el DUSK robado a través de la ruta del puente. La secuencia incluyó 7,880 DUSK puenteados y posteriormente otros 1.91 millones de DUSK antes de que la mitigación detuviera un intento adicional de 8.91 millones de DUSK.
Lo que me parece importante no es simplemente que se haya comprometido una wallet.
Es que la ingesta del evento y la liberación del valor estaban efectivamente conectadas mediante una única ruta operativa. Un contrato inteligente puede ser determinista, mientras que el sistema que lo rodea todavía depende de la custodia de claves, el aislamiento del servidor, la supervisión y el manejo de transacciones.
Por lo tanto, el rediseño que separa la ingesta de eventos de la firma y convierte los eventos de migración en trabajos persistentes es más que un parche de seguridad. Cambia dónde vive la confianza.
Al leer esto, pensé de manera diferente sobre los puentes. El contrato suele ser la parte que inspeccionamos primero, pero el verdadero límite de confianza puede estar a varios niveles detrás del contrato, dentro del software que decide cuándo un evento se convierte en dinero.
#dusk $DUSK @Dusk
El contrato de migración en sí era bastante sencillo. Los usuarios bloquearon ERC20 o BEP20 DUSK y se emitió un evento de migración. Pero ese evento no creó mágicamente DUSK nativo. Un servicio externo tuvo que observarlo y volver a emitir los fondos en Dusk.
Esa distinción importa más de lo que parece al principio.
La arquitectura más amplia de Dusk se estaba moviendo hacia un modelo de puente nativo, en el que el valor pudiera moverse entre DuskDS y DuskEVM sin activos envueltos ni custodios externos. Sin embargo, la ruta de migración más antigua todavía dependía de una wallet de firma operativa para convertir un evento EVM observado en una transacción real de Dusk.
Los datos del incidente hacen visible esa dependencia. El 16 de enero, un atacante comprometió esa wallet y luego movió el DUSK robado a través de la ruta del puente. La secuencia incluyó 7,880 DUSK puenteados y posteriormente otros 1.91 millones de DUSK antes de que la mitigación detuviera un intento adicional de 8.91 millones de DUSK.
Lo que me parece importante no es simplemente que se haya comprometido una wallet.
Es que la ingesta del evento y la liberación del valor estaban efectivamente conectadas mediante una única ruta operativa. Un contrato inteligente puede ser determinista, mientras que el sistema que lo rodea todavía depende de la custodia de claves, el aislamiento del servidor, la supervisión y el manejo de transacciones.
Por lo tanto, el rediseño que separa la ingesta de eventos de la firma y convierte los eventos de migración en trabajos persistentes es más que un parche de seguridad. Cambia dónde vive la confianza.
Al leer esto, pensé de manera diferente sobre los puentes. El contrato suele ser la parte que inspeccionamos primero, pero el verdadero límite de confianza puede estar a varios niveles detrás del contrato, dentro del software que decide cuándo un evento se convierte en dinero.
#dusk $DUSK @Dusk