keep-network / keep-core

The smart contracts and reference client behind the Keep network
https://keep.network
MIT License
124 stars 75 forks source link

Stake undelegation and minimum group count adjustments #933

Closed pdyraga closed 4 years ago

pdyraga commented 5 years ago

According to our current design, the network operator has to wait for a certain undelegation period before we release the undelegated stake. This period should be longer than the group expiration time.

This card aims at exploring the corner case: what happens if we fall below the minimum group threshold and no longer expire groups?

pdyraga commented 5 years ago

https://www.flowdock.com/app/cardforcoin/keep/threads/dlrk0vuLrDeWG5cq1PLIl2V6rRA

eth-r commented 5 years ago

If we no longer expire groups by timing out, we should still let undelegation happen normally; otherwise the proper privilege relationship is inverted (staking contract needs to get trusted input from operator contract). In case this happens, we need to have a threshold of members undelegating when we terminate the specific impacted group (maybe the same 1/4 threshold as with DKG nofail).

This enables an attack where groups can be forced to terminate by undelegating but if our DKG is generally sufficiently reliable it requires a high adversary power and mostly impacts groups where the adversary has a large representation, so it isn't so much of a big deal.

There's also the question of where the low group count is determined if we have multiple operator contracts being used for the same service contract; if the group count is determined on the operator contract side it means we hit this condition if operator contracts are upgraded, effectively preventing deprecated operator contracts from clearing properly. This indicates that we should do these adjustments from the service contract side. We may also want to tweak the DKG triggering threshold and DKG contribution on the pricing side, to favor group creation when there are fewer groups and to slow it down when there are enough.