#dusk $DUSK Übersetze die Dusk-Technologiedokumente, wobei ich besonders auf den Generierungs- und Verifizierungsprozess der Zero-Knowledge-Proofs (ZKP) im Phoenix-Protokoll geachtet habe. Das Whitepaper beschreibt Plonk sehr vollständig, aber das, was mich wirklich zum Innehalten brachte, war: In dem Dokument werden kaum zeitliche Benchmarks für die Proof-Generierung im Mainnet-Umfeld angegeben.
Genau das ist der entscheidende Engpass für die Umsetzung datenschutzfreundlicher Transaktionen. Phoenix stellt Gelder als verschlüsselte Notes dar, und bei jeder Überweisung muss lokal ein Proof erzeugt werden – der Absender ist berechtigt, die Note zu verbrauchen, der Betrag ist nicht negativ, Eingaben und Ausgaben sind ausgeglichen und es gibt keinen Double-Spend. Dieser Proof-Generierungsprozess findet auf dem Gerät des Nutzers statt, ist nicht vom Netzwerk abhängig, benötigt aber Rechenressourcen.
Die Frage lautet: Wenn das Generieren eines Proofs für eine Shielded-Transaktion auf dem Smartphone 30 Sekunden oder länger dauert, dann kann eine datenschutzorientierte Überweisung nicht Teil eines alltäglichen Zahlungserlebnisses sein. Wenn die Proof-Generierung zudem viel Arbeitsspeicher benötigt, können Geräte mit schwacher Ausstattung sie direkt nicht verwenden. Noch schwieriger ist, dass Dusk Phoenix und Moonlight zwei unterschiedliche Modelle sind: Wenn Nutzer von shielded zurück zu public wechseln, müssen sie ebenfalls einen Proof erzeugen.
Ich habe mir das Dusk-GitHub-Repository und die Community-Diskussionen angesehen. Die meisten der verfügbaren Leistungsdaten stammen aus Testumgebungen oder von spezifischer Hardware. Ich habe keinen Benchmark-Bericht für Mobile, für den Browser-Client oder für ein normales Notebook gefunden. Und Optimierungen für die ZKP-Proof-Generierung – von der Wahl des Algorithmus über das Circuit-Design bis hin zur Hardwarebeschleunigung – können in jedem Schritt die Latenz von Sekunden auf Millisekunden drücken, aber auch umgekehrt ausufern, wenn die Komplexität explodiert.
Ein weiteres leicht übersehenes Thema sind die Verifizierungskosten. Selbst wenn die Proof-Generierung auf der Nutzerseite erfolgt, verbraucht die On-Chain-Verifizierung weiterhin Gas. Wenn die Verifizierungskosten linear mit der Transaktionskomplexität ansteigen, kann eine Privacy-Transaktion bei hoher Auslastung ein Vielfaches teurer sein als eine öffentliche. Das ist im Grunde so, als würde man Nutzer mit dem Preis zurück zu Moonlight drängen.@Dusk
Darum bewerte ich die praktische Datenschutz-Tauglichkeit von Dusk nicht danach, welches Beweissystem es unterstützt, sondern danach, wie hoch die Proof-Generierungsverzögerung auf normaler Hardware ist, wie sich der Gasverbrauch für die On-Chain-Verifizierung entwickelt und ob der Anteil der Phoenix-Transaktionen am Gesamtsystem sich auf natürliche Weise weiter erhöht. Die Mathematik im Whitepaper ist der Startpunkt, die Stoppuhr auf dem Gerät ist das Ziel. $DUSK