#dusk $DUSK @Dusk
Ein vertraulicher Transaktionsbeweis von Dusk liegt bei etwa einem halben Kilobyte. Egal, ob die zugrunde liegende Berechnung eine einfache Übertragung ist oder eine Multi-Party-Settlement-Prüfung mit eingebauter Compliance-Logik. Gleiche Größe. Das ist die Schlagzahl – und genau solche Werte werden immer wieder genannt, ohne dass jemand fragt, was sie verschweigen.
Das Beweissystem dahinter, PLONK, ist ein zk-SNARK, ausgelegt für Beweise konstanter Größe und eine Verifikationszeit, die mit der Komplexität des Schaltkreises sublinear wächst. Es läuft über die BLS12-381- und JubJub-Kurven, wobei Kate-Commitments dafür sorgen, dass diese Commitments konstant groß bleiben. Der eigentliche Designgewinn liegt nicht in der Beweisgröße, sondern im Setup. Groth16 liefert zwar einen kleineren Beweis, etwa 128 Bytes, benötigt jedoch eine schaltkreis-spezifische Referenzzeichenfolge (Reference String), was die praktische Nutzbarkeit einschränkt, sobald man viele unterschiedliche Schaltkreistypen einsetzt. PLONK-Setup ist über Schaltkreise hinweg wiederverwendbar. Für eine Kette, die viele verschiedene Vorlagen für vertrauliche Verträge unterstützen will, ist genau dieser Trade-off entscheidender.
Der Teil, der sich nicht so elegant skalieren lässt, ist die Beweiszeit. Der ursprüngliche Plonk-Prover hat eine Zeitkomplexität, die mit der Größe des zu beweisenden Schaltkreises wächst. Verifizierer bleiben leicht, aber wer den Beweis erzeugt – Wallet, Node – eben nicht. Wenn XSC-Verträge mit mehr Settlement-Zweigen, Compliance-Checks und Multi-Party-Logik erweitert werden, wächst der Schaltkreis, und damit steigen auch die Beweiskosten. Irgendwann beginnen sich die wirtschaftlichen Aspekte zugunsten dedizierter Beweis-Infrastruktur statt lokaler Generierung zu verschieben – ein seltsamer Zustand für eine datenschutzorientierte Kette.
Das Fee-Design muss diese Verschiebung irgendwann berücksichtigen – unabhängig davon, wer am Ende die schwere Rechenarbeit übernimmt. Bleibt Dusk’s Architektur dezentral, sobald das Proving teuer genug wird, um es auszulagern?
Ein vertraulicher Transaktionsbeweis von Dusk liegt bei etwa einem halben Kilobyte. Egal, ob die zugrunde liegende Berechnung eine einfache Übertragung ist oder eine Multi-Party-Settlement-Prüfung mit eingebauter Compliance-Logik. Gleiche Größe. Das ist die Schlagzahl – und genau solche Werte werden immer wieder genannt, ohne dass jemand fragt, was sie verschweigen.
Das Beweissystem dahinter, PLONK, ist ein zk-SNARK, ausgelegt für Beweise konstanter Größe und eine Verifikationszeit, die mit der Komplexität des Schaltkreises sublinear wächst. Es läuft über die BLS12-381- und JubJub-Kurven, wobei Kate-Commitments dafür sorgen, dass diese Commitments konstant groß bleiben. Der eigentliche Designgewinn liegt nicht in der Beweisgröße, sondern im Setup. Groth16 liefert zwar einen kleineren Beweis, etwa 128 Bytes, benötigt jedoch eine schaltkreis-spezifische Referenzzeichenfolge (Reference String), was die praktische Nutzbarkeit einschränkt, sobald man viele unterschiedliche Schaltkreistypen einsetzt. PLONK-Setup ist über Schaltkreise hinweg wiederverwendbar. Für eine Kette, die viele verschiedene Vorlagen für vertrauliche Verträge unterstützen will, ist genau dieser Trade-off entscheidender.
Der Teil, der sich nicht so elegant skalieren lässt, ist die Beweiszeit. Der ursprüngliche Plonk-Prover hat eine Zeitkomplexität, die mit der Größe des zu beweisenden Schaltkreises wächst. Verifizierer bleiben leicht, aber wer den Beweis erzeugt – Wallet, Node – eben nicht. Wenn XSC-Verträge mit mehr Settlement-Zweigen, Compliance-Checks und Multi-Party-Logik erweitert werden, wächst der Schaltkreis, und damit steigen auch die Beweiskosten. Irgendwann beginnen sich die wirtschaftlichen Aspekte zugunsten dedizierter Beweis-Infrastruktur statt lokaler Generierung zu verschieben – ein seltsamer Zustand für eine datenschutzorientierte Kette.
Das Fee-Design muss diese Verschiebung irgendwann berücksichtigen – unabhängig davon, wer am Ende die schwere Rechenarbeit übernimmt. Bleibt Dusk’s Architektur dezentral, sobald das Proving teuer genug wird, um es auszulagern?
