Ich denke, wir stellen normalerweise die falsche Frage, wenn eine Dusk-Transaktion „fehlschlägt“.
Ein 202 „Accepted“ bedeutet nur, dass der Node die Anfrage zur Weiterleitung akzeptiert hat. Es heißt nicht, dass die Transaktion bereits in der Mempool ist oder sich in einem Block befindet. Ein Beispiel, das ich interessant fand, ist eine zukünftige Nonce. Wenn eine Moonlight-Transaktion mit einer zukünftigen Nonce eintrifft, während eine frühere Nonce noch fehlt, kann Dusk sie außerhalb der realen Mempool lassen und warten, bis die Nonce-Lücke geschlossen ist, anstatt sie sofort abzulehnen. Dabei erhält sie einen verzögerten Status.
Das ist nur ein Teil der Geschichte. Sobald eine Transaktion die Zulassung passiert, gelangt sie in die lokale Mempool dieses Nodes. Andere Nodes behalten ihre eigenen Mempools und führen ebenfalls eigene Zulassungsprüfungen durch. Später kann eine Transaktion für einen Block ausgewählt, ausgeführt und schließlich finalisiert werden. Sie kann auch die lokale Mempool wieder verlassen, ohne dass das automatisch bedeutet, dass sie fehlgeschlagen ist. Ablauf (Expiry), Ersetzung (Replacement), Kapazitätsgrenzen und Konflikte können allesamt zu einer Entfernung führen.
Hier denke ich, dass der Unterschied für Wallets und Exchanges entscheidend ist. Die eigene Integrationsempfehlung von Dusk sagt, dass die exakt signierte Transaktion aufbewahrt werden soll, 202 „Accepted“ nur als erfolgreiche Weiterleitung zu behandeln ist und dieselben signierten Bytes nach einem Transport-Timeout erneut zu senden sind, statt blind eine neue Transaktion zu erstellen. Ein Withdrawal sollte erst als abgeschlossen markiert werden, nachdem die Ausführung geprüft wurde und der Block finalisiert ist.
Je mehr ich mir das angeschaut habe, desto weniger klang „Transaktion übermittelt“ nach einem nützlichen Status für sich allein. Eine Transaktion kann auf eine Nonce warten, in der Mempool eines Nodes liegen, mit einem Fehler ausgeführt werden oder in einem Block sitzen, der noch nicht final ist. Das sind sehr unterschiedliche Situationen, auch wenn sie von außen alle wie „es ist noch ausstehend“ wirken können.
Für mich ist das die nützliche Erkenntnis aus Dusk’s Transaktionsablauf: Übermittelt ist nur der Anfang. Entscheidend ist der Zustand, den man tatsächlich nachweisen kann, dass die Transaktion erreicht hat.
$DUSK @Dusk #dusk
Ein 202 „Accepted“ bedeutet nur, dass der Node die Anfrage zur Weiterleitung akzeptiert hat. Es heißt nicht, dass die Transaktion bereits in der Mempool ist oder sich in einem Block befindet. Ein Beispiel, das ich interessant fand, ist eine zukünftige Nonce. Wenn eine Moonlight-Transaktion mit einer zukünftigen Nonce eintrifft, während eine frühere Nonce noch fehlt, kann Dusk sie außerhalb der realen Mempool lassen und warten, bis die Nonce-Lücke geschlossen ist, anstatt sie sofort abzulehnen. Dabei erhält sie einen verzögerten Status.
Das ist nur ein Teil der Geschichte. Sobald eine Transaktion die Zulassung passiert, gelangt sie in die lokale Mempool dieses Nodes. Andere Nodes behalten ihre eigenen Mempools und führen ebenfalls eigene Zulassungsprüfungen durch. Später kann eine Transaktion für einen Block ausgewählt, ausgeführt und schließlich finalisiert werden. Sie kann auch die lokale Mempool wieder verlassen, ohne dass das automatisch bedeutet, dass sie fehlgeschlagen ist. Ablauf (Expiry), Ersetzung (Replacement), Kapazitätsgrenzen und Konflikte können allesamt zu einer Entfernung führen.
Hier denke ich, dass der Unterschied für Wallets und Exchanges entscheidend ist. Die eigene Integrationsempfehlung von Dusk sagt, dass die exakt signierte Transaktion aufbewahrt werden soll, 202 „Accepted“ nur als erfolgreiche Weiterleitung zu behandeln ist und dieselben signierten Bytes nach einem Transport-Timeout erneut zu senden sind, statt blind eine neue Transaktion zu erstellen. Ein Withdrawal sollte erst als abgeschlossen markiert werden, nachdem die Ausführung geprüft wurde und der Block finalisiert ist.
Je mehr ich mir das angeschaut habe, desto weniger klang „Transaktion übermittelt“ nach einem nützlichen Status für sich allein. Eine Transaktion kann auf eine Nonce warten, in der Mempool eines Nodes liegen, mit einem Fehler ausgeführt werden oder in einem Block sitzen, der noch nicht final ist. Das sind sehr unterschiedliche Situationen, auch wenn sie von außen alle wie „es ist noch ausstehend“ wirken können.
Für mich ist das die nützliche Erkenntnis aus Dusk’s Transaktionsablauf: Übermittelt ist nur der Anfang. Entscheidend ist der Zustand, den man tatsächlich nachweisen kann, dass die Transaktion erreicht hat.
$DUSK @Dusk #dusk
