Eine „202 Accepted“ bedeutet, dass der DUSK-Withdrawal durchgelaufen ist.
Sie hat aber noch nicht die Ziellinie erreicht.
Ich ging davon aus, dass die Auszahlung im Grunde erledigt ist, sobald der Austausch 202 zurückgibt.
Die Austausch-Architektur von Dusk behandelt diese Antwort viel enger.
POST /on/transactions/propagate gibt 202 zurück, wenn der Node die Transaktion zur Weiterleitung akzeptiert. Das beweist keinen Mempool-Zugang, keine Ausführung oder Finalität.
Dann kommt der Teil, den ich nicht erwartet habe.
Der Signierungsdienst reserviert die nächste Moonlight-Nonce atomar, erstellt und signiert die Transaktion einmal und speichert dann die exakt serialisierten Bytes, bevor sie gesendet werden.
Betrachten wir ein konstruiertes Beispiel: Withdrawal-Nonce 41 wird reserviert, die Transaktion wird signiert und persistiert, und die API gibt 202 zurück. Dann läuft die Verbindung ab, bevor der Austausch weiß, was passiert ist.
Der Austausch erzeugt nicht einfach blind eine weitere Transaktion.
Er sendet die gleichen signierten Bytes erneut.
Das ist der ganze Trick.
Die 202-Antwort beantwortet eine Frage: „Hat der Node diese Transaktion zur Weiterleitung akzeptiert?“
Der persistierte Transaktionsstatus beantwortet eine andere: „Haben wir noch die exakte Transaktion, die wir sicher erneut versuchen können, während die Ausführung unbekannt ist?“
Beides erfüllt unterschiedliche Aufgaben.
So kann ein Withdrawal vom Node akzeptiert werden, während er aus Sicht des Austauschs noch lange nicht abgeschlossen ist.
Wie viel von den zuverlässigen DUSK-Withdrawals kommt aus netzwerkseitiger Ausführung und Finalität, und wie viel kommt aus austauschseitiger Transaktionskontinuität, während dieses Ergebnis noch unbekannt ist?
@Dusk_Foundation #dusk $DUSK
Sie hat aber noch nicht die Ziellinie erreicht.
Ich ging davon aus, dass die Auszahlung im Grunde erledigt ist, sobald der Austausch 202 zurückgibt.
Die Austausch-Architektur von Dusk behandelt diese Antwort viel enger.
POST /on/transactions/propagate gibt 202 zurück, wenn der Node die Transaktion zur Weiterleitung akzeptiert. Das beweist keinen Mempool-Zugang, keine Ausführung oder Finalität.
Dann kommt der Teil, den ich nicht erwartet habe.
Der Signierungsdienst reserviert die nächste Moonlight-Nonce atomar, erstellt und signiert die Transaktion einmal und speichert dann die exakt serialisierten Bytes, bevor sie gesendet werden.
Betrachten wir ein konstruiertes Beispiel: Withdrawal-Nonce 41 wird reserviert, die Transaktion wird signiert und persistiert, und die API gibt 202 zurück. Dann läuft die Verbindung ab, bevor der Austausch weiß, was passiert ist.
Der Austausch erzeugt nicht einfach blind eine weitere Transaktion.
Er sendet die gleichen signierten Bytes erneut.
Das ist der ganze Trick.
Die 202-Antwort beantwortet eine Frage: „Hat der Node diese Transaktion zur Weiterleitung akzeptiert?“
Der persistierte Transaktionsstatus beantwortet eine andere: „Haben wir noch die exakte Transaktion, die wir sicher erneut versuchen können, während die Ausführung unbekannt ist?“
Beides erfüllt unterschiedliche Aufgaben.
So kann ein Withdrawal vom Node akzeptiert werden, während er aus Sicht des Austauschs noch lange nicht abgeschlossen ist.
Wie viel von den zuverlässigen DUSK-Withdrawals kommt aus netzwerkseitiger Ausführung und Finalität, und wie viel kommt aus austauschseitiger Transaktionskontinuität, während dieses Ergebnis noch unbekannt ist?
@Dusk_Foundation #dusk $DUSK