Al recargar una exchange o usar el sistema de pagos, uno de los malentendidos más peligrosos es tomar la respuesta del nodo “202 Accepted” como un comprobante de que ya ha llegado el dinero.
Reorganicé de nuevo el ciclo de vida de las transacciones de @Dusk . Cuando se envía una transacción al nodo, el “202” solo indica que el nodo aceptó los datos y está preparado para reenviarlos; no significa que ya haya entrado en el Mempool real, ni que haya sido empaquetada, ejecutada con éxito o que haya alcanzado la confirmación final.
Una transacción de Dusk L1 debe pasar, como mínimo, por varias etapas: envío, prevalidación, entrada al mempool local, propagación por la red, selección de bloques, ejecución del contrato y finalmente la finalización del bloque. Incluso si la transacción ya está dentro del bloque que fue aceptado, hay que comprobar si el campo Error en el evento Executed está vacío; si ocurre un error en el contrato, aún pueden consumirse el Nonce o las Phoenix Notes, y también se debe pagar el Gas. Solo cuando el estado del bloque se convierte en Finalized, se puede considerar la transacción como un resultado irreversible.
Esto es como un sistema de mensajería que muestra “recolectado”. Solo puede probar que el mensajero recibió el paquete, pero no que el paquete ya fue entregado al destinatario.
Por lo tanto, si una exchange ve el hash de la transacción y acredita el dinero antes de tiempo, podría tratar como depósito real una transacción que fue reemplazada, que falló al ejecutarse o que todavía no se ha finalizado. Lo más importante que conviene observar después es cómo el monedero muestra la etapa de la transacción, qué criterio de confirmación final usa la exchange y la proporción de casos en los que la ejecución falló pero el Gas ya se pagó.
Recibir una transacción no equivale a ejecutarla; ejecutar una transacción no equivale a la liquidación final. Lo que un sistema financiero realmente necesita confirmar es el último paso.#dusk $DUSK
Reorganicé de nuevo el ciclo de vida de las transacciones de @Dusk . Cuando se envía una transacción al nodo, el “202” solo indica que el nodo aceptó los datos y está preparado para reenviarlos; no significa que ya haya entrado en el Mempool real, ni que haya sido empaquetada, ejecutada con éxito o que haya alcanzado la confirmación final.
Una transacción de Dusk L1 debe pasar, como mínimo, por varias etapas: envío, prevalidación, entrada al mempool local, propagación por la red, selección de bloques, ejecución del contrato y finalmente la finalización del bloque. Incluso si la transacción ya está dentro del bloque que fue aceptado, hay que comprobar si el campo Error en el evento Executed está vacío; si ocurre un error en el contrato, aún pueden consumirse el Nonce o las Phoenix Notes, y también se debe pagar el Gas. Solo cuando el estado del bloque se convierte en Finalized, se puede considerar la transacción como un resultado irreversible.
Esto es como un sistema de mensajería que muestra “recolectado”. Solo puede probar que el mensajero recibió el paquete, pero no que el paquete ya fue entregado al destinatario.
Por lo tanto, si una exchange ve el hash de la transacción y acredita el dinero antes de tiempo, podría tratar como depósito real una transacción que fue reemplazada, que falló al ejecutarse o que todavía no se ha finalizado. Lo más importante que conviene observar después es cómo el monedero muestra la etapa de la transacción, qué criterio de confirmación final usa la exchange y la proporción de casos en los que la ejecución falló pero el Gas ya se pagó.
Recibir una transacción no equivale a ejecutarla; ejecutar una transacción no equivale a la liquidación final. Lo que un sistema financiero realmente necesita confirmar es el último paso.#dusk $DUSK