I assumed staking on a PoS chain meant one key controlling one thing: put DUSK in, get rewards out, same key handles it end to end.
Dusk's own operator docs split that in two.
The consensus key is the key a node uses to sign and vote in consensus. It has to live on an internet-connected node and participate as the validator operates. The owner key is separate: it's the key that can unstake or withdraw funds, and the docs say it doesn't need to touch the node at all.
The security benefit isn't simply that there are two keys. It's that the authority to participate in consensus and the authority to withdraw funds don't have to live in the same place. If the consensus key gets compromised because the server it's on gets breached, an attacker can interfere with consensus participation, but they still can't unstake or withdraw the stake. That authority never lived on the machine that's exposed to the internet in the first place. Which means the real security question isn't just how much is staked. It's where the authority to withdraw it actually sits relative to the machine that's exposed to attackers.
But there's a catch the docs don't hide: this separation isn't the default. If you stake without specifying a separate owner, the consensus key automatically becomes the owner too, one key, one boundary, back to the model I originally assumed. The safer setup is a choice an operator has to actively make, not something the protocol forces on them.
"A security boundary that has to be opted into is a different guarantee than one built into the default path, even when both are technically available."
What I'd actually want to know: how many active provisioners run with a separate owner key versus the default, because that would tell me whether the stronger boundary is actually being adopted, rather than merely being available.
#dusk $DUSK @Dusk
Dusk's own operator docs split that in two.
The consensus key is the key a node uses to sign and vote in consensus. It has to live on an internet-connected node and participate as the validator operates. The owner key is separate: it's the key that can unstake or withdraw funds, and the docs say it doesn't need to touch the node at all.
The security benefit isn't simply that there are two keys. It's that the authority to participate in consensus and the authority to withdraw funds don't have to live in the same place. If the consensus key gets compromised because the server it's on gets breached, an attacker can interfere with consensus participation, but they still can't unstake or withdraw the stake. That authority never lived on the machine that's exposed to the internet in the first place. Which means the real security question isn't just how much is staked. It's where the authority to withdraw it actually sits relative to the machine that's exposed to attackers.
But there's a catch the docs don't hide: this separation isn't the default. If you stake without specifying a separate owner, the consensus key automatically becomes the owner too, one key, one boundary, back to the model I originally assumed. The safer setup is a choice an operator has to actively make, not something the protocol forces on them.
"A security boundary that has to be opted into is a different guarantee than one built into the default path, even when both are technically available."
What I'd actually want to know: how many active provisioners run with a separate owner key versus the default, because that would tell me whether the stronger boundary is actually being adopted, rather than merely being available.
#dusk $DUSK @Dusk
