Ich begann, die Gate-Count-Erzählung von DUSK zu hinterfragen, als ein modellierter 8-Bit-XOR von 31 Gates auf eine einzelne PlonKup-Lookup-Operation fiel. Die Kompression sieht mit 96,8% beeindruckend aus. Aber das spiegelt Circuit-Arithmetik wider, nicht die tatsächliche Proof-Geschwindigkeit.
Ein Lookup bringt dennoch Tabellenbehandlung, Commitments-Sortierung und Memory-Pressure mit sich. Also bedeuten 31× weniger Gates nicht automatisch 31× schnelleres Proving. Die Kosten können sich schlicht in den RAM verlagern.
Das ist entscheidend, weil DUSK’ Operator-Guidance-Budgets etwa 1 GB pro Proof-Worker und 8 GB für einen Mindest-Server vorsieht. Das sind Größenordnungswerte, nicht gemessene Spitzen-RAM-Verbräuche. Die fehlende Kennzahl ist Proofs pro GB bei Last im P50- und P99-Szenario – insbesondere mit gleichzeitigen Workern.
Dann kommt die Zugänglichkeit. Was passiert auf einem Mittelklasse-Telefon nach Hitze, im Hintergrund laufenden Apps und wiederholten Proofs? Wenn P50 akzeptabel ist, aber P99 ins Stocken gerät, wird Privatsphäre zu Nutzerreibung – nicht nur zu einem kryptografischen Gewinn.
Ich beobachte außerdem fehlerhafte Proofs. Wie viel CPU kann eine ungültige Eingabe verbrauchen, bevor abgelehnt wird, und wie viel spart frühes Filtern? Ein gewisser Overhead ist normal. Unbegrenzte Verstärkung ist es nicht.
DUSK kann erfolgreich sein, wenn die Lookup-Kompression den echten Durchsatz verbessert, ohne das Proving stark auf High-Memory-Hardware zu konzentrieren. Solange DUSK keine Proof-Time-Peaks, RAM-Energieverbrauch und Benchmarks zum Ablehnen ungültiger Proofs veröffentlicht, bleibt es unvollständig.
#dusk $DUSK @Dusk
Ein Lookup bringt dennoch Tabellenbehandlung, Commitments-Sortierung und Memory-Pressure mit sich. Also bedeuten 31× weniger Gates nicht automatisch 31× schnelleres Proving. Die Kosten können sich schlicht in den RAM verlagern.
Das ist entscheidend, weil DUSK’ Operator-Guidance-Budgets etwa 1 GB pro Proof-Worker und 8 GB für einen Mindest-Server vorsieht. Das sind Größenordnungswerte, nicht gemessene Spitzen-RAM-Verbräuche. Die fehlende Kennzahl ist Proofs pro GB bei Last im P50- und P99-Szenario – insbesondere mit gleichzeitigen Workern.
Dann kommt die Zugänglichkeit. Was passiert auf einem Mittelklasse-Telefon nach Hitze, im Hintergrund laufenden Apps und wiederholten Proofs? Wenn P50 akzeptabel ist, aber P99 ins Stocken gerät, wird Privatsphäre zu Nutzerreibung – nicht nur zu einem kryptografischen Gewinn.
Ich beobachte außerdem fehlerhafte Proofs. Wie viel CPU kann eine ungültige Eingabe verbrauchen, bevor abgelehnt wird, und wie viel spart frühes Filtern? Ein gewisser Overhead ist normal. Unbegrenzte Verstärkung ist es nicht.
DUSK kann erfolgreich sein, wenn die Lookup-Kompression den echten Durchsatz verbessert, ohne das Proving stark auf High-Memory-Hardware zu konzentrieren. Solange DUSK keine Proof-Time-Peaks, RAM-Energieverbrauch und Benchmarks zum Ablehnen ungültiger Proofs veröffentlicht, bleibt es unvollständig.
#dusk $DUSK @Dusk