Hoy tendí un puente entre DUSK y DuskEVM y estuve refrescando el rastreador como si eso fuera a cambiar algo. Mi transacción mostró "incluida" casi de inmediato. Luego se quedó ahí un rato antes de que alguien dijera que "se había liquidado". Asumí que ese intervalo era un retraso de la interfaz.

Pero no. DuskEVM funciona con un ciclo de rollup: un secuenciador incluye tu transacción en un bloque de L2 rápido, pero eso no es el mismo paso que la liquidación. Un publicador (batcher) por separado tiene que publicar esos datos en DuskDS — la capa propia de consenso y disponibilidad de datos de Dusk — y solo una vez que las confirmaciones de estado y las pruebas de fallos vuelven a estar vinculadas a esa capa, entonces algo se liquida realmente. "Incluida" y "liquidada" son dos promesas distintas, hechas por dos partes diferentes del stack.

Me pareció como un paquete que muestra "en camino" en el momento en que sale del almacén, mucho antes de que realmente esté sentado en tu porche. Las dos cosas son verdad. Pero no es la misma afirmación.

Lo que llamó la atención es que no se supone que debas deducirlo a partir del tiempo transcurrido. Mover valor entre DuskEVM y la Dusk L1 significa comprobar el estado real del protocolo o de la wallet, no asumir que han pasado suficientes minutos. Para algo destinado a transportar activos financieros regulados, ese no es un detalle menor: un fondo no puede liquidarse por suposición.

Entonces, ¿ese diseño de dos etapas se convierte en un punto de venta cuando las instituciones dependen de ello, o solo es un obstáculo de UX con el que los usuarios habituales se tropiezan antes de entender por qué se construyó así?

@Dusk_Foundation $DUSK #dusk

#dusk $DUSK