Queued updates and withdrawable stake

[awmacpherson]

Merged spec from SWIPs 40 and 41, including everything except revert of SWIP-20. Updated to align with implementation at ethersphere/storage-incentives#309.

[significance]

thank you for the SWIP 🙇

as discussed, please can you emphasise the rationale behind withdrawal delay i.e. encouraging predicability / reducing unpredictability

in this vein i think we have agreement that limiting the amount of times an overlay can be changed over some similar period would also be beneficial in this regard without incurring too much friction in terms of neighbourhood rebalancing

i would suggest it were set at once every half or quarter the period of the withdrawal delay, but certainly less, to allow for some margin of error in coordination of node repositioning

it was also mooted that 14 days could well be sufficient delay and that the exact value of that constant and/or mode and means of tuning it would benefit from some more discussion

[awmacpherson]

as discussed, please can you emphasise the rationale behind withdrawal delay i.e. encouraging predicability / reducing unpredictability

Sure, I will expand on this.

in this vein i think we have agreement that limiting the amount of times an overlay can be changed over some similar period would also be beneficial in this regard without incurring too much friction in terms of neighbourhood rebalancing

i would suggest it were set at once every half or quarter the period of the withdrawal delay, but certainly less, to allow for some margin of error in coordination of node repositioning

While I think this is a reasonable direction to explore due to the sync costs excessive node churn could impose on the network, in terms of both motivation and implementation is it independent of the present SWIP. This SWIP does not make any change to the rate at which one can change neighbourhoods (whether staked or not). So I'd argue that this research direction should not block merging this PR. Would you agree?

it was also mooted that 14 days could well be sufficient delay and that the exact value of that constant and/or mode and means of tuning it would benefit from some more discussion

Regardless of what value we choose for the delay parameter now, we ought to establish processes to monitor the behaviour of the network and determine whether the delay parameter is performing as desired or if it ought to be changed. I'll work on adding something on that to the SWIP too.

If we are concerned about committing to a particular withdrawal notice period that may be awkward to change later, one option would be to add an admin function that allows the deployer to change the parameter on the live contract without having to redeploy. However, I would highlight a couple of caveats to this approach:

1. Unrestricted control of the wait period would give the admin power to effectively rug funds by setting the wait to a very large value. That in turn places a higher target value on the admin keys, e.g. for social engineering attacks. To protect depositors, the admin function ought therefore to have some safeguards that restrict the admin's power, for example:
   • A hardcoded maximum value (30 days?)
   • An enforced wait period before admin-triggered changes to the value come into effect, so that depositors not happy with the new configuration have time to trigger exits or withdrawals.
2. Implementing such a function does not save us from the need to set up processes for monitoring and deciding when the parameter should be updated. The situation in which it does buy us something is if we do decide there needs to be a retuning and there are no other upcoming updates to the stake registry that would necessitate a redeployment anyway.
3. We need to decide whether decisions about calling the update function necessitate a SWIP or if it can be conducted more efficiently through some other sufficiently well-defined process.

Understanding these factors, especially (1), means that trying to get this function into the current SWIP could further delay the decision process. My view is that it isn't really necessary right now for the following reasons:

1. We are probably going to need to update the stake registry again, and further parameter updates can be bundled with that change.
2. The choice between 14 or 28 days, or even 7 days, probably does not matter all that much at the current network size. The real win here is coming from bringing it down from ∞ to less than a month.

Nonetheless, if you want it I also don't mind adding it.