Ich führe eine laufende Liste mit Protokoll-Annahmen, die niemand ernsthaft unter Belastung testet, und Dusk's Succinct Attestation hat gerade einen Platz darauf bekommen.
Alle reden über Stake-Konzentration in PoS, als wäre das nur eine einzige Zahl, die ein Wal X% hält und damit X% des Komitees kontrolliert. Dusk's Sortition funktioniert nicht so. Jede Provisioniererin bzw. jeder Provisionierer erhält Credits basierend auf dem Stake, aber jedes Mal, wenn ein Credit zugewiesen wird, sinkt das effektive Gewicht dieser Provisioniererin bzw. dieses Provisionierers für den nächsten Credit um 1 DUSK. Abnehmende Erträge sind bereits in der Auswahl selbst eingebaut. Reine Dominanz durch Stake übersetzt sich nicht linear in Dominanz im Komitee.
Sauberer als ich erwartet hatte. Aber das eigentliche Risiko ist nicht die Credit-Reduktionsrechnung, sondern das Minimum von 1.000 DUSK plus die Maturitätsverzögerung, bevor ein Stake aktiv wird. Das ist die eigentliche Engstelle—ein Zugangsproblem, nicht ein Sortitionsfehler. Das heißt, das Konzentrationsrisiko hier dürfte eher von Pooling-/Delegationsdiensten kommen, die kleine Holder bündeln, um diese Schwelle mit Custody zu erreichen, nicht von Kryptografie. Ein Governance-Problem, gekleidet in einem technischen Anzug.
Das andere, woran ich immer wieder herumgestochert habe: Emergency Mode. Wenn das Netzwerk nach genug Iterationen kein Quorum erreichen kann, fällt DUSK auf die niedrigste Iteration zurück, die deterministisch gewinnt—keine zusätzliche Abstimmungsrunde. Effizient für einen kurzen Aussetzer. Aber wenn man es gegen eine gezielte Eclipse-artige Störung laufen lässt, bei der gerade genug Provisionierer still bleiben, könnte derselbe Mechanismus immer wieder erneut auslösen und die Rundendauern in die Länge ziehen. Ein Liveness-Kostenfaktor, nicht einer der Safety—klassischer BFT-Kompromiss, aber ich bin nicht überzeugt, dass das über ein Spec-Read-through hinaus validiert wurde. Simulationstests von Partitionen würden mehr zeigen als das Whitepaper.
Kein klares Urteil. Auf Papier gut vertretbar. Ob es unter adversarialem Druck standhält, ist für mich immer noch offen—nicht entschieden.
#dusk $DUSK @Dusk
Alle reden über Stake-Konzentration in PoS, als wäre das nur eine einzige Zahl, die ein Wal X% hält und damit X% des Komitees kontrolliert. Dusk's Sortition funktioniert nicht so. Jede Provisioniererin bzw. jeder Provisionierer erhält Credits basierend auf dem Stake, aber jedes Mal, wenn ein Credit zugewiesen wird, sinkt das effektive Gewicht dieser Provisioniererin bzw. dieses Provisionierers für den nächsten Credit um 1 DUSK. Abnehmende Erträge sind bereits in der Auswahl selbst eingebaut. Reine Dominanz durch Stake übersetzt sich nicht linear in Dominanz im Komitee.
Sauberer als ich erwartet hatte. Aber das eigentliche Risiko ist nicht die Credit-Reduktionsrechnung, sondern das Minimum von 1.000 DUSK plus die Maturitätsverzögerung, bevor ein Stake aktiv wird. Das ist die eigentliche Engstelle—ein Zugangsproblem, nicht ein Sortitionsfehler. Das heißt, das Konzentrationsrisiko hier dürfte eher von Pooling-/Delegationsdiensten kommen, die kleine Holder bündeln, um diese Schwelle mit Custody zu erreichen, nicht von Kryptografie. Ein Governance-Problem, gekleidet in einem technischen Anzug.
Das andere, woran ich immer wieder herumgestochert habe: Emergency Mode. Wenn das Netzwerk nach genug Iterationen kein Quorum erreichen kann, fällt DUSK auf die niedrigste Iteration zurück, die deterministisch gewinnt—keine zusätzliche Abstimmungsrunde. Effizient für einen kurzen Aussetzer. Aber wenn man es gegen eine gezielte Eclipse-artige Störung laufen lässt, bei der gerade genug Provisionierer still bleiben, könnte derselbe Mechanismus immer wieder erneut auslösen und die Rundendauern in die Länge ziehen. Ein Liveness-Kostenfaktor, nicht einer der Safety—klassischer BFT-Kompromiss, aber ich bin nicht überzeugt, dass das über ein Spec-Read-through hinaus validiert wurde. Simulationstests von Partitionen würden mehr zeigen als das Whitepaper.
Kein klares Urteil. Auf Papier gut vertretbar. Ob es unter adversarialem Druck standhält, ist für mich immer noch offen—nicht entschieden.
#dusk $DUSK @Dusk
