Prevent “ghost” provisioners

[herr-seppia]

If a provisioner is not active (both in good and bad faith) it can significantly impact the consensus performance when it's selected as block generator
To address this issue, we need to find a way to prevent (or at least lower the probability for) a "ghost" node to be selected.

Describe alternatives you've considered
Incentivise those provisioners who partecipate properly in the consensus.
Btw this:

1. don't prevent "ghost" provisioners to be selected, but it just lower (a little) their probability increasing the other nodes probability
2. exclude incentivization to the provisioners that are already cutoff by the quorum mechanism (only 67% will be rewarded)

Additional context
In order to prevent malicious nodes to play the game, staking withdraw should be allowed only after a period of unlocking
See also #1448

[herr-seppia]

Proposed solution
Since the block generator selection is deterministic, when a block is not accepted at the first iteration the network knows exactly which node (bls key) failed to produce an accepted block.
If a node keep continuing to not produce block over the time (let's think in term of epochs) it can be safely detected by the whole network.
In this case, a slashing mechanism should be triggered and included in the block.

This slashing mechanism can be:

1. proportional to the amount of missed blocks
2. percentage fixed but increased in case of missing consecutive epochs (eg: 20% - 40% - 70% - 100%)

To prevent slashing honest nodes that missed to produce block for a spot reason, a threshold should be taken into consideration.

E.g: node need to miss more than 30% of blocks (with at least 5 block missed)

Since this is not been incepted to harm provisioners, the slashed amount should not be removed from circulation (as other chains are used to do) but should just removed from the staked amount

⚠️ This mechanism can be exploited by user who want to withdraw their stake without paying fee (they can simply power off their nodes and wait for their stake amount to be slashed). To prevent this, the slashed amount should remain in the stake-contract state to be withdrawn as usual

[autholykos]

Awesome, let's give it a try. There might be the option in the future to consider diminishing the penalty, but as @HDauven pointed out this might create a bit of an attack surface.

[fed-franz]

If I understand it correctly, this is a "soft" slashing, where slashed stake isn't actually lost, but simply excluded from block production.
In other words, the provisioner does not lose their stake, but are simply prevented from earning from it.

Is this correct?

[HDauven]

@fed-franz exactly.

Let's take the following example: You stake 1000 DUSK. This 1000 DUSK would be set to an active state.

If you misbehave, a deduction penalty multiplier would be applied. In the values used above that @herr-seppia uses in option 2, for the first epoch of misbehavior, you would end up with 800 active DUSK and 200 inactive DUSK.

Inactive within this context means, no longer included in the sortition. The result of this is that after the epoch they misbehaved in, their chance of being selected has been reduced, having a sizable impact on their protocol yield.

If an actor decides to unstake, the full amount they originally staked will be returned to them, thus the 1000 DUSK.

The effect of this is that misbehaving actors do not lose in absolute value on their initial stake, but instead lose future yield. Due to stakes taking 2 epochs to mature, an actor that misbehaves will both lose yield in terms of ROI due to a loss in active stake and in having to unstake and restake if they want to get a full active balance again.

[fed-franz]

Would something like this make sense/be viable?:

• We implement an "active" state for stakes. An 'inactive' state would be like a "temporary unstake": unlike unstaking, the stake isn't actually unlocked, and its age/maturity is preserved. In other words, the stake is frozen.
• When a node shuts down, it automatically creates a transaction to "de-activate" the stake (i.e., set its active state to "false")
• Inactive stakers are not included in the sortition, so they cannot be selected
• When the node restarts, a new transaction is created to reactivate the stake

This mechanism would co-exist with slashing, which I believe it's still necessary to de-incentivize repeated misbehavior.

[herr-seppia]

This approach can be seen as a "pause" for a stake. It for sure help an honest node to be offline for maintenance, without the need to unstake.
However this doesn't cover at all the issue we have with:

• slow nodes
• misconfigured nodes
• offline nodes (talking about unplanned mantainance or similar)
• malicious nodes

The only way we can measure if a node is working properly is: "Is this node producing valid block/votes?"
About the votes, I believe we should remove this parameter, because a vote can be produced after some delay or the vote can even never been received by all the provisioners (due to drift in steps).

From what I see, the only information that can be deterministically verified, is if a node produced a block that has been accepted. Hence why I was focusing only on that part

[fed-franz]

* We'll end up with more transactions on the network. (Might be fine)

* It will complicate the stake contract, especially if you combine it with the suggested slashing approach. Not sure if it is a problem, but if we go for soft slashing we need to be really careful with how we separate these two. (Active vs inactive stake in temporary unstake and slashing)

* The wallet/BLS key the node uses needs to have a minimum balance to allow for the temporary unstake. Given the potential fluidity of gas prices, a termination request of the node will need to request the operator to give some input here. Same applies on startup. So the shutdown and startup logic of the node needs to be expanded.

Replying to the above

• Number of transactions: While the number of total transactions would indeed increase, I'd expect such an increase to be limited: as stakers' revenue depend on their online status, they are incentivized to stay online.
• Stake contract: it might not be necessary to use different statuses. instead, I would aim at having a unique "active"/"inactive", with another mechanism to understand if the inactive state is due to the stake having being slashed. Additionally, as this mechanism is already dealing with "honest" stakers going offline, we don't necessarily need to be soft on slashing. As slashing would occur in extreme cases, we could actually think about doing it properly (i.e. burn a portion of the stake).
• Node management: this might need more discussion (I lack some info to formulate a workaround). A simple workaround that would allow to leave node management untouched, could be to make these state-change transactions "special" (that is, different form other transactions) and free-of-charge, so no extra balance would be needed. Still, if nodes do not have access to the provisioner's wallet, it would be indeed necessary to have some user interaction.

[fed-franz]

This approach can be seen as a "pause" for a stake. It for sure help an honest node to be offline for maintenance, without the need to unstake. However this doesn't cover at all the issue we have with:

* slow nodes

* misconfigured nodes

* offline nodes (talking about unplanned mantainance or similar)

* malicious nodes

The only way we can measure if a node is working properly is: "Is this node producing valid block/votes?" About the votes, I believe we should remove this parameter, because a vote can be produced after some delay or the vote can even never been received by all the provisioners (due to drift in steps).

From what I see, the only information that can be deterministically verified, is if a node produced a block that has been accepted. Hence why I was focusing only on that part

This "pause" solution is indeed only targeting the "honest" case (I specifically thought about it the last time that provisioners disconnected, for some reason, without unstaking.
An all-comprehensive solution would be ideal, but likely harder to find (at least not in the short term).
However, a combination of mitigating measures can make the network robust enough to deal with the problem as a whole.

A good approach would be to think about possible solutions or mitigations in all different cases and then converge them into a unified mechanism.

[fed-franz]

There's two things I'm uncertain about:

1. Is this game-able?

2. Could this make (temporarily) unstaking so easy that we'll end up very quickly with peak moments where too many people are in a temporary state that it could effect the network negatively? For instance, temporary centralization risks during a new node version release.

1. Not totally sure about this, but wouldn't it be already? An inactive state would prevent the stake from generating revenues while being locked at the same time. Provisioners would not be exactly incentivized to have an inactive stake. Did you have something different in mind?
2. The case you mention (a massive number of nodes reboot due an update) seems independent from the ability of deactivating the stake. I mean, this would happen anyway.
   Even so, if it does occur, it would be better to have many inactive stakes than many ghost provisioners, right?
   Not sure about the general case. Is there a situation in which deactivating a stake would be convenient (or necessary) for a large number of nodes?

[HDauven]

Becoming a ghost provisioner when updating your client, while being picked in the intervening period, seems like a risk. The node operator would have to unstake and restake again if they're soft slashed, reducing the security of the network over a more prolonged period. Dependent on the strictness of soft slashing.

That would be mitigated by your proposal @fed-franz.

[fed-franz]

Have we considered Delegated PoS?
If DPoS has been discarded, what was the reason?
While DPoS wouldn't eliminate the problem, it would lower its magnitude by reducing the number of validators that actually need to be online when the block has to be created.

[herr-seppia]

I've personally never liked it.
DPos is an attempt to centralize the decentralization (imvho), however it has a lot of pro (I have to admit it)

[HDauven]

What is interesting is to look at protocols that have DPoS in protocol and (liquid) staking derivatives, versus protocols that do not have it in protocol. What are the pros and cons there? How do we see development over time?

I'm not a big fan of DPoS either, even though there are a lot of benefits. Centralization does not only affect network security, but it is also intertwined with systematic risks in the crypto space itself, as we've seen with centralized entities that have collapsed recently.

If a DPoS staking service ends up defaulting due to a parent company being illiquid, this can have a sizable impact on our network security as well.

I'm not sure if we still have no upper-bound on the maximum amount one can stake @herr-seppia but I see that as a risk as well. If someone builds a pooled staking service around Dusk (which is plausible), that could be a big centralization vector as well towards very big nodes.

[herr-seppia]

We currently have no upper-bound, but this is just a detail for now. I'm open to all the possibilities.

To be honest, even if I had a huge amount of DUSKs to stake, I would never put them into only one node/address

[fed-franz]

I've personally never liked it. DPos is an attempt to centralize the decentralization (imvho), however it has a lot of pro (I have to admit it)

I agree that DPoS is more centralized than PoS, but provisioners would still have voting power to choose (or rule out) delegates.
What I mean is that, while block producers would be less, they would still be "watched" by all stakers.

[fed-franz]

What is interesting is to look at protocols that have DPoS in protocol and (liquid) staking derivatives, versus protocols that do not have it in protocol. What are the pros and cons there? How do we see development over time?

That's definitely something we need to do.

I'm not a big fan of DPoS either, even though there are a lot of benefits. Centralization does not only affect network security, but it is also intertwined with systematic risks in the crypto space itself, as we've seen with centralized entities that have collapsed recently.

If a DPoS staking service ends up defaulting due to a parent company being illiquid, this can have a sizable impact on our network security as well.

Not sure I see a direct correlation between a defaulting company and the security of the network.
I guess if a staking service has financial troubles, they might want to cash out what they have, which means they would unstake what they own. But all delegated stakes would return to their owners, which would likely delegate them again to other producers.
Maybe I'm missing something here, though. Could you expand on your point?

I'm not sure if we still have no upper-bound on the maximum amount one can stake @herr-seppia but I see that as a risk as well. If someone builds a pooled staking service around Dusk (which is plausible), that could be a big centralization vector as well towards very big nodes.

This is somewhat inherent to stake-based protocols I think. It might be worth discussing it even with our current protocol.
But I think an upper-bound to stake would be relatively easy to circumvent. Even more in our case, where provisioners are anonymous.

[fed-franz]

Either way, this requires deeper analysis to understand pros and cons of the choice.

My question was more aimed at knowing if this option had been considered (and possibly ruled out) in the past.
I'll take some time in the future to study DPoS solutions and share my findings with you.

[HDauven]

@goshawk-3

[HDauven]

In what conditions should slashing take place?

Minimum required:

• Not sending a candidate block as a block generator.
• Sending invalid candidate as a block generator.
• A bad actor trying to penalize good actors through its actions.

Under what conditions could this take place?

• Low specced machine, not able to execute in the rounds.
• Network outage
• Syncing
• Network eclipsing

The latter case is currently cheap to do. Factors to look into:

• Increasing Kadcast message redundancy. -> Bandwidth implications
• Look at minimum stake as a factor in cost to execute the attack.
• Decrease Kadcast bucket rebuilding time.