#dusk $DUSK Heute werde ich $MUUB .$1000RATS kaufen. Es ist gleich so weit, dass es abgeworfen wird, und ich warte darauf, um zu einem perfekten Zeitpunkt einzusteigen.
Ich habe darüber nachgedacht, dass ein Validator-Schlüssel eine Aufgabe hat: zu beweisen, dass der Node für die Teilnahme am Konsens berechtigt ist.
Das Node-Setup von Dusk hat diese Annahme weniger angenehm gemacht.
Ein Dusk-Stake kann zwei getrennte Rollen beinhalten.
Der Konsensschlüssel bleibt beim Node und wird verwendet, um abzustimmen und Blöcke zu signieren. Der Owner-Key steuert die Möglichkeit, den Stake zu entsperren und die Gelder auszuzahlen.
Wenn ein Operator keinen separaten Owner angibt, wird der Konsensschlüssel standardmäßig zum Owner. Das ist einfacher, weil es nur eine Adresse zu verwalten gibt.
Aber dadurch werden auch zwei sehr unterschiedliche Arten von Autorität zusammengeführt.
Wenn der Online-Node kompromittiert wird, bedeutet das möglicherweise nicht mehr, dass man nur die Fähigkeit erhält, in den Konsens einzugreifen. Wenn derselbe Schlüssel die Eigentümerschaft kontrolliert, könnte ein Angreifer potenziell auch den Stake aussetzen und die Gelder des Operators abziehen.
Dusk empfiehlt daher, die Rollen zu trennen. Der Operator kann eine andere Adresse aus demselben Mnemonic wie der Owner zuweisen, während der Konsensschlüssel weiterhin für den Node verfügbar bleibt.
Das reduziert, was ein gestohlener Node-Schlüssel tun kann.
Aber die Trennung ist nicht vollständig, wenn das Mnemonic noch auf dem Server gespeichert ist. Dusk’ Leitfaden sagt, dass das Modell am effektivsten ist, wenn das Mnemonic nicht auf dem Node bleibt oder wenn das Wallet ein starkes Passwort verwendet, das sich vom Passwort des Konsensschlüssels unterscheidet.
Was meine Aufmerksamkeit geweckt hat, war, wie das sicherere Design mehr operative Verantwortung schafft.
Der Owner-Key muss geschützt und wiederherstellbar bleiben, wenn der Operator den Stake entsperren oder erneut staken muss. Die Trennung der Schlüssel begrenzt eine einzige Kompromittierung, aber der Verlust der Offline-Autorität schafft einen ganz anderen Ausfall.
Gibt die Trennung der Konsensaktivität von der Stake-Eigentümerschaft den Operatoren die richtige Sicherheitsgrenze, oder wird die Wiederherstellung des Owner-Keys zur wichtigeren operativen Risikoquelle??
#dusk @Dusk
Dusk Validator Key Setup: Was ist wichtiger?
Ich habe darüber nachgedacht, dass ein Validator-Schlüssel eine Aufgabe hat: zu beweisen, dass der Node für die Teilnahme am Konsens berechtigt ist.
Das Node-Setup von Dusk hat diese Annahme weniger angenehm gemacht.
Ein Dusk-Stake kann zwei getrennte Rollen beinhalten.
Der Konsensschlüssel bleibt beim Node und wird verwendet, um abzustimmen und Blöcke zu signieren. Der Owner-Key steuert die Möglichkeit, den Stake zu entsperren und die Gelder auszuzahlen.
Wenn ein Operator keinen separaten Owner angibt, wird der Konsensschlüssel standardmäßig zum Owner. Das ist einfacher, weil es nur eine Adresse zu verwalten gibt.
Aber dadurch werden auch zwei sehr unterschiedliche Arten von Autorität zusammengeführt.
Wenn der Online-Node kompromittiert wird, bedeutet das möglicherweise nicht mehr, dass man nur die Fähigkeit erhält, in den Konsens einzugreifen. Wenn derselbe Schlüssel die Eigentümerschaft kontrolliert, könnte ein Angreifer potenziell auch den Stake aussetzen und die Gelder des Operators abziehen.
Dusk empfiehlt daher, die Rollen zu trennen. Der Operator kann eine andere Adresse aus demselben Mnemonic wie der Owner zuweisen, während der Konsensschlüssel weiterhin für den Node verfügbar bleibt.
Das reduziert, was ein gestohlener Node-Schlüssel tun kann.
Aber die Trennung ist nicht vollständig, wenn das Mnemonic noch auf dem Server gespeichert ist. Dusk’ Leitfaden sagt, dass das Modell am effektivsten ist, wenn das Mnemonic nicht auf dem Node bleibt oder wenn das Wallet ein starkes Passwort verwendet, das sich vom Passwort des Konsensschlüssels unterscheidet.
Was meine Aufmerksamkeit geweckt hat, war, wie das sicherere Design mehr operative Verantwortung schafft.
Der Owner-Key muss geschützt und wiederherstellbar bleiben, wenn der Operator den Stake entsperren oder erneut staken muss. Die Trennung der Schlüssel begrenzt eine einzige Kompromittierung, aber der Verlust der Offline-Autorität schafft einen ganz anderen Ausfall.
Gibt die Trennung der Konsensaktivität von der Stake-Eigentümerschaft den Operatoren die richtige Sicherheitsgrenze, oder wird die Wiederherstellung des Owner-Keys zur wichtigeren operativen Risikoquelle??
#dusk @Dusk
Dusk Validator Key Setup: Was ist wichtiger?
🔘 Limiting node-key damage
🔘 Protecting owner-key recove
🔘 Both are equally critical
🔘 One key is simpler
4 Stunde(n) übrig
