#dusk $DUSK @Dusk he estado sentado con la tarea en el movimiento de Dusk en OP Stack por un rato, con un snack en la mano y una cosa no me deja en paz.
DuskEVM ahora corre sobre OP Stack, pasando a asentarse en DuskDS en lugar de quedarse ahí con la clásica ventana de desafío optimista de 7 días a la que todo el mundo está acostumbrado. Dusk lo plantea como una finalidad determinista: sin esperar una semana, sin el purgatorio de las pruebas de fraude. Suena limpio en el papel.
Luego ocurre el 16 de agosto de 2026.
El propio equipo de Dusk detecta actividad sospechosa en una wallet gestionada por el equipo vinculada a operaciones de puente. ¿Respuesta? No entra ninguna prueba de fraude on-chain automáticamente. El equipo deshabilitó y recicló las direcciones de puente afectadas, pausó los servicios del puente manualmente y desplegó una lista negra para Web Wallet de los destinatarios señalados.
O sea... un equipo de operaciones humanas tirando de los mandos, no la capa de settlement haciendo algo sin confianza.
Hmm. No estoy criticando que el arreglo fue rápido, razonable, exactamente lo que querrías. Pero es un recordatorio de que una “ventana sin fallos” es una afirmación sobre la matemática de finalidad de la capa de ejecución, no sobre quién interviene de verdad cuando algo va mal aguas arriba.
La red de seguridad que importó ese día fue un equipo con acceso de admin, no la arquitectura de OP Stack.
Me hizo pausar a mitad de la tarea: en mis notas escribí que “no hay una ventana de 7 días es sin confianza”, y luego lo taché.
¿En qué reduce realmente la dependencia de un equipo que responda el settlement determinista: además de solo mover la confianza a un lugar menos visible?
DuskEVM ahora corre sobre OP Stack, pasando a asentarse en DuskDS en lugar de quedarse ahí con la clásica ventana de desafío optimista de 7 días a la que todo el mundo está acostumbrado. Dusk lo plantea como una finalidad determinista: sin esperar una semana, sin el purgatorio de las pruebas de fraude. Suena limpio en el papel.
Luego ocurre el 16 de agosto de 2026.
El propio equipo de Dusk detecta actividad sospechosa en una wallet gestionada por el equipo vinculada a operaciones de puente. ¿Respuesta? No entra ninguna prueba de fraude on-chain automáticamente. El equipo deshabilitó y recicló las direcciones de puente afectadas, pausó los servicios del puente manualmente y desplegó una lista negra para Web Wallet de los destinatarios señalados.
O sea... un equipo de operaciones humanas tirando de los mandos, no la capa de settlement haciendo algo sin confianza.
Hmm. No estoy criticando que el arreglo fue rápido, razonable, exactamente lo que querrías. Pero es un recordatorio de que una “ventana sin fallos” es una afirmación sobre la matemática de finalidad de la capa de ejecución, no sobre quién interviene de verdad cuando algo va mal aguas arriba.
La red de seguridad que importó ese día fue un equipo con acceso de admin, no la arquitectura de OP Stack.
Me hizo pausar a mitad de la tarea: en mis notas escribí que “no hay una ventana de 7 días es sin confianza”, y luego lo taché.
¿En qué reduce realmente la dependencia de un equipo que responda el settlement determinista: además de solo mover la confianza a un lugar menos visible?
