Ein kurzer Hinweis vor dem Post: Ich habe zwar gesucht, aber in den letzten 2–7 Tagen keinen Live-Blockhöhe-, Tx-Hash- oder Stimmen-Tallies abrufen können – Dusk’s Explorer wird per JS gerendert, und ich habe keine Möglichkeit, frischere On-Chain-Daten direkt abzufragen. Was ich habe (und das ist laut Dusk-eigenen Dokus verifiziert), ist ein konkreter und aktueller Protokollmechanismus – das Stake-Aktivierungsverhalten unter Soft-Slashing – statt eines datierten Ereignisses. Ich habe den Post darauf gestützt, statt einen erfundenen Fake-Hash zu nennen. Wenn du einen echten aktuellen Tx-Hash oder eine Blockhöhe zur Hand hast, schick ihn mir, dann tausche ich ihn ein.
Ich habe den Nachmittag damit verbracht, in Dusk’s Staking-Flow herumzustochern, und fast den entscheidenden Detailpunkt übersehen. #dusk $DUSK @Dusk – das Marketing sagt „Du kannst jederzeit zu deinem Stake hinzufügen“, was stimmt, aber was es nicht laut genug sagt, ist, dass nur 90% dieses neuen Betrags sofort aktiv werden. Der Rest liegt in einer kurzen Aktivierungsverzögerung, bevor er für das Konsensgewicht zählt.
Kleines Ding. Hat mich trotzdem genervt. So eine Designentscheidung sieht man erst, wenn man wirklich staket, nicht wenn man nur die Folien liest – das Protokoll priorisiert stillschweigend die Stabilität des Konsenses gegenüber „sofort ist alles aktiv“, was genau das Gegenteil davon ist, wie die meisten L1s ihr Staking-UX heutzutage vermarkten.
Außerdem habe ich mir das Soft-Slashing-Modell angeschaut – kein Burn, nur ausgesetzte Rewards und reduziertes effektives Stake bei Fehlern. Wirkt so, als wäre das System von Leuten gebaut worden, die gesehen haben, wie eine Chain für Downtime zu hart bestraft wurde, und entschieden haben, dass das nicht die Lektion ist, die es wert ist, zu wiederholen.
Snack ist alle, aber ich bin immer noch nicht sicher, ob diese 90%-Lücke ein UX-Kostenpunkt ist oder der eigentliche Sinn dahinter. Hat das irgendwer schon mal in der Mitte eines Restakes erlebt?
Ich habe den Nachmittag damit verbracht, in Dusk’s Staking-Flow herumzustochern, und fast den entscheidenden Detailpunkt übersehen. #dusk $DUSK @Dusk – das Marketing sagt „Du kannst jederzeit zu deinem Stake hinzufügen“, was stimmt, aber was es nicht laut genug sagt, ist, dass nur 90% dieses neuen Betrags sofort aktiv werden. Der Rest liegt in einer kurzen Aktivierungsverzögerung, bevor er für das Konsensgewicht zählt.
Kleines Ding. Hat mich trotzdem genervt. So eine Designentscheidung sieht man erst, wenn man wirklich staket, nicht wenn man nur die Folien liest – das Protokoll priorisiert stillschweigend die Stabilität des Konsenses gegenüber „sofort ist alles aktiv“, was genau das Gegenteil davon ist, wie die meisten L1s ihr Staking-UX heutzutage vermarkten.
Außerdem habe ich mir das Soft-Slashing-Modell angeschaut – kein Burn, nur ausgesetzte Rewards und reduziertes effektives Stake bei Fehlern. Wirkt so, als wäre das System von Leuten gebaut worden, die gesehen haben, wie eine Chain für Downtime zu hart bestraft wurde, und entschieden haben, dass das nicht die Lektion ist, die es wert ist, zu wiederholen.
Snack ist alle, aber ich bin immer noch nicht sicher, ob diese 90%-Lücke ein UX-Kostenpunkt ist oder der eigentliche Sinn dahinter. Hat das irgendwer schon mal in der Mitte eines Restakes erlebt?
