#dusk $DUSK @Dusk
Ich habe letzten Monat eine Stimme um vierzig Sekunden verpasst und die nächste Stunde damit verbracht, mein Dashboard zu aktualisieren, überzeugt davon, dass ich meinen Anteil verloren hatte. Es stellte sich heraus, dass dem nicht so war. Das hat mich in ein Kaninchenloch geführt, wie das Belohnungssystem von Dusk tatsächlich funktioniert – und das Design hat diese Sorge besser beantwortet, als ich erwartet hatte.
Die Aufteilung der Belohnung gibt dem Blockgenerator bis zu achtzig Prozent davon, wobei ein Teil dieses zusätzlichen Anteils davon abhängt, wie viele Credits in das Zertifikat aufgenommen werden. Zehn Prozent gehen an einen Entwicklungsfonds, und die letzten zehn werden gleichmäßig zwischen Validierungs- und Ratifizierungskomitees aufgeteilt. Nichts Überraschendes. Was jedoch auffiel, war, wie gezielt sie zugunsten des Generators gewichtet ist. Anfangs wirkte es seltsam, dass so viel an eine Rolle geht, aber es ergibt Sinn, wenn man darüber nachdenkt, wer pro Block tatsächlich die schwere Arbeit leistet.
Der Teil, der wirklich zählt, ist das Sondersystem für Fehler. Dusk unterscheidet kleinere Fehler von größeren, statt jede Art von Versehen gleich zu behandeln. Wenn du eine Stimme verpasst, weil dein Knoten kurz hakt, wirst du für eine Weile ausgesetzt – mit einem vorübergehend gesperrten Anteil. Nichts wird verbrannt. Wenn du dagegen etwas nachweislich Schädliches tust, etwa indem du widersprüchliche Stimmen signierst, fällt das in eine ganz andere Kategorie – mit realem, verbranntem Anteil. Ich erinnere mich, Protokolle vor Jahren gelesen zu haben, in denen bei jeder Downtime einfach Anteil verbrannt wurde, und ehrlich gesagt wirkte das immer eher strafend als schützend.
Vielleicht denke ich zu viel darüber nach, aber diese Unterscheidung fühlt sich wie die eigentliche Design-Einsicht hier an. Sie bestraft keine ehrlichen Operatoren für Infrastrukturprobleme, macht aber gezielte Angriffe teuer. Ob diese Balance sich unter echter Netzlast im großen Maßstab bewährt, ist etwas, das mich noch interessiert. Slashingsysteme wirken auf dem Papier immer sauberer als sie es in der Praxis sind, sobald tausende Validatoren sie wirklich laufen haben.
$TUT
$ZRO
Wie sollte Dusk Validatorfehler behandeln?
Ich habe letzten Monat eine Stimme um vierzig Sekunden verpasst und die nächste Stunde damit verbracht, mein Dashboard zu aktualisieren, überzeugt davon, dass ich meinen Anteil verloren hatte. Es stellte sich heraus, dass dem nicht so war. Das hat mich in ein Kaninchenloch geführt, wie das Belohnungssystem von Dusk tatsächlich funktioniert – und das Design hat diese Sorge besser beantwortet, als ich erwartet hatte.
Die Aufteilung der Belohnung gibt dem Blockgenerator bis zu achtzig Prozent davon, wobei ein Teil dieses zusätzlichen Anteils davon abhängt, wie viele Credits in das Zertifikat aufgenommen werden. Zehn Prozent gehen an einen Entwicklungsfonds, und die letzten zehn werden gleichmäßig zwischen Validierungs- und Ratifizierungskomitees aufgeteilt. Nichts Überraschendes. Was jedoch auffiel, war, wie gezielt sie zugunsten des Generators gewichtet ist. Anfangs wirkte es seltsam, dass so viel an eine Rolle geht, aber es ergibt Sinn, wenn man darüber nachdenkt, wer pro Block tatsächlich die schwere Arbeit leistet.
Der Teil, der wirklich zählt, ist das Sondersystem für Fehler. Dusk unterscheidet kleinere Fehler von größeren, statt jede Art von Versehen gleich zu behandeln. Wenn du eine Stimme verpasst, weil dein Knoten kurz hakt, wirst du für eine Weile ausgesetzt – mit einem vorübergehend gesperrten Anteil. Nichts wird verbrannt. Wenn du dagegen etwas nachweislich Schädliches tust, etwa indem du widersprüchliche Stimmen signierst, fällt das in eine ganz andere Kategorie – mit realem, verbranntem Anteil. Ich erinnere mich, Protokolle vor Jahren gelesen zu haben, in denen bei jeder Downtime einfach Anteil verbrannt wurde, und ehrlich gesagt wirkte das immer eher strafend als schützend.
Vielleicht denke ich zu viel darüber nach, aber diese Unterscheidung fühlt sich wie die eigentliche Design-Einsicht hier an. Sie bestraft keine ehrlichen Operatoren für Infrastrukturprobleme, macht aber gezielte Angriffe teuer. Ob diese Balance sich unter echter Netzlast im großen Maßstab bewährt, ist etwas, das mich noch interessiert. Slashingsysteme wirken auf dem Papier immer sauberer als sie es in der Praxis sind, sobald tausende Validatoren sie wirklich laufen haben.
$TUT
$ZRO
Wie sollte Dusk Validatorfehler behandeln?
🟢 Suspend
100%
🔥 Slash
0%
⚖️ Both
0%
🤔 Depends
0%
1 Stimmen • Abstimmung beendet