Letzte Nacht habe ich die Dusk-Dokumentation erneut aufgerufen und mich darauf konzentriert, die tatsächliche Rolle $DUSK innerhalb des Protokolls zu verstehen – seine technische Funktion, nicht die marktgetriebene Story.
Das Erste, was ich entwirren musste, waren DuskDS’ zwei Transaktionsmodelle. Moonlight ist der vertraute Weg: öffentliche Konten, sichtbare Salden, Absender, Empfänger, Betrag. Phoenix arbeitet mit verschlüsselten „Notizen“. Um eine davon auszugeben, liefert der Nutzer einen Zero-Knowledge-Beweis, dass Besitz- und Saldenregeln eingehalten werden. Stell dir vor, du gibst einem Sachbearbeiter einen versiegelten Umschlag, dessen Siegel beweist, dass alle erforderlichen Kästchen abgehakt sind, ohne den Inhalt offenzulegen. Ein Nullifier ermöglicht es dem Netzwerk dann, einen zweiten Spend abzuweisen, ohne zu identifizieren, welche Notiz aus dem öffentlichen Baum verwendet wurde. Ich habe diesen Abschnitt zweimal gelesen – dann riss mich eine Benachrichtigung weg –, denn Privatsphäre bedeutet nicht „es wird nichts geprüft“. Sie bedeutet, dass das Netzwerk einen Beweis prüft statt die versteckten Transaktionsdetails. Viewing Keys können Informationen selektiv offenlegen.
Beim Konsens gab es einen weiteren Durchlauf. Dusk nennt ihn Succinct Attestation: Staker, also Provisioners, sperren DUSK; eine deterministische, stake-gewichtete Auswahl wählt einen Block-Producer, dann validiert ein Komitee und ein anderes ratifiziert. Aggregierte Signaturen werden zu einer Attestation, dass ein Quorum zugestimmt hat. So ist $DUSK sowohl Gas als auch der Stake hinter der Teilnahme.
Den nächsten Teil, den ich mir ansehen würde, ist Konzentration. Die Auswahl ist permissionless, aber wie verteilt sind die effektiven Komitee-Credits in der Praxis? In den Seiten, die ich gelesen habe, konnte ich kein klares Bild finden, wer globale Parameter ändert. vielleicht habe ich es übersehen.
Welche Belege würden zeigen, dass die Komitee-Macht wirklich dezentral verteilt ist? Wie werden Viewing Keys in realen Deployments gesteuert? Wer kann Protokollparameter ändern, und durch welchen Prozess?
#dusk $DUSK @Dusk
Das Erste, was ich entwirren musste, waren DuskDS’ zwei Transaktionsmodelle. Moonlight ist der vertraute Weg: öffentliche Konten, sichtbare Salden, Absender, Empfänger, Betrag. Phoenix arbeitet mit verschlüsselten „Notizen“. Um eine davon auszugeben, liefert der Nutzer einen Zero-Knowledge-Beweis, dass Besitz- und Saldenregeln eingehalten werden. Stell dir vor, du gibst einem Sachbearbeiter einen versiegelten Umschlag, dessen Siegel beweist, dass alle erforderlichen Kästchen abgehakt sind, ohne den Inhalt offenzulegen. Ein Nullifier ermöglicht es dem Netzwerk dann, einen zweiten Spend abzuweisen, ohne zu identifizieren, welche Notiz aus dem öffentlichen Baum verwendet wurde. Ich habe diesen Abschnitt zweimal gelesen – dann riss mich eine Benachrichtigung weg –, denn Privatsphäre bedeutet nicht „es wird nichts geprüft“. Sie bedeutet, dass das Netzwerk einen Beweis prüft statt die versteckten Transaktionsdetails. Viewing Keys können Informationen selektiv offenlegen.
Beim Konsens gab es einen weiteren Durchlauf. Dusk nennt ihn Succinct Attestation: Staker, also Provisioners, sperren DUSK; eine deterministische, stake-gewichtete Auswahl wählt einen Block-Producer, dann validiert ein Komitee und ein anderes ratifiziert. Aggregierte Signaturen werden zu einer Attestation, dass ein Quorum zugestimmt hat. So ist $DUSK sowohl Gas als auch der Stake hinter der Teilnahme.
Den nächsten Teil, den ich mir ansehen würde, ist Konzentration. Die Auswahl ist permissionless, aber wie verteilt sind die effektiven Komitee-Credits in der Praxis? In den Seiten, die ich gelesen habe, konnte ich kein klares Bild finden, wer globale Parameter ändert. vielleicht habe ich es übersehen.
Welche Belege würden zeigen, dass die Komitee-Macht wirklich dezentral verteilt ist? Wie werden Viewing Keys in realen Deployments gesteuert? Wer kann Protokollparameter ändern, und durch welchen Prozess?
#dusk $DUSK @Dusk
