#dusk $DUSK @Dusk
Oye, ya sabes… una pregunta sobre @DuskFoundation se me quedó dando vueltas: si un intercambio recibe “202 Accepted” para mi retiro, ¿por qué el trabajo no se ha terminado?
Estamos acostumbrados a leer una respuesta como “hecho”. Pero en una blockchain, el envío y la liquidación son momentos distintos.
En Dusk L1, “202 Accepted” solo significa que un nodo aceptó la transacción para enrutarla. No prueba que la transacción haya entrado al mempool, que haya llegado a pares, que se haya ejecutado correctamente ni que haya llegado a ser final.
Dusk separa esos pasos. “transactions/included” indica admisión local al mempool. “transactions/executed” significa que la transacción se ejecutó dentro de un bloque aceptado, donde el campo “err” debe ser nulo. La finalidad llega cuando un evento “blocks/statechange” se marca como “finalized”. Antes de eso, incluso un bloque aceptado podría revertirse.
Supongamos, hipotéticamente, que retiro DUSK de un intercambio. Su sistema firma la transacción de Moonlight, guarda sus bytes y su ID, y luego la difunde. La respuesta 202 confirma el enrutamiento, no la finalización. El intercambio debe verificar la ejecución y el estado del bloque finalizado.
Pero me detuve aquí un momento.
Quizá la finalidad no sea solo una característica de consenso. Es una responsabilidad operativa.
Entonces, ¿cuándo un retiro está realmente completo: cuando la API responde, o cuando ya no es posible una reversión? Todavía estoy dándole vueltas. 🤔
Oye, ya sabes… una pregunta sobre @DuskFoundation se me quedó dando vueltas: si un intercambio recibe “202 Accepted” para mi retiro, ¿por qué el trabajo no se ha terminado?
Estamos acostumbrados a leer una respuesta como “hecho”. Pero en una blockchain, el envío y la liquidación son momentos distintos.
En Dusk L1, “202 Accepted” solo significa que un nodo aceptó la transacción para enrutarla. No prueba que la transacción haya entrado al mempool, que haya llegado a pares, que se haya ejecutado correctamente ni que haya llegado a ser final.
Dusk separa esos pasos. “transactions/included” indica admisión local al mempool. “transactions/executed” significa que la transacción se ejecutó dentro de un bloque aceptado, donde el campo “err” debe ser nulo. La finalidad llega cuando un evento “blocks/statechange” se marca como “finalized”. Antes de eso, incluso un bloque aceptado podría revertirse.
Supongamos, hipotéticamente, que retiro DUSK de un intercambio. Su sistema firma la transacción de Moonlight, guarda sus bytes y su ID, y luego la difunde. La respuesta 202 confirma el enrutamiento, no la finalización. El intercambio debe verificar la ejecución y el estado del bloque finalizado.
Pero me detuve aquí un momento.
Quizá la finalidad no sea solo una característica de consenso. Es una responsabilidad operativa.
Entonces, ¿cuándo un retiro está realmente completo: cuando la API responde, o cuando ya no es posible una reversión? Todavía estoy dándole vueltas. 🤔