#dusk $DUSK 协议升级前, ich normalerweise erst eine Runde Überweisung, Verifikation der Signatur und Vertragsaufruf durch. Alle Tests waren erfolgreich, die Börse bereitet die Wiederaufnahme von Ein- und Auszahlungen vor, und der Bot beginnt, den temporären Hedge abzubauen. Dann wird der DUSK-Bestand wieder auf den Markt gelegt. Das ist ein ganz gewöhnliches Szenario.
Aber Dusk hat eine kleine Details, die mich daran erinnert, nicht gleich auf „Wiederherstellen“ zu drücken.
In der lokalen temporären VM von Dusk: Wenn ich die Blockhöhe auf Boreas setze, heißt das nur, dass das Programm diese Zeit simuliert. Nach welchen Regeln die BLS-Signatur geprüft wird, und auch die Host-Query-Policy muss separat gesetzt werden. Fehlt dieser Schritt, steht im Test-Interface zwar „Boreas“, die Backend-seitige Signaturverifikation verwendet jedoch möglicherweise weiterhin die alten PreFork-Regeln.
Das kann zu einem sehr realen Handelsunfall führen: Der Bot testet unter den alten Regeln erfolgreich, aber nach dem Upgrade des offiziellen Nodes wird die Transaktion nach den neuen Regeln abgelehnt. Gerade erst hat die Börse die Ein- und Auszahlungen wieder aktiviert, und die Benutzer-Auszahlungen stecken fest; der Market-Maker-Bestand, der den Hedge bereits abgebaut hat, kann On-Chain nicht mehr nachgefüllt werden. Ein einzelnes grünes Häkchen im Testbericht kann am Ende zu einem ausgedünnten Orderbuch und stehenden Geldern führen.
Als ich das erste Mal gesehen habe, dass Blockhöhe und Verifikationsregeln getrennt eingestellt werden, dachte ich, das sei ein bisschen umständlich. Aber wenn man den echten Bestand einträgt, ist diese „Umständlichkeit“ eigentlich ziemlich wertvoll: Entwickler, Auditoren und Börsen müssen klar dokumentieren, welche Protokollvariante sie testen, damit andere das unter exakt derselben Version auch erneut nachvollziehen können. Damit ist zumindest transparent, was das Ganze letztlich „sicher“ macht – nicht nur, um Handelsumstände zu reduzieren, sondern auch als Erklärung für mehr Sicherheit.
Ich finde, genau das ist ein sehr wertvoller Punkt von Dusk für den Handel. Upgrade-Nachweise für Finanz-Ketten dürfen nicht nur „Tests bestanden“ lauten. Es müssen auch die Rusk-Version, die Hard-Fork-Strategie und die Signaturregeln enthalten sein. Wenn diese drei Dinge zueinander passen, traut sich das Handelsteam, die Downtime bei Ein- und Auszahlungen zu verkürzen, Reservebestände zu reduzieren und das Geld schneller wieder in Umlauf zu bringen.
Für $DUSK wird die technische Vertrauenswürdigkeit am Ende auf eine ganz konkrete Buchung hinauslaufen: Nach dem Upgrade gibt es weniger fehlgeschlagene Transaktionen, die Börse nimmt Ein- und Auszahlungen früher wieder auf, Market-Maker-Gelder kommen schneller zurück in die Kette, und echte Aufrufe sowie Gas können kontinuierlich stattfinden.
Nur „alles grün“ bedeutet: Das Programm ist durchgelaufen. Und erst wenn auch die Regeln zusammenpassen, traut sich der Markt, das Geld wieder zurückzugeben. Kurz gesagt: Meine persönliche Erfahrung ist, dass, wenn es um technische Vertrauenswürdigkeit geht, jedes noch so kleine Detail sehr wichtig ist.
@Dusk
$BTC
Aber Dusk hat eine kleine Details, die mich daran erinnert, nicht gleich auf „Wiederherstellen“ zu drücken.
In der lokalen temporären VM von Dusk: Wenn ich die Blockhöhe auf Boreas setze, heißt das nur, dass das Programm diese Zeit simuliert. Nach welchen Regeln die BLS-Signatur geprüft wird, und auch die Host-Query-Policy muss separat gesetzt werden. Fehlt dieser Schritt, steht im Test-Interface zwar „Boreas“, die Backend-seitige Signaturverifikation verwendet jedoch möglicherweise weiterhin die alten PreFork-Regeln.
Das kann zu einem sehr realen Handelsunfall führen: Der Bot testet unter den alten Regeln erfolgreich, aber nach dem Upgrade des offiziellen Nodes wird die Transaktion nach den neuen Regeln abgelehnt. Gerade erst hat die Börse die Ein- und Auszahlungen wieder aktiviert, und die Benutzer-Auszahlungen stecken fest; der Market-Maker-Bestand, der den Hedge bereits abgebaut hat, kann On-Chain nicht mehr nachgefüllt werden. Ein einzelnes grünes Häkchen im Testbericht kann am Ende zu einem ausgedünnten Orderbuch und stehenden Geldern führen.
Als ich das erste Mal gesehen habe, dass Blockhöhe und Verifikationsregeln getrennt eingestellt werden, dachte ich, das sei ein bisschen umständlich. Aber wenn man den echten Bestand einträgt, ist diese „Umständlichkeit“ eigentlich ziemlich wertvoll: Entwickler, Auditoren und Börsen müssen klar dokumentieren, welche Protokollvariante sie testen, damit andere das unter exakt derselben Version auch erneut nachvollziehen können. Damit ist zumindest transparent, was das Ganze letztlich „sicher“ macht – nicht nur, um Handelsumstände zu reduzieren, sondern auch als Erklärung für mehr Sicherheit.
Ich finde, genau das ist ein sehr wertvoller Punkt von Dusk für den Handel. Upgrade-Nachweise für Finanz-Ketten dürfen nicht nur „Tests bestanden“ lauten. Es müssen auch die Rusk-Version, die Hard-Fork-Strategie und die Signaturregeln enthalten sein. Wenn diese drei Dinge zueinander passen, traut sich das Handelsteam, die Downtime bei Ein- und Auszahlungen zu verkürzen, Reservebestände zu reduzieren und das Geld schneller wieder in Umlauf zu bringen.
Für $DUSK wird die technische Vertrauenswürdigkeit am Ende auf eine ganz konkrete Buchung hinauslaufen: Nach dem Upgrade gibt es weniger fehlgeschlagene Transaktionen, die Börse nimmt Ein- und Auszahlungen früher wieder auf, Market-Maker-Gelder kommen schneller zurück in die Kette, und echte Aufrufe sowie Gas können kontinuierlich stattfinden.
Nur „alles grün“ bedeutet: Das Programm ist durchgelaufen. Und erst wenn auch die Regeln zusammenpassen, traut sich der Markt, das Geld wieder zurückzugeben. Kurz gesagt: Meine persönliche Erfahrung ist, dass, wenn es um technische Vertrauenswürdigkeit geht, jedes noch so kleine Detail sehr wichtig ist.
@Dusk
$BTC