Cuando revisé el documento del ciclo de vida de las transacciones de Dusk @Dusk Dusk, corregí un malentendido: la interfaz devuelve 202 Accepted, lo cual solo indica que el nodo aceptó la solicitud. Después de enviar la firma L1 de Dusk, el nodo primero hace admission; si pasa, entonces entra al real mempool y difunde a los peers. El productor del bloque ejecuta las transacciones ordenándolas por gasPrice.
Yo lo veo como una línea de procesamiento de liquidaciones. El 202 es el recibo en ventanilla; included es entrar a la zona de espera; ejecuted aún debe comprobar si err es null. Aunque el bloque sea accepted, todavía puede revertirse, hasta que blocks/statechange informa finalized, momento en el que el libro mayor queda sellado. Moonlight resuelve conflictos usando la cuenta y el nonce; Phoenix mira el nullifier. Para reemplazar una transacción, hay que aumentar gasPrice.
Esta cadena de eventos solo aplica a Dusk L1. En DuskEVM hay otro modelo con sequencer y finality. Mi listener escribe el tx hash y la coordenada del bloque, y luego valida con onlyFinalized:true. Solo observo included: si ocurre un reemplazo del nodo, expiración o eliminación por capacidad, es fácil confundir el estado local con que efectivamente ha llegado. El recibo es solo un registro del envío; la confirmación del fondo tiene que esperar el estado final.
#dusk $DUSK
Yo lo veo como una línea de procesamiento de liquidaciones. El 202 es el recibo en ventanilla; included es entrar a la zona de espera; ejecuted aún debe comprobar si err es null. Aunque el bloque sea accepted, todavía puede revertirse, hasta que blocks/statechange informa finalized, momento en el que el libro mayor queda sellado. Moonlight resuelve conflictos usando la cuenta y el nonce; Phoenix mira el nullifier. Para reemplazar una transacción, hay que aumentar gasPrice.
Esta cadena de eventos solo aplica a Dusk L1. En DuskEVM hay otro modelo con sequencer y finality. Mi listener escribe el tx hash y la coordenada del bloque, y luego valida con onlyFinalized:true. Solo observo included: si ocurre un reemplazo del nodo, expiración o eliminación por capacidad, es fácil confundir el estado local con que efectivamente ha llegado. El recibo es solo un registro del envío; la confirmación del fondo tiene que esperar el estado final.
#dusk $DUSK