Ich habe eine Stunde damit verbracht, Dusk’s PLONK-V3-Aktivierung in Block 3,590,904 nachzuverfolgen, dann wurde ich von einer einzigen Wallet-Sicherheitszeile weggerufen: Das Repository sagt, es sei noch kein externer Audit abgeschlossen.
Das macht Dusk-Kryptografie nicht schwach. Es bedeutet nur, dass ernsthaftes kryptografisches Talent die falsche Kennzahl als Oberfläche misst.
Ein Proof-Verifier kann fehlerhafte Punkte zurückweisen, die nicht zu den öffentlichen Inputs und den komprimierten Circuits passen, während die Transaktion des Nutzers dennoch von Erweiterungs-Code abhängt: Passwortableitung, JavaScript-Speicherberechtigungen, der Node-Endpunkt und die Signieraufforderung.
Die Extension verwendet PBKDF2 mit 900.000 Iterationen und AES-GCM-256, der native Pfad nutzt Stronghold plus Argon2. Unterschiedliche Pfade, unterschiedliche Vertrauensannahmen.
Also würde ich Verhalten messen: Wie viele unabhängige Builds erzeugen byte-identische Solidity-Verifier? Welcher fehlerhafte Proof verbraucht vor der Zurückweisung am meisten Gas? Legt die CLI die gleiche markierte Empfängerwarnung offen wie die Web Wallet? Und wurde der Signierpfad einer vergleichbaren Prüfung unterzogen wie PLONK?
Einige Asymmetrie ist normal. Browser-Wallets können die Zeroisierung von JavaScript-Speicher nicht garantieren, und eine einfachere Verifier-Bereitstellung hat einen Wert, auch wenn die Gaskosten nicht sinken.
Aber Dusk’ institutionelle Sicherheit wird durch die schwächste Komponente bestimmt, die von der Autorität getragen wird – nicht durch ihre eleganteste Mathematik. Ich beobachte, ob Audits den Transaktionspfad Ende-zu-Ende verfolgen.
#dusk $DUSK @Dusk
Das macht Dusk-Kryptografie nicht schwach. Es bedeutet nur, dass ernsthaftes kryptografisches Talent die falsche Kennzahl als Oberfläche misst.
Ein Proof-Verifier kann fehlerhafte Punkte zurückweisen, die nicht zu den öffentlichen Inputs und den komprimierten Circuits passen, während die Transaktion des Nutzers dennoch von Erweiterungs-Code abhängt: Passwortableitung, JavaScript-Speicherberechtigungen, der Node-Endpunkt und die Signieraufforderung.
Die Extension verwendet PBKDF2 mit 900.000 Iterationen und AES-GCM-256, der native Pfad nutzt Stronghold plus Argon2. Unterschiedliche Pfade, unterschiedliche Vertrauensannahmen.
Also würde ich Verhalten messen: Wie viele unabhängige Builds erzeugen byte-identische Solidity-Verifier? Welcher fehlerhafte Proof verbraucht vor der Zurückweisung am meisten Gas? Legt die CLI die gleiche markierte Empfängerwarnung offen wie die Web Wallet? Und wurde der Signierpfad einer vergleichbaren Prüfung unterzogen wie PLONK?
Einige Asymmetrie ist normal. Browser-Wallets können die Zeroisierung von JavaScript-Speicher nicht garantieren, und eine einfachere Verifier-Bereitstellung hat einen Wert, auch wenn die Gaskosten nicht sinken.
Aber Dusk’ institutionelle Sicherheit wird durch die schwächste Komponente bestimmt, die von der Autorität getragen wird – nicht durch ihre eleganteste Mathematik. Ich beobachte, ob Audits den Transaktionspfad Ende-zu-Ende verfolgen.
#dusk $DUSK @Dusk