#dusk $DUSK @Dusk Du gehst in ein Krankenhaus der höchsten Versorgungsstufe, um einen Gentest machen zu lassen. Geräte und Reagenzien sind in Ordnung – aber die Krankenschwester klebt die Etiketten am Probenmaterial falsch. Du bekommst den Bericht einer anderen Person, und die Daten fließen in die Akte eines Fremden. Der Prozess ist makellos; das eigentliche Objekt ist bereits im ersten Schritt falsch.
Die Zero-Knowledge-Proof-Pipeline von Dusk Network durchlebt gerade dasselbe Fehl-Alignment.
Der Privacy-Trade von <a>DuskNetwork</a> wird von dusk-plonk an der Tür gehalten. Aber nachdem man für den range proof benutzerdefinierte widgets eingeführt hat, beginnt der Prover, vier selector evaluations an den Verifier zu übermitteln. Der Verifier setzt sie in die finale Gleichung ein, bindet jedoch keinen opening proof an die Verpflichtung auf die verifier key ein – eine grundlegende Invariante wird gebrochen: Jede Skalare, die in die Verifikationsgleichung gelangt, wird entweder lokal berechnet oder kryptografisch verriegelt. Beides trifft nicht zu.
Osec.io hat zuvor eine Angriffskette konstruiert: Auf einem lokalen Rusk-Node fälscht der Angreifer mit einer Wallet mit Null-Balance eine Phoenix-Transaktion, erfindet einen 2000 DUSK Input note, feinjustiert die selector-Scalar so, dass das Pairing durchgeht. Die Node verifiziert erfolgreich, die Transaktion wird in den Block aufgenommen und anschließend überweist sie 1337 DUSK an eine ehrliche Wallet und wird bestätigt – der gesamte Kontostand kommt aus der Luft.
Das ist nicht einfach ein falsch geschriebenes Circuit-Constraint. Die Circuit-Logik wurde von Kryptografen auditierend als korrekt bestätigt. Das ist das Zusammenbrechen der Vertrauensgrenze auf Architektur-Ebene: Vier selector evaluations sind wie unlabeled Proben – direkt in das „korrekte“ Detektionsverfahren eingespeist.
Das Dusk-Team behebt es innerhalb von 24 Stunden. Aber die tieferliegende Spannung ist nicht verschwunden. Im Standard-PLONK sind selectors feste Parameter auf der Verifier-Seite; sobald benutzerdefinierte widgets den Prover zwingen, sie bereitzustellen, betritt man das im Paper nicht spezifizierte Gebiet. Mehrere Audits im Dezember 2023 und im September 2024 haben es nicht entdeckt – denn in den mentalen Modellen der Reviewer ist „selectors gehören zum Verifier“ eine so selbstverständlich angenommene Axiomatik. Die Abweichung steckt im Schatten der Axiome.
Dusk ersetzt benutzerdefinierte widgets gegen Effizienz bei Privacy-Berechnungen – aber jede Erweiterung fügt der Sicherheitsargumentationskette wieder einen nicht verifizierten Schritt hinzu. Zwischen dem mentalen Modell der Auditoren und dem innovativen Angriffspfad der Angreifer existiert stets ein Zeitversatz. Das ist kein Technikproblem, sondern ein Erkenntnisproblem.
Technik kann die Implementierung reparieren; Technik kann die architektonische Spannung nicht reparieren. In der Welt der Zero Knowledge sind Privacy das Versprechen, Soundness die Einlösung. Ein Versprechen, das man nicht einlösen kann, ist nur eine kryptografisch verpackte Fantasie. DYOR.
#dusk DUSK
Die Zero-Knowledge-Proof-Pipeline von Dusk Network durchlebt gerade dasselbe Fehl-Alignment.
Der Privacy-Trade von <a>DuskNetwork</a> wird von dusk-plonk an der Tür gehalten. Aber nachdem man für den range proof benutzerdefinierte widgets eingeführt hat, beginnt der Prover, vier selector evaluations an den Verifier zu übermitteln. Der Verifier setzt sie in die finale Gleichung ein, bindet jedoch keinen opening proof an die Verpflichtung auf die verifier key ein – eine grundlegende Invariante wird gebrochen: Jede Skalare, die in die Verifikationsgleichung gelangt, wird entweder lokal berechnet oder kryptografisch verriegelt. Beides trifft nicht zu.
Osec.io hat zuvor eine Angriffskette konstruiert: Auf einem lokalen Rusk-Node fälscht der Angreifer mit einer Wallet mit Null-Balance eine Phoenix-Transaktion, erfindet einen 2000 DUSK Input note, feinjustiert die selector-Scalar so, dass das Pairing durchgeht. Die Node verifiziert erfolgreich, die Transaktion wird in den Block aufgenommen und anschließend überweist sie 1337 DUSK an eine ehrliche Wallet und wird bestätigt – der gesamte Kontostand kommt aus der Luft.
Das ist nicht einfach ein falsch geschriebenes Circuit-Constraint. Die Circuit-Logik wurde von Kryptografen auditierend als korrekt bestätigt. Das ist das Zusammenbrechen der Vertrauensgrenze auf Architektur-Ebene: Vier selector evaluations sind wie unlabeled Proben – direkt in das „korrekte“ Detektionsverfahren eingespeist.
Das Dusk-Team behebt es innerhalb von 24 Stunden. Aber die tieferliegende Spannung ist nicht verschwunden. Im Standard-PLONK sind selectors feste Parameter auf der Verifier-Seite; sobald benutzerdefinierte widgets den Prover zwingen, sie bereitzustellen, betritt man das im Paper nicht spezifizierte Gebiet. Mehrere Audits im Dezember 2023 und im September 2024 haben es nicht entdeckt – denn in den mentalen Modellen der Reviewer ist „selectors gehören zum Verifier“ eine so selbstverständlich angenommene Axiomatik. Die Abweichung steckt im Schatten der Axiome.
Dusk ersetzt benutzerdefinierte widgets gegen Effizienz bei Privacy-Berechnungen – aber jede Erweiterung fügt der Sicherheitsargumentationskette wieder einen nicht verifizierten Schritt hinzu. Zwischen dem mentalen Modell der Auditoren und dem innovativen Angriffspfad der Angreifer existiert stets ein Zeitversatz. Das ist kein Technikproblem, sondern ein Erkenntnisproblem.
Technik kann die Implementierung reparieren; Technik kann die architektonische Spannung nicht reparieren. In der Welt der Zero Knowledge sind Privacy das Versprechen, Soundness die Einlösung. Ein Versprechen, das man nicht einlösen kann, ist nur eine kryptografisch verpackte Fantasie. DYOR.
#dusk DUSK