#dusk $DUSK @Dusk Dusk's Vertraulichkeits-Setup läuft tatsächlich auf zwei getrennten Spuren. Auf DuskDS stellt das Phoenix-Modell den Wert als Notizen dar, die in einen Merkle-Baum festgeschrieben sind – das Ausgeben einer Notiz verweist dabei nicht darauf, welche Notiz ausgegeben wird. Stattdessen veröffentlicht der Absender einen Nullifier und einen Zero-Knowledge-Beweis, der zeigt, dass die Ausgabe gültig ist, dass das Eigentum echt ist und dass kein Wert aus dem Nichts erzeugt wurde, ohne die zugrunde liegende Notiz offenzulegen. Daneben läuft Moonlight als transparentes, kontobasiertes Modell auf derselben Kette.
Auf DuskEVM hingegen kommt die Privatsphäre aus einem völlig anderen Werkzeugset – einem Modul namens Hedger, das ElGamal-basierte homomorphe Verschlüsselung mit Zero-Knowledge-Beweisen kombiniert, plus eine hybride UTXO-/Konto-Struktur. Hier interagiert ein Nutzer über eine standardmäßige EVM-Adresse mit den Contracts, während eine separate Hedger-Adresse die verschlüsselten Salden verwaltet, wobei die Einhaltung durch Allowlisting erzwungen wird.
Das sind nicht zwei Versionen derselben Idee. Phoenix ist ein notizbasiertes Beweissystem; Hedger rechnet direkt auf verschlüsselten Salden und wird über Zero-Knowledge-Beweise verifiziert. Der wahrscheinlichste Grund für die Aufspaltung ist, dass notizbasierte Privatsphäre sich nicht natürlich in eine kontobasierte EVM-Struktur einfügt, sodass dort ein anderer Ansatz nötig war.
Zwei unabhängige kryptografische Privatsphären-Stacks parallel zu betreiben bedeutet eine größere Angriffsfläche und einen höheren Audit-Aufwand. Außerdem ist nicht klar, wie die Zusicherung der Privatsphäre erhalten bleibt, wenn der Wert zwischen den beiden Ebenen wechselt.
Erhöht die Pflege zweier getrennten Vertraulichkeits-Engines den Audit-Aufwand proportional, oder bedeutet die gemeinsame Abhängigkeit von Zero-Knowledge-Beweisen, dass die zusätzlichen Kosten der zweiten Engine tatsächlich geringer sind, als es auf den ersten Blick wirkt?
Auf DuskEVM hingegen kommt die Privatsphäre aus einem völlig anderen Werkzeugset – einem Modul namens Hedger, das ElGamal-basierte homomorphe Verschlüsselung mit Zero-Knowledge-Beweisen kombiniert, plus eine hybride UTXO-/Konto-Struktur. Hier interagiert ein Nutzer über eine standardmäßige EVM-Adresse mit den Contracts, während eine separate Hedger-Adresse die verschlüsselten Salden verwaltet, wobei die Einhaltung durch Allowlisting erzwungen wird.
Das sind nicht zwei Versionen derselben Idee. Phoenix ist ein notizbasiertes Beweissystem; Hedger rechnet direkt auf verschlüsselten Salden und wird über Zero-Knowledge-Beweise verifiziert. Der wahrscheinlichste Grund für die Aufspaltung ist, dass notizbasierte Privatsphäre sich nicht natürlich in eine kontobasierte EVM-Struktur einfügt, sodass dort ein anderer Ansatz nötig war.
Zwei unabhängige kryptografische Privatsphären-Stacks parallel zu betreiben bedeutet eine größere Angriffsfläche und einen höheren Audit-Aufwand. Außerdem ist nicht klar, wie die Zusicherung der Privatsphäre erhalten bleibt, wenn der Wert zwischen den beiden Ebenen wechselt.
Erhöht die Pflege zweier getrennten Vertraulichkeits-Engines den Audit-Aufwand proportional, oder bedeutet die gemeinsame Abhängigkeit von Zero-Knowledge-Beweisen, dass die zusätzlichen Kosten der zweiten Engine tatsächlich geringer sind, als es auf den ersten Blick wirkt?