Ich habe die Datenschutzarchitektur von @Dusk auseinandergebaut und dabei mehrere Probleme entdeckt, die von der Erzählung einer „konformen Datenschutz-L1“ überdeckt werden.
Erste Ebene: Zwei Spuren, zwei Kosten $DUSK – Das Hauptnetz läuft gleichzeitig Moonlight (transparent) und Phoenix (privacy). Moonlight bietet ein übliches EVM-Erlebnis; aber bei Phoenix muss jede einzelne Transaktion durch den Client zk-SNARK-Nachweise generieren. wallet-core unterstützt das Auslagern der Nachweise an externe Prover – dieses Design allein zeigt, dass lokale Geräte die Rechenlast hochfrequenter Schaltkreise nicht tragen können.
Zweite Ebene: KYC ist die vorgelagerte Hürde
Das Citadel-Lizenzmodell, das für RWA verwendet wird, verlangt erst die Erledigung von KYC. Das ist in Ordnung, aber dadurch wird der aktuelle Hauptnetzdurchsatz in den Bereich „institutionelle Kleinchargen, hochwerthafte Abwicklungen“ eingeschlossen. Die Stabilität, die du siehst, ist das Ergebnis von Low-Concurrency-Szenarien.
Dritte Ebene: Einschränkungen verzerren die Verifikation
Der Anteil von Phoenix-Transaktionen ist derzeit nicht hoch, entsprechend ist die Nachweislast begrenzt. In einer kontrollierten Umgebung bleibt das System stabil – das bedeutet aber nicht, dass nach einer breiten Retail-Großserien-Parallelisierung Client-Rechenleistung, Prover-Queue und Verifikator-Durchsatz weiterhin effizient bleiben. Das Hauptnetz kann beweisen, dass „Datenschutz funktioniert“, aber es kann nicht beweisen, dass „Datenschutz auch die Menge trägt“.
Vierte Ebene: Nutzer könnten im letzten Schritt hängen bleiben
Wenn Nutzer KYC durchlaufen, Vermögenswerte gesperrt haben und dann eine Phoenix-Transaktion starten, können unzureichende lokale Rechenleistung oder eine überfüllte Prover-Queue dazu führen, dass die entscheidende Aktion nicht rausgeht. DUSK will Retail-Privacy-DeFi anbinden – die Skalierung der Prover und das Feedback bei Fehlern dürfen nicht nur in technischen Updates vorkommen.
Meine Einschätzung
Ich werde weder die ZK-Kosten noch KYC mit #dusk verneinen – Privacy L1 und permissionless Public Chains sind schlicht zwei verschiedene Wege. Aber „Der Prozess kann laufen“ und „er kann die Menge tragen“ sind zwei verschiedene Dinge. Warte ab, bis der Phoenix-Anteil steigt, das Prover-Netzwerk reifer wird und die Optimierung komplexer Smart-Contract-Schaltkreise umgesetzt ist. Beobachte dann die Fehlerquote, die Nachweisdauer und die reibungslose Umsetzbarkeit beim Wechsel zwischen Modellen – erst dann weiß man, ob es sich um „Privacy, die läuft“ oder „Privacy, die die Menge trägt“ handelt.
Erste Ebene: Zwei Spuren, zwei Kosten $DUSK – Das Hauptnetz läuft gleichzeitig Moonlight (transparent) und Phoenix (privacy). Moonlight bietet ein übliches EVM-Erlebnis; aber bei Phoenix muss jede einzelne Transaktion durch den Client zk-SNARK-Nachweise generieren. wallet-core unterstützt das Auslagern der Nachweise an externe Prover – dieses Design allein zeigt, dass lokale Geräte die Rechenlast hochfrequenter Schaltkreise nicht tragen können.
Zweite Ebene: KYC ist die vorgelagerte Hürde
Das Citadel-Lizenzmodell, das für RWA verwendet wird, verlangt erst die Erledigung von KYC. Das ist in Ordnung, aber dadurch wird der aktuelle Hauptnetzdurchsatz in den Bereich „institutionelle Kleinchargen, hochwerthafte Abwicklungen“ eingeschlossen. Die Stabilität, die du siehst, ist das Ergebnis von Low-Concurrency-Szenarien.
Dritte Ebene: Einschränkungen verzerren die Verifikation
Der Anteil von Phoenix-Transaktionen ist derzeit nicht hoch, entsprechend ist die Nachweislast begrenzt. In einer kontrollierten Umgebung bleibt das System stabil – das bedeutet aber nicht, dass nach einer breiten Retail-Großserien-Parallelisierung Client-Rechenleistung, Prover-Queue und Verifikator-Durchsatz weiterhin effizient bleiben. Das Hauptnetz kann beweisen, dass „Datenschutz funktioniert“, aber es kann nicht beweisen, dass „Datenschutz auch die Menge trägt“.
Vierte Ebene: Nutzer könnten im letzten Schritt hängen bleiben
Wenn Nutzer KYC durchlaufen, Vermögenswerte gesperrt haben und dann eine Phoenix-Transaktion starten, können unzureichende lokale Rechenleistung oder eine überfüllte Prover-Queue dazu führen, dass die entscheidende Aktion nicht rausgeht. DUSK will Retail-Privacy-DeFi anbinden – die Skalierung der Prover und das Feedback bei Fehlern dürfen nicht nur in technischen Updates vorkommen.
Meine Einschätzung
Ich werde weder die ZK-Kosten noch KYC mit #dusk verneinen – Privacy L1 und permissionless Public Chains sind schlicht zwei verschiedene Wege. Aber „Der Prozess kann laufen“ und „er kann die Menge tragen“ sind zwei verschiedene Dinge. Warte ab, bis der Phoenix-Anteil steigt, das Prover-Netzwerk reifer wird und die Optimierung komplexer Smart-Contract-Schaltkreise umgesetzt ist. Beobachte dann die Fehlerquote, die Nachweisdauer und die reibungslose Umsetzbarkeit beim Wechsel zwischen Modellen – erst dann weiß man, ob es sich um „Privacy, die läuft“ oder „Privacy, die die Menge trägt“ handelt.