#dusk $DUSK
Ayer por la noche volví a revisar la documentación del @Dusk y me sorprendí tratanto “finalized” como un solo instante. Asumí que, una vez que una transacción de Dusk estaba finalizada, los fondos deberían existir inmediatamente en DuskEVM. La documentación también hizo que esa suposición fuera demasiado sencilla.
En DuskEVM Testnet, un depósito se envía y se finaliza en Dusk L1, luego se procesa antes de que el saldo esté disponible en DuskEVM. Una retirada tiene más etapas: se inicia en DuskEVM, se espera un resultado (output), se prueba en Dusk L1, se superan las comprobaciones de madurez requerida y del dispute-game, y finalmente se finaliza en L1. La documentación advierte que la inclusión, la ejecución y la finalización no son el mismo estado, y que la preparación debería basarse en el estado del protocolo en lugar del tiempo transcurrido.
Eso me hizo verlo de otra manera.
Mi interpretación: el puente no es un retraso oculto; intenta convertir una máquina de estados entre capas en algo que una wallet pueda explicar. La tensión está entre la seguridad y la dependencia operativa. Los reintentos más seguros, la recuperación tras rollback y las comprobaciones de challenge reducen una clase de fallos, pero las rutas de recuperación también concentran la responsabilidad en algún lugar.
Mi incertidumbre: durante un rollback junto con una falla del relayer, ¿qué puede verificar un usuario de forma independiente antes de que los fondos se liberen o se reintenten? ¿Quién puede pausar o reanudar las operaciones del puente, y cuáles son los límites de esa autoridad si la emergencia dura más de lo esperado?
Quiero observar esto en la práctica.
Ayer por la noche volví a revisar la documentación del @Dusk y me sorprendí tratanto “finalized” como un solo instante. Asumí que, una vez que una transacción de Dusk estaba finalizada, los fondos deberían existir inmediatamente en DuskEVM. La documentación también hizo que esa suposición fuera demasiado sencilla.
En DuskEVM Testnet, un depósito se envía y se finaliza en Dusk L1, luego se procesa antes de que el saldo esté disponible en DuskEVM. Una retirada tiene más etapas: se inicia en DuskEVM, se espera un resultado (output), se prueba en Dusk L1, se superan las comprobaciones de madurez requerida y del dispute-game, y finalmente se finaliza en L1. La documentación advierte que la inclusión, la ejecución y la finalización no son el mismo estado, y que la preparación debería basarse en el estado del protocolo en lugar del tiempo transcurrido.
Eso me hizo verlo de otra manera.
Mi interpretación: el puente no es un retraso oculto; intenta convertir una máquina de estados entre capas en algo que una wallet pueda explicar. La tensión está entre la seguridad y la dependencia operativa. Los reintentos más seguros, la recuperación tras rollback y las comprobaciones de challenge reducen una clase de fallos, pero las rutas de recuperación también concentran la responsabilidad en algún lugar.
Mi incertidumbre: durante un rollback junto con una falla del relayer, ¿qué puede verificar un usuario de forma independiente antes de que los fondos se liberen o se reintenten? ¿Quién puede pausar o reanudar las operaciones del puente, y cuáles son los límites de esa autoridad si la emergencia dura más de lo esperado?
Quiero observar esto en la práctica.
