#dusk $DUSK In den letzten zwei Tagen habe ich die Sicherheitsroute für @Dusk neu durchdacht. Mir ist klar geworden, dass es nicht wirklich darum geht, ob bei dem Projekt schon Probleme aufgetreten sind, sondern darum, wie es die Sicherheit der Protokolle, die Anwendungssicherheit und die Sicherheit der Asset-Treuhand/Verwahrung aufteilt. Viele sehen einen Zwischenketten-Bridge-Unfall und ihre erste Reaktion ist, alle Risiken dem Mainnet zuzuschreiben. Andere hören, dass der Konsens nicht durchbrochen wurde, und schließen daraus, dass das Ereignis nichts mit Dusk zu tun hat. Beide Einschätzungen sind zu simpel. Für Nutzer gilt: Sobald an einer Stelle ein Schwachpunkt in der Asset-Einlassstelle, im Signaturdienst oder am Cross-Chain-Ausgang auftritt, ist der wirtschaftliche Schaden real vorhanden – und kann nicht einfach ignoriert werden, nur weil das zugrunde liegende Protokoll normal läuft.
Was Dusk derzeit bewältigen muss, ist ein mehrschichtiges System: Der Konsens ist für den Netzwerkstatus zuständig, die virtuelle Maschine führt die Logik aus, Phoenix verarbeitet datenschutzrelevante/transaktionsbezogene Privatsphäre, und Bridge sowie Wallet sind für den externen Transfer von Assets verantwortlich. Wenn an irgendeiner Schicht die Randbedingungen falsch sind, kann das die gesamte Netzwerksicherheit bzw. das Vertrauen der Nutzer in das System beeinträchtigen. Daher ist die Behebung einer bestimmten Schwachstelle nur der erste Schritt. Noch wichtiger ist es, zu prüfen, ob ähnliche Probleme des gleichen Typs in anderen Komponenten existieren und ob die reparierte Version auch Knoten, Wallets und die zugehörigen Dienste abdeckt.
Ich interessiere mich besonders dafür, ob das Team künftig die interne Prüfung als dauerhaftes Mechanismus etablieren wird – statt erst kurz vor der Veröffentlichung einer großen Version alles gebündelt zu prüfen. Zero-Knowledge-Beweise, Signaturvalidierung und Deserialisierung gehören zu den tieferliegenden Bereichen, die gewöhnliche Nutzer kaum bemerken. Auch ein einzelnes Update, das neuen Code einführt, kann alte Risiken wieder öffnen. Externe Audits liefern zwar eine unabhängige Perspektive, können aber keine laufende Überwachung, Quoten-/Limitmechanismen und Notfall-Stopps ersetzen.$SPCXB
Daher kann man die Sicherheit von DUSK nicht nur an der Anzahl der Audits festmachen, und auch nicht nur an einer einmaligen Bekanntmachung nach einem Vorfall. Aussagekräftiger sind Kennzahlen wie die Geschwindigkeit der Schwachstellenbehebung, der Anteil der aufgerüsteten Nodes, die Limits für Hot Wallets, die Aufteilung von Schlüsselberechtigungen und die Ergebnisse der nachgelagerten erneuten Überprüfungen. Sicherheit bedeutet nicht, dass es nie zu Fehlern kommt, sondern dass sich Fehler schwer vergrößern lassen und dass sie schnell erkannt und kontrolliert werden können.#dusk @Dusk $SNDKB