Ich dachte immer, dass ein Verifikator-Schlüssel nur einen Job hat: zu beweisen, dass ein Knoten berechtigt ist, an dem Konsens teilzunehmen. Bis ich mir die Node-Setup-Dokumentation von Dusk angesehen habe – diese Annahme wurde widerlegt.
Ein Dusk-Deposit kann zwei völlig unabhängige Rollen umfassen. Der Konsensschlüssel bleibt auf dem Knoten und ist für das Abstimmen und das Signieren von Blöcken zuständig; der Eigentümerschlüssel hingegen kontrolliert die Rechte zum Entstaken und zum Auszahlen.
Klingt nach einer kleinen Einzelheit, oder? Aber wenn man genauer darüber nachdenkt, löst dieses Design ein Problem, das von den meisten Projekten ignoriert wird: Was passiert, wenn der Knoten gehackt wird? @Dusk
Die meisten PoS-Ketten-Validatoren haben nur ein einziges Schlüsselpaar – wenn es verloren geht, übergibt man damit gleichzeitig die Kontrolle über den Knoten und die gestakten Vermögenswerte. Der Angreifer kann nicht nur den Konsens stören, sondern auch direkt Ihre Coins abziehen. Dusk trennt diese beiden Dinge. Selbst wenn der Online-Knoten kompromittiert wird, kann der Angreifer höchstens den Konsens beeinflussen – und kann Ihre gestakten Vermögenswerte nicht anfassen.
Natürlich ist der Preis dafür eine komplexere operative Verantwortung. Dusk empfiehlt offiziell, aus demselben Seed eine weitere Adresse als Eigentümer festzulegen, während der Konsensschlüssel weiterhin vom Knoten verwendet wird. Aber wenn der Seed noch auf dem Server liegt, ist diese Trennung nicht vollständig. Das wirklich wirksame Muster ist, dass der Seed überhaupt nicht auf dem Knoten gespeichert ist – oder dass die Brieftasche ein starkes Passwort verwendet, das sich vom Passwort des Konsensschlüssels unterscheidet.
Das bringt mich zu einer grundsätzlicheren Frage: Viele Projekte halten ihr Sicherheitsdesign auf Schutz gegen externe Angriffe ausgerichtet, aber Dusk schützt bereits gegen interne Single Points of Failure. Der Konsensschlüssel kann online exponiert sein, während der Eigentümerschlüssel offline geschützt werden muss. Diese beiden Rollen zu trennen ist im Grunde eine Anerkennung einer Realität: Der Server wird auf jeden Fall ins Visier genommen – es ist nur eine Frage der Zeit.
Ich sage nicht, dass Dusk’ Sicherheitsdesign perfekt ist. Die Trennung der Schlüssel begrenzt zwar die Auswirkungen eines einzelnen Eindringens, der Verlust von Offline-Rechten führt aber zu völlig anderen Ausfallmodi. Ob normale Validatoren beide Schlüsselpaare zuverlässig bei Backup und Recovery gleichzeitig handhaben können, ist eher eine Praxisfrage. Aber zumindest denkt Dusk in Sachen Sicherheit einen Schritt weiter als die meisten Projekte. Es geht nicht davon aus, dass der Knoten nicht gehackt wird, sondern davon, dass er gehackt wird – und dann wird so entworfen, dass der Schaden so klein wie möglich bleibt. Diese Denkweise ist in der Krypto-Welt nicht allzu verbreitet. #dusk $DUSK
Ein Dusk-Deposit kann zwei völlig unabhängige Rollen umfassen. Der Konsensschlüssel bleibt auf dem Knoten und ist für das Abstimmen und das Signieren von Blöcken zuständig; der Eigentümerschlüssel hingegen kontrolliert die Rechte zum Entstaken und zum Auszahlen.
Klingt nach einer kleinen Einzelheit, oder? Aber wenn man genauer darüber nachdenkt, löst dieses Design ein Problem, das von den meisten Projekten ignoriert wird: Was passiert, wenn der Knoten gehackt wird? @Dusk
Die meisten PoS-Ketten-Validatoren haben nur ein einziges Schlüsselpaar – wenn es verloren geht, übergibt man damit gleichzeitig die Kontrolle über den Knoten und die gestakten Vermögenswerte. Der Angreifer kann nicht nur den Konsens stören, sondern auch direkt Ihre Coins abziehen. Dusk trennt diese beiden Dinge. Selbst wenn der Online-Knoten kompromittiert wird, kann der Angreifer höchstens den Konsens beeinflussen – und kann Ihre gestakten Vermögenswerte nicht anfassen.
Natürlich ist der Preis dafür eine komplexere operative Verantwortung. Dusk empfiehlt offiziell, aus demselben Seed eine weitere Adresse als Eigentümer festzulegen, während der Konsensschlüssel weiterhin vom Knoten verwendet wird. Aber wenn der Seed noch auf dem Server liegt, ist diese Trennung nicht vollständig. Das wirklich wirksame Muster ist, dass der Seed überhaupt nicht auf dem Knoten gespeichert ist – oder dass die Brieftasche ein starkes Passwort verwendet, das sich vom Passwort des Konsensschlüssels unterscheidet.
Das bringt mich zu einer grundsätzlicheren Frage: Viele Projekte halten ihr Sicherheitsdesign auf Schutz gegen externe Angriffe ausgerichtet, aber Dusk schützt bereits gegen interne Single Points of Failure. Der Konsensschlüssel kann online exponiert sein, während der Eigentümerschlüssel offline geschützt werden muss. Diese beiden Rollen zu trennen ist im Grunde eine Anerkennung einer Realität: Der Server wird auf jeden Fall ins Visier genommen – es ist nur eine Frage der Zeit.
Ich sage nicht, dass Dusk’ Sicherheitsdesign perfekt ist. Die Trennung der Schlüssel begrenzt zwar die Auswirkungen eines einzelnen Eindringens, der Verlust von Offline-Rechten führt aber zu völlig anderen Ausfallmodi. Ob normale Validatoren beide Schlüsselpaare zuverlässig bei Backup und Recovery gleichzeitig handhaben können, ist eher eine Praxisfrage. Aber zumindest denkt Dusk in Sachen Sicherheit einen Schritt weiter als die meisten Projekte. Es geht nicht davon aus, dass der Knoten nicht gehackt wird, sondern davon, dass er gehackt wird – und dann wird so entworfen, dass der Schaden so klein wie möglich bleibt. Diese Denkweise ist in der Krypto-Welt nicht allzu verbreitet. #dusk $DUSK
