Ich habe in die jüngste Entwicklung von Dusk eingetaucht, und eine Sache beschäftigt mich – auf eine gute Weise: die @PLONK -Performance-Arbeit.
Ein Rückgang der Proofing-Zeit um 58 % ist beeindruckend, aber nicht die Zahl hat mich am meisten gepackt.
Sondern wie sie dorthin gekommen sind.
Das Caching deterministischer Prover-/Verifier-Daten, das Batching von Inversionen und MSM-Terms, die Parallelisierung unabhängiger FFT-Arbeiten und das Reduzieren wiederholter Allokationen haben den Durchsatz beim Proving auf ungefähr das 2,4-Fache gehoben.
Die Verifikation wurde um 44 % verbessert, während die Circuit-Compilation 25 % schneller wurde.
Aber der wichtige Teil ist, was unangetastet blieb.
Die zugrunde liegende Mathematik, das Transcript und das Proof-Format haben sich nicht geändert.
Das fühlt sich also weniger nach „besserer Kryptografie“ an und mehr nach dem Entfernen verschwendeter Arbeit aus einer Kryptografie, die bereits funktioniert.
Dann habe ich mir die Tests von DuskEM × DuskDS angesehen und ein ähnliches Muster entdeckt. Unterschiedliche Ausführungs- und State-Modelle werden unter gemischten Workloads getestet.
Das ist wichtig, weil Systeme selten schwierig werden, wenn jede Komponente für sich allein läuft. Die Reibung zeigt sich normalerweise erst, wenn sie zusammen funktionieren müssen.
Und vielleicht ist das der Teil, der mir bei Privacy-Netzwerken jetzt am meisten wichtig zu werden beginnt.
Starke Kryptografie kann Privatsphäre schaffen.
Aber wenn das Proving langsam ist, die Verifikation teuer wird oder die Ausführung unvorhersehbar wird, spüren die Nutzer weiterhin die Komplexität.
Ich könnte mich irren, aber vielleicht besteht Dusk’ eigentliche Herausforderung nicht darin zu beweisen, dass Privatsphäre funktioniert.
Sondern darin, die Mechanik hinter der Privatsphäre schnell genug zu machen, dass sich niemand darum kümmern muss.

#dusk @Dusk $DUSK