Ich komme immer wieder auf eine hässliche Einzelheit in DUSK-Integrationen zurück: „202 Accepted“ ist nicht der Moment, in dem ich einem Nutzer Glauben schenken würde.
Diese Antwort sagt mir lediglich, dass ein Rusk-Node die Transaktion zur Weiterleitung akzeptiert hat. Der Betreiber muss weiterhin den finalisierten Moonlight-Verlauf einhalten, die Einzahlung korrekt zuordnen und sicherstellen, dass dieselbe Transaktion nicht zu zwei Buchungskrediten werden kann.
Das, was ich dabei interessanter fand, ist die Art, wie explizit das Fehlerhandling ausfällt. Ein gemeinsames Einzahlungskonto kann Memos für die Zuordnung zu Kunden verwenden, aber fehlende, fehlerhaft formatierte, unbekannte oder wiederverwendete Metadaten sollen quarantänisiert werden. Dann wird die Dusk-Transaktions-ID zum Idempotenzschlüssel, sodass ein erneut abgescanntes Replay nicht still und leise einen Kontostand doppelt.
Das ist kein besonders glamouröser Ablauf. Es ist genau die Art von Prozess, die darüber entscheidet, ob eine Exchange-Integration einen Neustart eines Nodes, einen Backfill oder eine chaotische Kundeneinzahlung überlebt, ohne dass die Abstimmung in manuelle Schadensbegrenzung abdriftet.
Für mich ist der eigentliche Test nicht, ob sich ein DUSK-Transfer fortpflanzt. Entscheidend ist, ob der Betreiber seinen Platz verlieren kann, den finalisierten Verlauf erneut scannen und dennoch beim selben Kunden-Ledger ankommen kann.
Wenn diese Invariante bricht, kann die Kette zwar korrekt sein, aber der Kontostand des Nutzers ist trotzdem falsch.
#dusk $DUSK @Dusk
Diese Antwort sagt mir lediglich, dass ein Rusk-Node die Transaktion zur Weiterleitung akzeptiert hat. Der Betreiber muss weiterhin den finalisierten Moonlight-Verlauf einhalten, die Einzahlung korrekt zuordnen und sicherstellen, dass dieselbe Transaktion nicht zu zwei Buchungskrediten werden kann.
Das, was ich dabei interessanter fand, ist die Art, wie explizit das Fehlerhandling ausfällt. Ein gemeinsames Einzahlungskonto kann Memos für die Zuordnung zu Kunden verwenden, aber fehlende, fehlerhaft formatierte, unbekannte oder wiederverwendete Metadaten sollen quarantänisiert werden. Dann wird die Dusk-Transaktions-ID zum Idempotenzschlüssel, sodass ein erneut abgescanntes Replay nicht still und leise einen Kontostand doppelt.
Das ist kein besonders glamouröser Ablauf. Es ist genau die Art von Prozess, die darüber entscheidet, ob eine Exchange-Integration einen Neustart eines Nodes, einen Backfill oder eine chaotische Kundeneinzahlung überlebt, ohne dass die Abstimmung in manuelle Schadensbegrenzung abdriftet.
Für mich ist der eigentliche Test nicht, ob sich ein DUSK-Transfer fortpflanzt. Entscheidend ist, ob der Betreiber seinen Platz verlieren kann, den finalisierten Verlauf erneut scannen und dennoch beim selben Kunden-Ledger ankommen kann.
Wenn diese Invariante bricht, kann die Kette zwar korrekt sein, aber der Kontostand des Nutzers ist trotzdem falsch.
#dusk $DUSK @Dusk
