$DUSK #dusk @Dusk

Ich habe mich mit der Aufgabe befasst, durch die Kryptografie von Dusk zu graben – Argon2, Equihash, PLONK, die ganze ernsthafte Mathe-Seite des Stacks.

Dann habe ich mir angesehen, was tatsächlich in letzter Zeit zum Sicherheitsproblem wurde.

Es war nicht die Kryptografie.

Es war ein operatives Wallet.

Am 16. August hat Dusk seine Bridge-Dienste pausiert, nachdem überwachte Aktivitäten erkannt wurden, die nicht zu normalen Bridge-Operationen passten. DuskDS selbst erzeugte weiterhin Blöcke, und die darauf folgende Maßnahme war kein neues Beweissystem oder ein Konsens-Change.

Es war viel simpler: eine Empfänger-Blockliste in der Web Wallet, die Nutzer warnt, bevor sie an als auffällig markierte Adressen senden.

Dieser Kontrast ist mir geblieben.

Dusk kann darunter ausgefeilte Kryptografie haben, während die unmittelbarste nutzerseitige Abwehr in der Wallet-Schicht sitzt.

Und das schafft eine interessante Grenze.

Wenn du die Web Wallet nutzt, bekommst du diese Warnung.

Wenn du über dein eigenes Tooling oder direkt über das Protokoll interagierst, bekommst du sie möglicherweise nicht.

Also ist das Sicherheitsmodell nicht nur eine Frage davon, wie stark die zugrunde liegende Kryptografie ist.

Es geht auch darum, wo der Schutz tatsächlich verankert ist – und wer ihn standardmäßig übernimmt.

Ich kann nachvollziehen, warum eine Wallet-seitige Kontrolle die schnellste praktische Reaktion ist.

Aber für ein Netzwerk, das regulierte Finanzen adressiert, komme ich immer wieder zu einer Frage:

Wie viel Sicherheit sollte im Protokoll leben, und wie viel kann sicher in der Oberfläche leben?

$PORTAL
$PROM

Wo sollen Dusk’s Sicherheitskontrollen leben? 👀