Creo que normalmente hacemos la pregunta equivocada cuando una transacción de “Dusk” “falla”.
Un 202 Accepted solo significa que el nodo aceptó la solicitud para el enrutamiento. No significa que la transacción ya esté en el mempool o en un bloque. Un ejemplo que me pareció interesante es un nonce futuro. Si llega una transacción de Moonlight con un nonce futuro mientras aún falta un nonce anterior, Dusk puede mantenerla fuera del mempool real y esperar a que se cierre la brecha de nonces en lugar de rechazarla de inmediato. Obtiene un estado diferido mientras ocurre eso.
Esa es solo una parte de la historia. Una vez que una transacción pasa la admisión, entra en el mempool local de ese nodo. Los otros nodos mantienen sus propios mempools y también ejecutan sus propias comprobaciones de admisión. Más tarde, una transacción puede seleccionarse para un bloque, ejecutarse y finalmente quedar finalizada. También puede salir del mempool local sin que eso signifique automáticamente que falló. La caducidad, el reemplazo, los límites de capacidad y los conflictos pueden llevar a su eliminación.
Aquí es donde creo que la diferencia importa para billeteras y exchanges. La guía de integración de Dusk indica que se debe conservar la transacción firmada exacta, tratar el 202 Accepted solo como un enrutamiento exitoso y retransmitir los mismos bytes firmados después de un tiempo de espera de transporte en lugar de crear una nueva transacción a ciegas. Un retiro solo debe marcarse como completado después de comprobar que la ejecución se realizó y que el bloque quedó finalizado.
Cuanto más lo miré, menos “transacción enviada” sonaba como un estado útil por sí solo. Una transacción puede estar esperando un nonce, estar en el mempool de un nodo, ejecutarse con un error o estar en un bloque que todavía no es final. Son situaciones muy distintas, aunque todas pueden parecer “sigue pendiente” desde fuera.
Para mí, esa es la conclusión útil del flujo de transacciones de Dusk: enviada es solo el comienzo. Lo que importa es el estado que realmente puedes demostrar que alcanzó la transacción.
$DUSK @Dusk #dusk
Un 202 Accepted solo significa que el nodo aceptó la solicitud para el enrutamiento. No significa que la transacción ya esté en el mempool o en un bloque. Un ejemplo que me pareció interesante es un nonce futuro. Si llega una transacción de Moonlight con un nonce futuro mientras aún falta un nonce anterior, Dusk puede mantenerla fuera del mempool real y esperar a que se cierre la brecha de nonces en lugar de rechazarla de inmediato. Obtiene un estado diferido mientras ocurre eso.
Esa es solo una parte de la historia. Una vez que una transacción pasa la admisión, entra en el mempool local de ese nodo. Los otros nodos mantienen sus propios mempools y también ejecutan sus propias comprobaciones de admisión. Más tarde, una transacción puede seleccionarse para un bloque, ejecutarse y finalmente quedar finalizada. También puede salir del mempool local sin que eso signifique automáticamente que falló. La caducidad, el reemplazo, los límites de capacidad y los conflictos pueden llevar a su eliminación.
Aquí es donde creo que la diferencia importa para billeteras y exchanges. La guía de integración de Dusk indica que se debe conservar la transacción firmada exacta, tratar el 202 Accepted solo como un enrutamiento exitoso y retransmitir los mismos bytes firmados después de un tiempo de espera de transporte en lugar de crear una nueva transacción a ciegas. Un retiro solo debe marcarse como completado después de comprobar que la ejecución se realizó y que el bloque quedó finalizado.
Cuanto más lo miré, menos “transacción enviada” sonaba como un estado útil por sí solo. Una transacción puede estar esperando un nonce, estar en el mempool de un nodo, ejecutarse con un error o estar en un bloque que todavía no es final. Son situaciones muy distintas, aunque todas pueden parecer “sigue pendiente” desde fuera.
Para mí, esa es la conclusión útil del flujo de transacciones de Dusk: enviada es solo el comienzo. Lo que importa es el estado que realmente puedes demostrar que alcanzó la transacción.
$DUSK @Dusk #dusk
