Ich habe etwas Unangenehmes in der DUSK-Provisioner-Konfiguration bemerkt: Der Schlüssel, der meinen Knoten am Leben hält, um im Konsens zu bleiben, kann auch der Schlüssel sein, mit dem ein Angreifer mit meinem Einsatz davonspazieren kann.
Rusk benötigt den Konsensschlüssel auf dem Server, um zu signieren und abzustimmen. Wenn ich die Standardeinrichtung für das Staking verwende, wird derselbe Schlüssel auch zum Besitzer. Jetzt ist ein kompromittierter Provisioner nicht mehr nur ein Problem für die Verfügbarkeit. Der Angreifer kann ausstaken und die Position zurückziehen.
DUSK gibt mir eine sauberere Trennung. Ich kann mit einer separaten Owner-Adresse staken und dann ausschließlich consensus.keys auf die Maschine exportieren, auf der Rusk läuft. Der Knoten kann weiterhin signieren und abstimmen, aber die Befugnis, Gelder abzuziehen, bleibt anderswo. Diese Trennung ist am stärksten, wenn das Mnemonic niemals auf dem Server lebt.
Das verändert, wie ich über einen 1.000-DUSK-Provisioner nachdenke. Ich würde nicht nur fragen, ob der VPS gehärtet ist. Ich würde fragen, wozu der Schlüssel, der auf diesem VPS liegt, tatsächlich berechtigt ist.
Die Maschine, die für den Konsens heiß bleiben muss, braucht nicht auch meine Exit-Autorität.
#dusk $DUSK @Dusk