Anoche tendí un puente de algunas pruebas de la red de prueba de DUSK a DuskEVM y desplegué un contrato pequeño, en su mayoría solo para ver cómo una transacción pasaba por el proceso de extremo a extremo. Se confirmó rápido. Naturalmente asumí que eso significaba que ya estaba listo: la inclusión aparecía, la transacción se cerraba y seguí adelante.
Resulta que aquí no es exactamente lo mismo, y la brecha importa más de lo que suena. DuskEVM funciona como un rollup: un secuenciador incluye tu transacción primero en un bloque de L2, luego un “batcher” publica esos datos por separado en DuskDS, y solo después de que vuelven a conectarse los compromisos de estado y las pruebas de fallos es cuando realmente se liquida. La inclusión ocurre en un reloj. La liquidación ocurre en otro. Mi cartera mostró confirmada en el momento en que ocurrió la primera, no la segunda.
Me recordó a un cheque que se hace efectivo en un mostrador de un banco. El cajero te entrega un recibo en cuanto lo recibe: se siente como que ya está hecho. El dinero real no se transfiere entre bancos hasta que se liquida en segundo plano, en su propio calendario, independientemente de lo que diga el recibo.
Tiene sentido que Dusk trace esta línea con tanta claridad, dado para quién está construido realmente este chain. Un entorno regulado que mueve valores reales no puede tratar “parece confirmado” e “está liquidado” como intercambiables: la documentación es explícita en que cualquier cosa que mueva valor entre DuskEVM y la Dusk L1 debe verificar el estado del protocolo o de la cartera directamente, no inferir la finalidad a partir de cuánto tiempo pasó.
Vale la pena aclarar que esto fue en testnet: el timing en mainnet puede verse diferente una vez que esté completamente en vivo.
Aún lo estoy repasando: para una cadena que apunta a liquidación de nivel MTF, ¿esa separación entre inclusión y liquidación se abstrae para el usuario final eventualmente, o las finanzas reguladas realmente quieren que esa brecha permanezca visible a propósito?
#dusk $DUSK @Dusk #DUSK
Resulta que aquí no es exactamente lo mismo, y la brecha importa más de lo que suena. DuskEVM funciona como un rollup: un secuenciador incluye tu transacción primero en un bloque de L2, luego un “batcher” publica esos datos por separado en DuskDS, y solo después de que vuelven a conectarse los compromisos de estado y las pruebas de fallos es cuando realmente se liquida. La inclusión ocurre en un reloj. La liquidación ocurre en otro. Mi cartera mostró confirmada en el momento en que ocurrió la primera, no la segunda.
Me recordó a un cheque que se hace efectivo en un mostrador de un banco. El cajero te entrega un recibo en cuanto lo recibe: se siente como que ya está hecho. El dinero real no se transfiere entre bancos hasta que se liquida en segundo plano, en su propio calendario, independientemente de lo que diga el recibo.
Tiene sentido que Dusk trace esta línea con tanta claridad, dado para quién está construido realmente este chain. Un entorno regulado que mueve valores reales no puede tratar “parece confirmado” e “está liquidado” como intercambiables: la documentación es explícita en que cualquier cosa que mueva valor entre DuskEVM y la Dusk L1 debe verificar el estado del protocolo o de la cartera directamente, no inferir la finalidad a partir de cuánto tiempo pasó.
Vale la pena aclarar que esto fue en testnet: el timing en mainnet puede verse diferente una vez que esté completamente en vivo.
Aún lo estoy repasando: para una cadena que apunta a liquidación de nivel MTF, ¿esa separación entre inclusión y liquidación se abstrae para el usuario final eventualmente, o las finanzas reguladas realmente quieren que esa brecha permanezca visible a propósito?
#dusk $DUSK @Dusk #DUSK