#dusk $DUSK Ich habe vor Kurzem angefangen, mit Robotern zu traden. Der schlimmste Zustand, auf den ich gestoßen bin, ist folgender: Die Oberfläche zeigt ständig „Connected“, aber die Abfrage kommt viel zu spät oder gar nicht zurück, während der Bot dumm an dieser Leitung festhängt und wartet.
Im offiziellen Rusk-Repository von Dusk gibt es ein integriertes Issue: W3sper prüft, ob das Netzwerk online ist, hauptsächlich daran, ob die WebSocket-Verbindung der eigenen Maschine weiterhin im Zustand OPEN ist. Man kann es sich so vorstellen, dass das Telefon noch nicht aufgelegt hat. Wenn die Leitung nur halb abbricht, leuchtet das Gesprächs-Symbol trotzdem weiter, obwohl die Gegenstelle längst nichts mehr hört. Auch sein Keep-Alive-Mechanismus sendet im Wesentlichen nur regelmäßig Nachrichten nach außen – ohne eine Bestätigung, dass die Gegenstelle tatsächlich geantwortet hat.
Das führt dazu, dass der Handel in eine versteckte Falle gerät: Der Kontostand lässt sich nicht auslesen, der Stop-Loss kann nicht gesendet werden, die Quotes bleiben bei alten Preisen stehen, und der Bestand kann nicht angepasst werden. Noch schlimmer: Das System geht weiterhin davon aus, dass der primäre Knoten „online“ ist, während der Backup-Knoten erst viel zu spät übernimmt.
In so einer Situation wirkt die Chain zwar vielleicht in Ordnung, aber die Position hat bereits keinen Ausgang mehr.
Anfangs habe ich es einfach als eine kleine Macke innerhalb des SDK betrachtet. Nachdem ich das Positionsrisiko mit eingerechnet habe, wurde mir unruhig. Wie viel Kapital eine Institution einer Chain zuweist, wird direkt danach berechnet, wie lange der Fehler unentdeckt bleibt, wie lange es dauert, bis die Backup-Leitung wieder einspringt, und wie lange das Kapital im schlimmsten Fall gefangen ist. Im Schnitt macht eine Reaktionszeit, die nur um ein paar Millisekunden besser ist, am Ende weniger aus – das Gesamtgewicht liegt woanders.
Darum darf man Dusk „Online-Rate“ nicht nur an einem einzigen grünen Status festmachen. Ob die letzte Anfrage eine Antwort erhalten hat, wie oft es durchgehend zu Timeouts kommt, wie lange der Wechsel im langsamsten 5%-Fall dauert und wie oft der Backup-Knoten erfolgreich übernommen hat – diese Daten kommen der realen Handelserfahrung viel näher.
Ich glaube auch, dass das die Wertermittlung für $DUSK beeinflusst. Wenn man „quasi online“ ist, bleibt der Handel in dieser SDK-Ebene stecken: On-Chain sieht das dann vielleicht nur so aus, als gäbe es weniger Gebühren und weniger Transaktionen; die Institutionen könnten aber dadurch den ständig gehaltenen Bestand reduzieren und stattdessen mehr Backup-Kapital vorhalten. Wenn das Geld nicht langfristig auf der Chain bleiben kann, wird auch das Traden und der Gas-Bedarf automatisch geringer.
TPS sagt uns, wie schnell die Chain laufen kann. Die Fähigkeit für einen Failover bestimmt, ob das Geld im schlimmsten Marktumfeld noch herauslaufen kann. Ist das nicht genau die Handelserfahrung, die jeder – jede Institution – am meisten schätzt?
@Dusk
$BTC
Im offiziellen Rusk-Repository von Dusk gibt es ein integriertes Issue: W3sper prüft, ob das Netzwerk online ist, hauptsächlich daran, ob die WebSocket-Verbindung der eigenen Maschine weiterhin im Zustand OPEN ist. Man kann es sich so vorstellen, dass das Telefon noch nicht aufgelegt hat. Wenn die Leitung nur halb abbricht, leuchtet das Gesprächs-Symbol trotzdem weiter, obwohl die Gegenstelle längst nichts mehr hört. Auch sein Keep-Alive-Mechanismus sendet im Wesentlichen nur regelmäßig Nachrichten nach außen – ohne eine Bestätigung, dass die Gegenstelle tatsächlich geantwortet hat.
Das führt dazu, dass der Handel in eine versteckte Falle gerät: Der Kontostand lässt sich nicht auslesen, der Stop-Loss kann nicht gesendet werden, die Quotes bleiben bei alten Preisen stehen, und der Bestand kann nicht angepasst werden. Noch schlimmer: Das System geht weiterhin davon aus, dass der primäre Knoten „online“ ist, während der Backup-Knoten erst viel zu spät übernimmt.
In so einer Situation wirkt die Chain zwar vielleicht in Ordnung, aber die Position hat bereits keinen Ausgang mehr.
Anfangs habe ich es einfach als eine kleine Macke innerhalb des SDK betrachtet. Nachdem ich das Positionsrisiko mit eingerechnet habe, wurde mir unruhig. Wie viel Kapital eine Institution einer Chain zuweist, wird direkt danach berechnet, wie lange der Fehler unentdeckt bleibt, wie lange es dauert, bis die Backup-Leitung wieder einspringt, und wie lange das Kapital im schlimmsten Fall gefangen ist. Im Schnitt macht eine Reaktionszeit, die nur um ein paar Millisekunden besser ist, am Ende weniger aus – das Gesamtgewicht liegt woanders.
Darum darf man Dusk „Online-Rate“ nicht nur an einem einzigen grünen Status festmachen. Ob die letzte Anfrage eine Antwort erhalten hat, wie oft es durchgehend zu Timeouts kommt, wie lange der Wechsel im langsamsten 5%-Fall dauert und wie oft der Backup-Knoten erfolgreich übernommen hat – diese Daten kommen der realen Handelserfahrung viel näher.
Ich glaube auch, dass das die Wertermittlung für $DUSK beeinflusst. Wenn man „quasi online“ ist, bleibt der Handel in dieser SDK-Ebene stecken: On-Chain sieht das dann vielleicht nur so aus, als gäbe es weniger Gebühren und weniger Transaktionen; die Institutionen könnten aber dadurch den ständig gehaltenen Bestand reduzieren und stattdessen mehr Backup-Kapital vorhalten. Wenn das Geld nicht langfristig auf der Chain bleiben kann, wird auch das Traden und der Gas-Bedarf automatisch geringer.
TPS sagt uns, wie schnell die Chain laufen kann. Die Fähigkeit für einen Failover bestimmt, ob das Geld im schlimmsten Marktumfeld noch herauslaufen kann. Ist das nicht genau die Handelserfahrung, die jeder – jede Institution – am meisten schätzt?
@Dusk
$BTC