Ich bin letzte Nacht noch einmal durch das Dusk-Whitepaper gegangen, und der Abschnitt „Consensus“ hat mich ausbremsen lassen. Dusk verwendet Succinct Attestation mit permissionless, komitee-basiertem Proof of Stake. Es ist ein Mindestbetrag von 1.000 DUSK erforderlich, während die aktuelle Epoche 2.160 Blöcke umfasst. Jede Runde kann bis zu 50 Iterationen ausführen, und die Komitees haben 64 Credits, sodass die Abstimmungsmacht gewichtet ist – statt „eine Person, eine Stimme“.
Was ich interessant fand, ist die Schwellenstruktur: „Valid“ braucht 2/3, während „Invalid“, „NoCandidate“ oder „NoQuorum“ eine Mehrheit von 1/2 + 1 erreichen können. Nach 16 fehlgeschlagenen Iterationen kann das Protokoll in den Emergency Mode wechseln, was die Frage aufwirft, wie es um Liveness im Verhältnis zum Fork-Risiko steht.
Auch das Anreizdesign hat meine Aufmerksamkeit erregt: 80 % gehen an den Block-Generator, 10 % an das Abstimmkomitee und 10 % an Dusk. Die 80 % des Generators setzen sich aus 70 % Fixanteil plus einem variablen Anteil von 10 % zusammen, der an die einbezogenen Stimmen gekoppelt ist. Gröbere Fehler wie doppeltes Abstimmen können ein hartes Slashing auslösen.
Dann haben Moonlight und Phoenix mir die Architektur klarer gemacht: öffentliche konto-basierte Transaktionen versus UTXO-artige Notes, Merkle-Bäume, Nullifier und ZK-Beweise.
Ich frage mich immer noch: Erzeugt die stake-gewichtete Zuteilung von Credits Konzentrationsrisiken? Und wie robust ist der Emergency Mode bei Ausfällen von Validatoren?
#dusk $DUSK @Dusk
Was ich interessant fand, ist die Schwellenstruktur: „Valid“ braucht 2/3, während „Invalid“, „NoCandidate“ oder „NoQuorum“ eine Mehrheit von 1/2 + 1 erreichen können. Nach 16 fehlgeschlagenen Iterationen kann das Protokoll in den Emergency Mode wechseln, was die Frage aufwirft, wie es um Liveness im Verhältnis zum Fork-Risiko steht.
Auch das Anreizdesign hat meine Aufmerksamkeit erregt: 80 % gehen an den Block-Generator, 10 % an das Abstimmkomitee und 10 % an Dusk. Die 80 % des Generators setzen sich aus 70 % Fixanteil plus einem variablen Anteil von 10 % zusammen, der an die einbezogenen Stimmen gekoppelt ist. Gröbere Fehler wie doppeltes Abstimmen können ein hartes Slashing auslösen.
Dann haben Moonlight und Phoenix mir die Architektur klarer gemacht: öffentliche konto-basierte Transaktionen versus UTXO-artige Notes, Merkle-Bäume, Nullifier und ZK-Beweise.
Ich frage mich immer noch: Erzeugt die stake-gewichtete Zuteilung von Credits Konzentrationsrisiken? Und wie robust ist der Emergency Mode bei Ausfällen von Validatoren?
#dusk $DUSK @Dusk
