Warum @Dusk die Konsensautorität von der Asset-Autorität trennt
Ich habe die Node-Operator-Dokumente von Dusk gelesen, als eine Einzelheit mich aufhorchen ließ: Die Maschine, die den Konsens ausführt, soll nicht den Schlüssel besitzen, der die Beteiligung (Stake) kontrolliert.
Das klingt nach Schlüsselhygiene. Ich denke, es ist mehr.
Der Provisioner-Key von Dusk lebt auf dem Node, weil der Konsens ihn benötigt, um Vorschläge, Validierungen und Abstimmungen zu signieren. Aber Dusk trennt diesen Schlüssel vom Schlüssel des Eigentümers/Fonds, der Unstaking und Abhebungen steuert. Sein technisches Update erklärt die Motivation: Wenn ein Node kompromittiert wurde, konnten Provisioner-Keys zuvor missbraucht werden, um Stake und Rewards zu verschieben.
Die interessante Entscheidung ist, wofür #Dusk den Konsensschlüssel nicht verantwortlich macht. Es akzeptiert, dass ein Konsens-Teilnehmer kompromittiert werden kann, und schränkt dann die Konsequenz ein. Konsensautorität und Asset-Autorität werden zu unterschiedlichen Fähigkeiten.
Ich bin immer wieder zu dieser Unterscheidung zurückgekehrt. Ein Provisioner hat etwas zu verlieren durch Konsensverhalten und Slashing, aber ein Angreifer, der den Server übernimmt, erbt nicht die Fähigkeit, das Kapital zu liquidieren. Die Sicherheitsgrenze verschiebt sich von „den Validator perfekt schützen“ zu „Validator-Kompromittierung reicht nicht für die finanzielle Kontrolle aus“.
Dabei gibt es einen Preis: Ein weiterer Schlüssel muss geschützt werden, wenn Gelder bewegt werden. Aber diese Unannehmlichkeit ist das Mittel. $DUSK tauscht Einfachheit gegen Kapselung ein.
Die tiefere Frage ist, ob diese Trennung robust bleibt, wenn sich Kapital und Automatisierung um Provisioner ansammeln, oder ob sich die beiden Autoritäten langfristig wieder miteinander verbinden.
Ich habe die Node-Operator-Dokumente von Dusk gelesen, als eine Einzelheit mich aufhorchen ließ: Die Maschine, die den Konsens ausführt, soll nicht den Schlüssel besitzen, der die Beteiligung (Stake) kontrolliert.
Das klingt nach Schlüsselhygiene. Ich denke, es ist mehr.
Der Provisioner-Key von Dusk lebt auf dem Node, weil der Konsens ihn benötigt, um Vorschläge, Validierungen und Abstimmungen zu signieren. Aber Dusk trennt diesen Schlüssel vom Schlüssel des Eigentümers/Fonds, der Unstaking und Abhebungen steuert. Sein technisches Update erklärt die Motivation: Wenn ein Node kompromittiert wurde, konnten Provisioner-Keys zuvor missbraucht werden, um Stake und Rewards zu verschieben.
Die interessante Entscheidung ist, wofür #Dusk den Konsensschlüssel nicht verantwortlich macht. Es akzeptiert, dass ein Konsens-Teilnehmer kompromittiert werden kann, und schränkt dann die Konsequenz ein. Konsensautorität und Asset-Autorität werden zu unterschiedlichen Fähigkeiten.
Ich bin immer wieder zu dieser Unterscheidung zurückgekehrt. Ein Provisioner hat etwas zu verlieren durch Konsensverhalten und Slashing, aber ein Angreifer, der den Server übernimmt, erbt nicht die Fähigkeit, das Kapital zu liquidieren. Die Sicherheitsgrenze verschiebt sich von „den Validator perfekt schützen“ zu „Validator-Kompromittierung reicht nicht für die finanzielle Kontrolle aus“.
Dabei gibt es einen Preis: Ein weiterer Schlüssel muss geschützt werden, wenn Gelder bewegt werden. Aber diese Unannehmlichkeit ist das Mittel. $DUSK tauscht Einfachheit gegen Kapselung ein.
Die tiefere Frage ist, ob diese Trennung robust bleibt, wenn sich Kapital und Automatisierung um Provisioner ansammeln, oder ob sich die beiden Autoritäten langfristig wieder miteinander verbinden.