Un tiempo de espera de retiro no debería crear una nueva identidad
Una solicitud de retiro agota el tiempo de espera. La respuesta tentadora es sencilla: vuelve a crear la transacción y reenvíala.
En Dusk, eso puede hacer el problema operativo más difícil.
Para retiros de Moonlight, la guía de integración indica que la transacción debe construirse y firmarse una sola vez, guardando sus bytes serializados y su ID de transacción antes de difundirla. Si el envío alcanza un tiempo de espera de transporte, la reintención segura es retransmitir esos mismos bytes firmados. La transacción mantiene la misma identidad mientras se investiga su estado en la cadena.
¿Por qué importa? Porque un tiempo de espera no prueba que el primer intento haya fallado. Incluso un 202 Accepted solo confirma el enrutamiento, no la inclusión o la finalidad. Crear otra transacción antes de resolver esa incertidumbre introduce otro objeto para que el sistema de retiros lo rastree.
Moonlight hace esta distinción explícita. Las transacciones usan nonces de cuenta secuenciales, y una transacción en conflicto con el mismo nonce reemplaza la entrada existente en el mempool solo cuando su precio de gas es estrictamente mayor. Ese reemplazo tiene un ID de transacción distinto. Por eso, Dusk le indica a los operadores de intercambio que concilien ambos ID y eviten debitar dos veces.
Así que “reintentar” y “reemplazar” no son acciones intercambiables en el backend. Un reintento preserva la identidad del intento de pago. Un reemplazo crea deliberadamente una nueva identidad para el mismo nonce.
Para la infraestructura de custodia, la idempotencia por lo tanto va más allá del diseño de bases de datos: la construcción de la transacción, la asignación de nonces, los bytes firmados y los registros contables tienen que describir el mismo retiro.
@Dusk $DUSK #dusk
Una solicitud de retiro agota el tiempo de espera. La respuesta tentadora es sencilla: vuelve a crear la transacción y reenvíala.
En Dusk, eso puede hacer el problema operativo más difícil.
Para retiros de Moonlight, la guía de integración indica que la transacción debe construirse y firmarse una sola vez, guardando sus bytes serializados y su ID de transacción antes de difundirla. Si el envío alcanza un tiempo de espera de transporte, la reintención segura es retransmitir esos mismos bytes firmados. La transacción mantiene la misma identidad mientras se investiga su estado en la cadena.
¿Por qué importa? Porque un tiempo de espera no prueba que el primer intento haya fallado. Incluso un 202 Accepted solo confirma el enrutamiento, no la inclusión o la finalidad. Crear otra transacción antes de resolver esa incertidumbre introduce otro objeto para que el sistema de retiros lo rastree.
Moonlight hace esta distinción explícita. Las transacciones usan nonces de cuenta secuenciales, y una transacción en conflicto con el mismo nonce reemplaza la entrada existente en el mempool solo cuando su precio de gas es estrictamente mayor. Ese reemplazo tiene un ID de transacción distinto. Por eso, Dusk le indica a los operadores de intercambio que concilien ambos ID y eviten debitar dos veces.
Así que “reintentar” y “reemplazar” no son acciones intercambiables en el backend. Un reintento preserva la identidad del intento de pago. Un reemplazo crea deliberadamente una nueva identidad para el mismo nonce.
Para la infraestructura de custodia, la idempotencia por lo tanto va más allá del diseño de bases de datos: la construcción de la transacción, la asignación de nonces, los bytes firmados y los registros contables tienen que describir el mismo retiro.
@Dusk $DUSK #dusk
