Knoten gibt „202 Accepted“ zurück – wie viele Schritte fehlen noch bis zum wirklich erfolgreichen Settlement?
In traditionellen Zahlungssystemen sind „Bank hat es angenommen“ und „Gelder sind eingegangen“ zwei unterschiedliche Zustände. Nach der Analyse des Transaktionslebenszyklus von @Dusk habe ich festgestellt: Auch On-Chain-Transaktionen kann man nicht nur anhand einer einzigen „Erfolgsmeldung“ bewerten.
Eine Dusk-L1-Transaktion durchläuft grob:
Einreichen, Knoten-Pre-Validierung, Eintritt in den lokalen Mempool, Verbreitung an andere Knoten, Auswahl durch den Blockproduzenten, Ausführung und schließlich die finale Bestätigung.
Am leichtesten wird dabei missverstanden, dass der Transaktions-Submit-Endpoint 202 Accepted zurückgibt. Das bedeutet lediglich, dass der Knoten diese Daten erhalten hat und für die Weiterverbreitung vorbereitet ist – nicht, dass die Transaktion bereits in einen Block gelangt ist.
Selbst wenn die Transaktion in den Mempool des Knotens gelangt, heißt das nur, dass sie die ersten Prüfungen dieses Knotens bestanden hat. Sobald sie in einen Block aufgenommen wurde, muss man außerdem im Ausführungsergebnis prüfen, ob das Feld „err“ leer ist. Wenn ein Smart Contract aufgrund von Parametern, Status oder Gas-Problemen zurückrollt, können der Nonce und bereits verbrauchtes Gas trotzdem nicht rückgängig gemacht werden.
Zum Schluss muss man noch abwarten, bis der Block den Zustand „finalized“ erreicht. Die offizielle Dokumentation weist ausdrücklich darauf hin, dass man included, removed oder ein normales accepted nicht als Signal für Zahlungs-Endgültigkeit missverstehen darf.
Das ist für Dusk-Services zur Wertpapier-Settlement in der Zukunft besonders wichtig. Für Institutionen ist nicht entscheidend, ob auf der Oberfläche ein grüner Hinweis auftaucht, sondern auf welcher irreversiblen Grundlage die Vermögensübergabe und die Buchung erfolgen.
Die von der Dusk-Website genannten Netzwerk-Kennzahlen zur Finalität liegen bei etwa 10 Sekunden – die Anwendung muss jedoch den finalen Status korrekt erkennen und darf nicht allein durch „10 Sekunden warten“ das Ergebnis raten.
Ich beurteile, ob ein institutionelles Abrechnungssystem reif ist, indem ich insbesondere auf Folgendes achte:
1. Stabilität der Zeit bis zur endgültigen Bestätigung;
2. Ausführungsfehlerrate;
3. Häufigkeit von Block- Rollbacks und Neuabgleichen;
4. Ob die Anwendung zwischen Einreichen, Ausführung und endgültiger Bestätigung unterscheidet;
5. Ob auf der Vermögens- und auf der Zahlungsseite derselbe Finalitätsstandard verwendet wird.
Wirkliches On-Chain-Settlement bedeutet nicht, dass die Transaktion nur „abgeschickt“ wurde, sondern dass alle Beteiligten eine übereinstimmende Antwort darauf haben, wann man buchen darf.#dusk $DUSK
In traditionellen Zahlungssystemen sind „Bank hat es angenommen“ und „Gelder sind eingegangen“ zwei unterschiedliche Zustände. Nach der Analyse des Transaktionslebenszyklus von @Dusk habe ich festgestellt: Auch On-Chain-Transaktionen kann man nicht nur anhand einer einzigen „Erfolgsmeldung“ bewerten.
Eine Dusk-L1-Transaktion durchläuft grob:
Einreichen, Knoten-Pre-Validierung, Eintritt in den lokalen Mempool, Verbreitung an andere Knoten, Auswahl durch den Blockproduzenten, Ausführung und schließlich die finale Bestätigung.
Am leichtesten wird dabei missverstanden, dass der Transaktions-Submit-Endpoint 202 Accepted zurückgibt. Das bedeutet lediglich, dass der Knoten diese Daten erhalten hat und für die Weiterverbreitung vorbereitet ist – nicht, dass die Transaktion bereits in einen Block gelangt ist.
Selbst wenn die Transaktion in den Mempool des Knotens gelangt, heißt das nur, dass sie die ersten Prüfungen dieses Knotens bestanden hat. Sobald sie in einen Block aufgenommen wurde, muss man außerdem im Ausführungsergebnis prüfen, ob das Feld „err“ leer ist. Wenn ein Smart Contract aufgrund von Parametern, Status oder Gas-Problemen zurückrollt, können der Nonce und bereits verbrauchtes Gas trotzdem nicht rückgängig gemacht werden.
Zum Schluss muss man noch abwarten, bis der Block den Zustand „finalized“ erreicht. Die offizielle Dokumentation weist ausdrücklich darauf hin, dass man included, removed oder ein normales accepted nicht als Signal für Zahlungs-Endgültigkeit missverstehen darf.
Das ist für Dusk-Services zur Wertpapier-Settlement in der Zukunft besonders wichtig. Für Institutionen ist nicht entscheidend, ob auf der Oberfläche ein grüner Hinweis auftaucht, sondern auf welcher irreversiblen Grundlage die Vermögensübergabe und die Buchung erfolgen.
Die von der Dusk-Website genannten Netzwerk-Kennzahlen zur Finalität liegen bei etwa 10 Sekunden – die Anwendung muss jedoch den finalen Status korrekt erkennen und darf nicht allein durch „10 Sekunden warten“ das Ergebnis raten.
Ich beurteile, ob ein institutionelles Abrechnungssystem reif ist, indem ich insbesondere auf Folgendes achte:
1. Stabilität der Zeit bis zur endgültigen Bestätigung;
2. Ausführungsfehlerrate;
3. Häufigkeit von Block- Rollbacks und Neuabgleichen;
4. Ob die Anwendung zwischen Einreichen, Ausführung und endgültiger Bestätigung unterscheidet;
5. Ob auf der Vermögens- und auf der Zahlungsseite derselbe Finalitätsstandard verwendet wird.
Wirkliches On-Chain-Settlement bedeutet nicht, dass die Transaktion nur „abgeschickt“ wurde, sondern dass alle Beteiligten eine übereinstimmende Antwort darauf haben, wann man buchen darf.#dusk $DUSK