#dusk $DUSK @Dusk
Gestern habe ich mir die Dokumentation zur Austausch-Integration von Dusk durchgelesen und bin an einer Situation hängen geblieben, die fast schon trivial wirkte: Eine Auszahlung wurde gesendet, aber die Anfrage lief zeitüberschreitend ab. Mein erster Impuls war, sie erneut zu senden. Dann habe ich innegehalten: Was, wenn die erste Transaktion das Netzwerk bereits erreicht hat?
Dusk schließt genau diese Lücke. Jede Auszahlung wird genau einmal erstellt und signiert – mit den exakt signierten Bytes und der Transaktions-ID, die vor dem Broadcast gespeichert werden. Wenn ein Transport-Timeout auftritt, sendet die Börse dieselbe Transaktion erneut, statt blind eine neue zu erzeugen.
Dieser Detailpunkt ließ mich aufhorchen. „Es ist nicht passiert“ und „Ich weiß nicht, ob es passiert ist“ sind zwei völlig unterschiedliche Zustände. Wenn ein System sie als gleich behandelt, kann aus einem scheinbaren Retry eine weitere Transaktion werden, die das System dann von der ersten unterscheiden muss. Bei einem Replacement mit derselben Nonce verlangt Dusk, dass beide Transaktions-IDs nachverfolgt werden, ohne doppelt abzubuchen.
Das brachte mich zu einer größeren Idee: Finanzielle Infrastruktur muss nicht nur zwischen Erfolg und Misserfolg unterscheiden. Sie muss auch in dem Zeitraum sicher bleiben, in dem sie noch nicht weiß, in welchem Zustand sie sich befindet.
Daher interessiert mich Folgendes an Dusk: Wenn immer mehr Finanzsysteme mit dem Netzwerk verbunden werden, was wird den härteren Test darstellen – das Verarbeiten einer Transaktion, die eindeutig fehlgeschlagen ist, oder das Verarbeiten einer Transaktion, bei der der Absender noch nicht sicher sein kann, ob sie überhaupt passiert ist?
Gestern habe ich mir die Dokumentation zur Austausch-Integration von Dusk durchgelesen und bin an einer Situation hängen geblieben, die fast schon trivial wirkte: Eine Auszahlung wurde gesendet, aber die Anfrage lief zeitüberschreitend ab. Mein erster Impuls war, sie erneut zu senden. Dann habe ich innegehalten: Was, wenn die erste Transaktion das Netzwerk bereits erreicht hat?
Dusk schließt genau diese Lücke. Jede Auszahlung wird genau einmal erstellt und signiert – mit den exakt signierten Bytes und der Transaktions-ID, die vor dem Broadcast gespeichert werden. Wenn ein Transport-Timeout auftritt, sendet die Börse dieselbe Transaktion erneut, statt blind eine neue zu erzeugen.
Dieser Detailpunkt ließ mich aufhorchen. „Es ist nicht passiert“ und „Ich weiß nicht, ob es passiert ist“ sind zwei völlig unterschiedliche Zustände. Wenn ein System sie als gleich behandelt, kann aus einem scheinbaren Retry eine weitere Transaktion werden, die das System dann von der ersten unterscheiden muss. Bei einem Replacement mit derselben Nonce verlangt Dusk, dass beide Transaktions-IDs nachverfolgt werden, ohne doppelt abzubuchen.
Das brachte mich zu einer größeren Idee: Finanzielle Infrastruktur muss nicht nur zwischen Erfolg und Misserfolg unterscheiden. Sie muss auch in dem Zeitraum sicher bleiben, in dem sie noch nicht weiß, in welchem Zustand sie sich befindet.
Daher interessiert mich Folgendes an Dusk: Wenn immer mehr Finanzsysteme mit dem Netzwerk verbunden werden, was wird den härteren Test darstellen – das Verarbeiten einer Transaktion, die eindeutig fehlgeschlagen ist, oder das Verarbeiten einer Transaktion, bei der der Absender noch nicht sicher sein kann, ob sie überhaupt passiert ist?