EINE DUSK-TRANSAKTION KANN VOR DEM AUSTAUSCH ALS „AKZEPTIERT“ GEKENNZEICHNET WERDEN, BEVOR DER AUSTAUSCH SIE ALS ERLEDIGT BEHANDELN SOLLTE.
Ich habe mir die Transaction-API von @Dusk durchgelesen, und ein Statuscode hat mich mehr als die übliche Diskussion über die endgültige Bestätigung beunruhigt:
202 Accepted.
Wenn ein Dusk-Knoten nach der Weiterleitung einer Transaktion 202 zurückgibt, bedeutet das, dass die Transaktion zur Weiterleitung akzeptiert wurde.
Es beweist noch nicht, dass sie in die echte Mempool gelangt ist, Peers erreicht hat, erfolgreich ausgeführt wurde oder endgültig bestätigt wurde.
Das klingt nach einer kleinen API-Detailfrage.
Für einen Austausch, der Abhebungen verarbeitet, glaube ich, ist es das nicht.
Ich habe die Abwicklungsverarbeitung gedanklich behandelt wie etwas in der Nähe von:
Transaktion senden → Netzwerk akzeptiert sie → auf endgültige Bestätigung warten → Abhebung schließen.
Aber es gibt einen unangenehmen Zwischenzustand, in dem der Austausch zwar etwas gesendet hat, aber noch nicht genug Informationen hat, um die wirtschaftliche Aktion sicher als abgeschlossen zu melden.
Das verändert das Problem.
Transaktionsübermittlung ist nicht gleich Transaktionsabschluss.
Und das erneute Versuchen einer fehlgeschlagenen API-Anfrage ist nicht zwangsläufig dasselbe wie die Entscheidung, dass die ursprüngliche Abhebung nie existiert hat.
Die Dusk-Dokumentation warnt sogar, dass ein Signierungsdienst die Zuweisung von Nonces serialisieren, übermittelte Transaktionen beibehalten und den ausstehenden sowie den bestätigten Kontostand prüfen muss, bevor eine Nonce wiederverwendet wird.
Das ist der Teil, der mich interessiert.
Deterministische Endgültigkeit kann das Ende einer Transaktion sehr klar machen.
Sie kann jedoch nicht automatisch jeden Zustand vor der Endgültigkeit für einen Austausch genauso leicht handhabbar machen.
Wenn ich also eine ernsthafte Dusk-Integration bewerten würde, würde ich nicht nur die Geschwindigkeit der Abwicklung messen.
Ich würde wissen wollen, was passiert bei Ausfällen von Knoten, Timeouts und mehrdeutigen Übermittlungen:
Wie viele Abhebungen können sich automatisch erholen, ohne doppelte Anweisungen zu erzeugen oder ohne dass jemand manuell entscheiden muss, was passiert ist?
Die beste Transaktionsinfrastruktur ist vielleicht diejenige, bei der der Fehlerpfad langweilig wird.
Das scheint viel schwerer, als den Happy Path schnell zu machen.
#dusk $DUSK @Dusk
$GPS $TUT
Ich habe mir die Transaction-API von @Dusk durchgelesen, und ein Statuscode hat mich mehr als die übliche Diskussion über die endgültige Bestätigung beunruhigt:
202 Accepted.
Wenn ein Dusk-Knoten nach der Weiterleitung einer Transaktion 202 zurückgibt, bedeutet das, dass die Transaktion zur Weiterleitung akzeptiert wurde.
Es beweist noch nicht, dass sie in die echte Mempool gelangt ist, Peers erreicht hat, erfolgreich ausgeführt wurde oder endgültig bestätigt wurde.
Das klingt nach einer kleinen API-Detailfrage.
Für einen Austausch, der Abhebungen verarbeitet, glaube ich, ist es das nicht.
Ich habe die Abwicklungsverarbeitung gedanklich behandelt wie etwas in der Nähe von:
Transaktion senden → Netzwerk akzeptiert sie → auf endgültige Bestätigung warten → Abhebung schließen.
Aber es gibt einen unangenehmen Zwischenzustand, in dem der Austausch zwar etwas gesendet hat, aber noch nicht genug Informationen hat, um die wirtschaftliche Aktion sicher als abgeschlossen zu melden.
Das verändert das Problem.
Transaktionsübermittlung ist nicht gleich Transaktionsabschluss.
Und das erneute Versuchen einer fehlgeschlagenen API-Anfrage ist nicht zwangsläufig dasselbe wie die Entscheidung, dass die ursprüngliche Abhebung nie existiert hat.
Die Dusk-Dokumentation warnt sogar, dass ein Signierungsdienst die Zuweisung von Nonces serialisieren, übermittelte Transaktionen beibehalten und den ausstehenden sowie den bestätigten Kontostand prüfen muss, bevor eine Nonce wiederverwendet wird.
Das ist der Teil, der mich interessiert.
Deterministische Endgültigkeit kann das Ende einer Transaktion sehr klar machen.
Sie kann jedoch nicht automatisch jeden Zustand vor der Endgültigkeit für einen Austausch genauso leicht handhabbar machen.
Wenn ich also eine ernsthafte Dusk-Integration bewerten würde, würde ich nicht nur die Geschwindigkeit der Abwicklung messen.
Ich würde wissen wollen, was passiert bei Ausfällen von Knoten, Timeouts und mehrdeutigen Übermittlungen:
Wie viele Abhebungen können sich automatisch erholen, ohne doppelte Anweisungen zu erzeugen oder ohne dass jemand manuell entscheiden muss, was passiert ist?
Die beste Transaktionsinfrastruktur ist vielleicht diejenige, bei der der Fehlerpfad langweilig wird.
Das scheint viel schwerer, als den Happy Path schnell zu machen.
#dusk $DUSK @Dusk
$GPS $TUT