THE MACHINE THAT SIGNS FOR A DUSK PROVISIONER DOESN’T HAVE TO OWN THE STAKE.
I had been thinking about a validator key as if it represented one thing:
control.
But @Dusk_Foundation splits that control into two very different roles.
The Consensus Key is what the node uses to participate in consensus — voting and signing blocks.
The Owner Key is what can unstake and withdraw the capital behind that provisioner.
Dusk lets both roles use the same key by default.
But its operator documentation recommends separating them.
That distinction is more interesting to me than it first sounds:
consensus authority ≠ ownership authority.
A provisioner has to keep its consensus key available to an online machine that is constantly participating in the network.
That is exactly the kind of environment I would least want to give unnecessary authority over the stake itself.
If the node or consensus key is compromised, separating the Owner Key means the attacker does not automatically gain the ability to unstake and withdraw the funds.
So the design is doing something subtle.
It is not only protecting a key.
It is limiting the blast radius of the key that has to remain operational.
But there is a trade-off.
Moving ownership authority away from the node means the Owner Key now has to be protected somewhere else while still remaining recoverable when the operator actually needs to unstake or withdraw.
More separation can reduce one kind of risk while increasing operational responsibility elsewhere.
That is the part I would evaluate.
Not simply whether a Dusk provisioner is difficult to compromise.
I would ask:
If the consensus machine is compromised tomorrow, how much authority does the attacker actually inherit?
For infrastructure that has to stay online 24/7, maybe the strongest security model is not giving the machine more protection.
It is giving the machine less power to begin with.
#dusk $DUSK @Dusk
$BOME $ETH
I had been thinking about a validator key as if it represented one thing:
control.
But @Dusk_Foundation splits that control into two very different roles.
The Consensus Key is what the node uses to participate in consensus — voting and signing blocks.
The Owner Key is what can unstake and withdraw the capital behind that provisioner.
Dusk lets both roles use the same key by default.
But its operator documentation recommends separating them.
That distinction is more interesting to me than it first sounds:
consensus authority ≠ ownership authority.
A provisioner has to keep its consensus key available to an online machine that is constantly participating in the network.
That is exactly the kind of environment I would least want to give unnecessary authority over the stake itself.
If the node or consensus key is compromised, separating the Owner Key means the attacker does not automatically gain the ability to unstake and withdraw the funds.
So the design is doing something subtle.
It is not only protecting a key.
It is limiting the blast radius of the key that has to remain operational.
But there is a trade-off.
Moving ownership authority away from the node means the Owner Key now has to be protected somewhere else while still remaining recoverable when the operator actually needs to unstake or withdraw.
More separation can reduce one kind of risk while increasing operational responsibility elsewhere.
That is the part I would evaluate.
Not simply whether a Dusk provisioner is difficult to compromise.
I would ask:
If the consensus machine is compromised tomorrow, how much authority does the attacker actually inherit?
For infrastructure that has to stay online 24/7, maybe the strongest security model is not giving the machine more protection.
It is giving the machine less power to begin with.
#dusk $DUSK @Dusk
$BOME $ETH