Ich habe eine eher unauffällige Buchhaltungsregel aus den Aufladedokumenten der Dusk-Börse herausgegriffen und genauer angesehen: Warum muss bei einer Einzahlung eine Transaktions-ID als Idempotency-Key verwendet werden? Denn „einmal gescannt“ ist nicht dasselbe wie „genau einmal verbucht“. Die offizielle Empfehlung lautet, dass der Lade-Scanner die bereits finalisierten Moonlight-Historien liest; bei jeder Verbuchung wird die Dusk-Transaktions-ID als Idempotency-Key genutzt, und gleichzeitig werden die Buchungsaufzeichnung und der Block-Checkpoint atomar aktualisiert. Fehlende, fehlerhafte, unbekannte oder doppelte Memo-Metadaten müssen erst isoliert werden und dürfen nicht einfach in die Buchhaltung übernommen werden. In der Doku steht außerdem ausdrücklich, dass man den Nutzern nicht vorzeitig Guthaben geben sollte – nicht anhand von Bilanzänderungen, nicht anhand des lokalen Mempools, nicht anhand von events wie „transactions/included“ und auch nicht anhand noch nicht finalisierter Blöcke. Diese Signale zeigen nur, dass ein Knoten irgendeine Änderung gesehen hat; das bedeutet nicht, dass die Verwahrbuchhaltung die endgültige Tatsache der Einzahlung bereits erhalten hat.
Nehmen wir ein einfaches Beispiel: Dieselbe 100 DUSK Einzahlung wird dreimal erneut gelesen, weil der Scanner neu startet, der Knoten gewechselt wird oder die Historie nachgeladen wird. Wenn das System nur „sieht und dann Guthaben hinzufügt“, wird fälschlicherweise 300 verbucht. Mit Abgleich über die Transaktions-ID dagegen entsprechen drei Lesevorgänge weiterhin genau einer Einzahlung von 100. Noch wichtiger ist: Checkpoint und Verbuchung müssen zusammen eingereicht werden. Wenn zuerst das Guthaben erhöht wird und danach erst die Scanhöhe geschrieben wird, kann ein Zwischencrash dazu führen, dass nach dem Neustart dieselbe Transaktion erneut gescannt wird. Hier geht es nicht um Double-Spends auf der Kette, sondern um doppelte Buchungen im Backend. Die Korrektheit der Einzahlung hängt außerdem davon ab, ob der Datenbank-Zustandsautomat nach Neustarts und Nachscans stets zum selben Ergebnis gelangt. $BTC
BTC-Nutzer kennen „erst nach Bestätigung verbuchen“, aber Bestätigung löst das Stabilitätsproblem der Transaktion – sie verhindert nicht automatisch, dass die Börsen-Datenbank die Transaktion eventuell mehrfach verarbeitet. In der ETH-Ökonomie machen Indexer zudem häufig Block-Rückscans; Dusk schreibt den Idempotency-Key und den atomaren Checkpoint direkt in die integrierten Empfehlungen – das bedeutet, das Risiko des Abgleichens wird bereits in das Interface-Design verlagert.$ETH
Daher schaue ich mir bei der Anpassung für die Börse rund um @Dusk vor allem nicht nur die Einzahlungs-Geschwindigkeit an. Für $DUSK ist für die Nutzererfahrung entscheidend, ob dieselbe On-Chain-Wahrheit im Verwahrbuch über die Zeit hinweg immer nur genau einmal erfasst werden kann. In Zukunft will ich vor allem sehen, ob gängige Integrationen öffentlich klar zwischen „bereits gescannt“, „bereits final bestätigt“ und „bereits verbucht“ unterscheiden – und ob es für fehlerhafte oder ungewöhnliche Memo-Metadaten klare manuelle Bearbeitungszustände gibt. Das ist näher an Verlässlichkeit als das bloße schnelle Springen der Seite beim Anzeigen des Guthabens.#dusk
Nehmen wir ein einfaches Beispiel: Dieselbe 100 DUSK Einzahlung wird dreimal erneut gelesen, weil der Scanner neu startet, der Knoten gewechselt wird oder die Historie nachgeladen wird. Wenn das System nur „sieht und dann Guthaben hinzufügt“, wird fälschlicherweise 300 verbucht. Mit Abgleich über die Transaktions-ID dagegen entsprechen drei Lesevorgänge weiterhin genau einer Einzahlung von 100. Noch wichtiger ist: Checkpoint und Verbuchung müssen zusammen eingereicht werden. Wenn zuerst das Guthaben erhöht wird und danach erst die Scanhöhe geschrieben wird, kann ein Zwischencrash dazu führen, dass nach dem Neustart dieselbe Transaktion erneut gescannt wird. Hier geht es nicht um Double-Spends auf der Kette, sondern um doppelte Buchungen im Backend. Die Korrektheit der Einzahlung hängt außerdem davon ab, ob der Datenbank-Zustandsautomat nach Neustarts und Nachscans stets zum selben Ergebnis gelangt. $BTC
BTC-Nutzer kennen „erst nach Bestätigung verbuchen“, aber Bestätigung löst das Stabilitätsproblem der Transaktion – sie verhindert nicht automatisch, dass die Börsen-Datenbank die Transaktion eventuell mehrfach verarbeitet. In der ETH-Ökonomie machen Indexer zudem häufig Block-Rückscans; Dusk schreibt den Idempotency-Key und den atomaren Checkpoint direkt in die integrierten Empfehlungen – das bedeutet, das Risiko des Abgleichens wird bereits in das Interface-Design verlagert.$ETH
Daher schaue ich mir bei der Anpassung für die Börse rund um @Dusk vor allem nicht nur die Einzahlungs-Geschwindigkeit an. Für $DUSK ist für die Nutzererfahrung entscheidend, ob dieselbe On-Chain-Wahrheit im Verwahrbuch über die Zeit hinweg immer nur genau einmal erfasst werden kann. In Zukunft will ich vor allem sehen, ob gängige Integrationen öffentlich klar zwischen „bereits gescannt“, „bereits final bestätigt“ und „bereits verbucht“ unterscheiden – und ob es für fehlerhafte oder ungewöhnliche Memo-Metadaten klare manuelle Bearbeitungszustände gibt. Das ist näher an Verlässlichkeit als das bloße schnelle Springen der Seite beim Anzeigen des Guthabens.#dusk