Der Schlüssel: Muss ein Dusk-Provisioner den Stake nicht besitzen
Das Kompromittieren eines Provisioner-Servers muss einem Angreifer keine Auszahlungsbefugnis über das DUSK geben, das dahinter liegt.
Dusk-Staking trennt zwei Rollen. Der Consensus Key ist die Online-Anmeldeinformation, die der Node verwendet, um abzustimmen und Blöcke zu signieren. Der Owner Key steuert das Unstaking und das Zurückziehen des Stakes. Wenn kein Owner angegeben ist, wird der Consensus Key standardmäßig zum Owner. Dusk unterstützt jedoch auch rusk-wallet stake --owner <OWNER_ADDRESS>, um diese Rollen zu trennen.
Das verändert die Sicherheitsgrenze eines Provisioners.
Die Node benötigt consensus.keys, um an Konsens teilzunehmen; sie braucht nicht die Owner-Wallet, die direkt daneben sitzt. Dusk’ aktuelle Anleitung für Betreiber empfiehlt ausdrücklich, die Owner-Wallet und das Wiederherstellungsmaterial nicht auf der Node zu halten.
Damit kann ein Betreiber den Consensus Key als Hot-Betriebsanmeldeinformation behandeln, ohne automatisch dieser Hot-Umgebung die Möglichkeit zu geben, mit dem Kapital auszusteigen.
Die Trennung ist jedoch kein absoluter Schutz. Ein gestohlener Consensus Key kann weiterhin widersprüchliche oder anderweitig ungültige Konsensnachrichten signieren, und die harten Penalties von Dusk können dafür den Stake verbrennen.
Die praktische Entscheidung fällt daher bereits vor dem Staking: Die Verwendung der Standardkonfiguration kombiniert Konsensbefugnis und Kapital-Kontrollbefugnis; die Angabe eines separaten Owners begrenzt, was ein kompromittierter Validator-Host direkt tun kann.
@Dusk $DUSK #dusk
Das Kompromittieren eines Provisioner-Servers muss einem Angreifer keine Auszahlungsbefugnis über das DUSK geben, das dahinter liegt.
Dusk-Staking trennt zwei Rollen. Der Consensus Key ist die Online-Anmeldeinformation, die der Node verwendet, um abzustimmen und Blöcke zu signieren. Der Owner Key steuert das Unstaking und das Zurückziehen des Stakes. Wenn kein Owner angegeben ist, wird der Consensus Key standardmäßig zum Owner. Dusk unterstützt jedoch auch rusk-wallet stake --owner <OWNER_ADDRESS>, um diese Rollen zu trennen.
Das verändert die Sicherheitsgrenze eines Provisioners.
Die Node benötigt consensus.keys, um an Konsens teilzunehmen; sie braucht nicht die Owner-Wallet, die direkt daneben sitzt. Dusk’ aktuelle Anleitung für Betreiber empfiehlt ausdrücklich, die Owner-Wallet und das Wiederherstellungsmaterial nicht auf der Node zu halten.
Damit kann ein Betreiber den Consensus Key als Hot-Betriebsanmeldeinformation behandeln, ohne automatisch dieser Hot-Umgebung die Möglichkeit zu geben, mit dem Kapital auszusteigen.
Die Trennung ist jedoch kein absoluter Schutz. Ein gestohlener Consensus Key kann weiterhin widersprüchliche oder anderweitig ungültige Konsensnachrichten signieren, und die harten Penalties von Dusk können dafür den Stake verbrennen.
Die praktische Entscheidung fällt daher bereits vor dem Staking: Die Verwendung der Standardkonfiguration kombiniert Konsensbefugnis und Kapital-Kontrollbefugnis; die Angabe eines separaten Owners begrenzt, was ein kompromittierter Validator-Host direkt tun kann.
@Dusk $DUSK #dusk
