#dusk $DUSK @Dusk
Nimmt man „Phoenix“ und „Moonlight“ nur rein danach auseinander, welches davon „privater“ ist, könnte man die falsche Frage stellen – denn zwei Modell(e) sind gar keine zwei Antworten auf dieselbe Fragestellung. Es sind unterschiedliche Werkzeuge für zwei komplett verschiedene Workflows. „Wie stark die Privatsphäre ist“ ist dabei nicht wirklich der entscheidende Maßstab.

Zuerst zur Einordnung: Viele, die „Privacy-Public-Chain“ hören, denken sofort an Zcash oder Monero. Aber dort geht es primär um anonyme persönliche Überweisungen. Dusk zielt dagegen auf Smart Contracts im Finanzbereich und auf geschäftliche/ institutionelle Workflows. Auf Privatsphäre kommt zudem noch eine Compliance- und Audit-Fähigkeit als zusätzliche Ebene – das ist eine völlig andere Größenordnung.

Die zugrunde liegende Abrechnung erfolgt über Succinct Attestation (SA). Im Whitepaper steht in Section 3 sehr konkret: Ein Governance-/Komiteesystem- PoS-Protokoll. Geheldet wird DUSK, und ein Provisioner (der DUSK Provisioner) ist für das Block-Voting zuständig. Die Auswahl des Komitees erfolgt über deterministische Zufallsauswahl (Section 3.5). Dafür muss nicht jeder Verifizierer ausdrücklich seinen Standpunkt abgeben – so lässt sich eine schnelle, deterministische Abrechnung erreichen.

Wirklich genauer hinschauen sollte man auf die jeweiligen Kosten von Moonlight und Phoenix. Moonlight ist ein transparentes Kontomodell: Konto-/Betragsüberweisungen sind öffentlich nachvollziehbar (Whitepaper Section 4.1). Es ist einfach in der Bedienung und die Abstimmung ist direkt – der Preis dafür ist: keine Privatsphäre. Phoenix basiert auf ZK-proof (Section 4.2). Vor jeder einzelnen Überweisung muss zuerst eine entsprechende Beweisrechnung erstellt werden; allein das Generieren dieses Beweises kostet Rechenressourcen. Wenn man diese Last nicht selbst tragen möchte, sieht das Whitepaper einen Ansatz vor: Die beiden Aufgaben „welche Transaktionen an einen selbst adressiert sind, scannen“ und „diesen Beweis erzeugen“ werden jeweils an vertrauenswürdige Dritte ausgelagert. Das ist im Vergleich zu Moonlight – wo man direkt über Signaturprüfung auskommt und keinen zusätzlichen Beweisschritt braucht – tatsächlich nicht dieselbe Größenordnung. Welche Modellvariante man wählt, bedeutet im Kern: „Muss man diese Komplexitätskosten tragen?“ und nicht einfach „Welches ist privater?“

Zum Entwickler-Ökosystem: DuskEVM ist kompatibel mit OP-Stack und Solidity, sodass bestehende Ethereum-Verträge direkt migriert werden können. Hedger ergänzt für die EVM-Umgebung vertrauliche-Transaktions-Flows. Nativ unterstützt DuskVM das Schreiben von vertraulichen Smart Contracts mit Rust/WASM – passend zum markenbasierten Dusk-Standard Confidential Security Contract (XSC). Entwickler können also ganz normale öffentliche dApps erstellen, und gleichzeitig auf derselben Kette auch institutionelle Anwendungen aufbauen, die Vertraulichkeit benötigen.

Was meint ihr: Lohnt es sich, Phoenix – also das komplexere, aber privatere Modell – zu wählen und die zusätzlichen Kosten dafür zu zahlen?