Ich bin letzte Nacht noch einmal durch die @Dusk -Dokumentation gegangen, insbesondere den Abschnitt zu deren Succinct Attestation-Konsens. Es ist ein permissionlesses, komiteebasiertes Proof-of-Stake-Setup, das von Provisionern betrieben wird....jeder, der mindestens 1000 DUSK als Stake ver- bzw. hinterlegt.
Ein Stake ist im Grunde nur die Menge plus die Blockhöhe, in der er aufgenommen wurde. Die Eignung tritt nicht sofort ein. Es gibt eine Sperr-/Reifefrist, die als M = 2 × epoch − (height mod epoch) berechnet wird, und die Epoch ist derzeit 2160 Blöcke. Erst nach diesem Reifezeitfenster und wenn der Betrag die Mindestanforderung erfüllt, geht der Stake in die deterministische Sortitionslotterie über, die den Blockgenerator und die Voting-Komitees für jede Runde auswählt.
Der Ablauf selbst läuft in Runden und Iterationen. Jede Iteration hat drei Schritte: Proposal (ein Provisioner wird ausgewählt, um einen Kandidatenblock vorzuschlagen), Validierung (ein Komitee stimmt Valid, Invalid oder NoCandidate ab; für Valid ist eine 2/3-Übermehrheit nötig oder für Invalid eine einfache Mehrheit), und Ratifikation (ein frisches Komitee bestätigt das Ergebnis). Eine Runde kann bis zu 50 Iterationen durchlaufen, bevor sie fehlschlägt.
Was mir immer noch durch den Kopf geht, ist, wie die nicht-interaktive Sortition und die rotierenden Komitees sich tatsächlich auf die langfristige Dezentralisierung und das Risiko eines Komitee-Captures auswirken. Die festen Parameter....1000 DUSK Minimum, 2160-Block-Epochs, Cap von 50 Iterationen
....wirken bewusst gewählt, aber ich konnte keine klare Diskussion finden, wie sie später ggf. angepasst werden könnten oder welcher Governance-Prozess das steuern würde.
Mich interessiert, wie andere die Sicherheitsannahmen rund um die Voting-Komitees und die Reifeverzögerung interpretieren. Fühlt sich das Design für euch robust an, oder übersehe ich wichtige Edge Cases?
#dusk $DUSK
Ein Stake ist im Grunde nur die Menge plus die Blockhöhe, in der er aufgenommen wurde. Die Eignung tritt nicht sofort ein. Es gibt eine Sperr-/Reifefrist, die als M = 2 × epoch − (height mod epoch) berechnet wird, und die Epoch ist derzeit 2160 Blöcke. Erst nach diesem Reifezeitfenster und wenn der Betrag die Mindestanforderung erfüllt, geht der Stake in die deterministische Sortitionslotterie über, die den Blockgenerator und die Voting-Komitees für jede Runde auswählt.
Der Ablauf selbst läuft in Runden und Iterationen. Jede Iteration hat drei Schritte: Proposal (ein Provisioner wird ausgewählt, um einen Kandidatenblock vorzuschlagen), Validierung (ein Komitee stimmt Valid, Invalid oder NoCandidate ab; für Valid ist eine 2/3-Übermehrheit nötig oder für Invalid eine einfache Mehrheit), und Ratifikation (ein frisches Komitee bestätigt das Ergebnis). Eine Runde kann bis zu 50 Iterationen durchlaufen, bevor sie fehlschlägt.
Was mir immer noch durch den Kopf geht, ist, wie die nicht-interaktive Sortition und die rotierenden Komitees sich tatsächlich auf die langfristige Dezentralisierung und das Risiko eines Komitee-Captures auswirken. Die festen Parameter....1000 DUSK Minimum, 2160-Block-Epochs, Cap von 50 Iterationen
....wirken bewusst gewählt, aber ich konnte keine klare Diskussion finden, wie sie später ggf. angepasst werden könnten oder welcher Governance-Prozess das steuern würde.
Mich interessiert, wie andere die Sicherheitsannahmen rund um die Voting-Komitees und die Reifeverzögerung interpretieren. Fühlt sich das Design für euch robust an, oder übersehe ich wichtige Edge Cases?
#dusk $DUSK