Ich habe erst beim Lesen der Dokumentation zum Transaktionslebenszyklus für Dusk @Dusk Dusk einen Irrtum korrigiert: Die API gibt „202 Accepted“ zurück und sagt damit nur, dass der Knoten die Anfrage entgegengenommen hat. Nachdem die Dusk‑L1‑Signatur übermittelt wurde, prüft der Knoten zunächst das Admission; wenn die Prüfung besteht, gelangt die Transaktion in die „real mempool“ und wird anschließend an die Peers ausgesendet. Der Blockproduzent führt dann nach gasPrice sortiert aus.
Ich sehe das wie eine Abwicklungslinie. 202 ist die Annahme am Schalter, „included“ bedeutet, dass die Transaktion in den Wartebereich kommt, und „executed“ prüft außerdem noch, ob „err“ null ist. Selbst nachdem ein Block akzeptiert wurde, kann die Ausführung noch „reverted“ werden, bis „blocks/statechange“ „finalized“ meldet und erst dann wird das Ledger versiegelt. Moonlight prüft Kollisionen über Konto und Nonce, Phoenix über Nullifier; bei ersetzenden Transaktionen muss der gasPrice erhöht werden.
Diese Ereigniskette gilt nur für Dusk L1; DuskEVM hat ein eigenes Sequencer- und Finality‑Modell. Mein Listener speichert die Tx‑Hashes und die Blockkoordinaten und validiert dann mit „onlyFinalized:true“. Wenn man nur auf „included“ achtet, ist es leicht, den lokalen Zustand fälschlich als „angekommen“ zu interpretieren, wenn Knoten Transaktionen ersetzen, sie ablaufen oder durch Kapazitäten aus dem Pool verdrängt werden. Empfangsbestätigungen sind nur Einlieferungs-/Schalterzettel; die Bestätigung der Gelder wartet auf den endgültigen Status.
#dusk $DUSK
Ich sehe das wie eine Abwicklungslinie. 202 ist die Annahme am Schalter, „included“ bedeutet, dass die Transaktion in den Wartebereich kommt, und „executed“ prüft außerdem noch, ob „err“ null ist. Selbst nachdem ein Block akzeptiert wurde, kann die Ausführung noch „reverted“ werden, bis „blocks/statechange“ „finalized“ meldet und erst dann wird das Ledger versiegelt. Moonlight prüft Kollisionen über Konto und Nonce, Phoenix über Nullifier; bei ersetzenden Transaktionen muss der gasPrice erhöht werden.
Diese Ereigniskette gilt nur für Dusk L1; DuskEVM hat ein eigenes Sequencer- und Finality‑Modell. Mein Listener speichert die Tx‑Hashes und die Blockkoordinaten und validiert dann mit „onlyFinalized:true“. Wenn man nur auf „included“ achtet, ist es leicht, den lokalen Zustand fälschlich als „angekommen“ zu interpretieren, wenn Knoten Transaktionen ersetzen, sie ablaufen oder durch Kapazitäten aus dem Pool verdrängt werden. Empfangsbestätigungen sind nur Einlieferungs-/Schalterzettel; die Bestätigung der Gelder wartet auf den endgültigen Status.
#dusk $DUSK