add SWIP-40: Withdrawable stake

[awmacpherson]

Draft of a simple approach to enabling stake withdrawals.

Discussion points:

• The conditionals for allowing withdrawal require a reference to the Redistribution contract.
• I expect that the final form of allowing withdrawals will involve an enforced delay via a 2 step commit/withdraw process. Whatever we do should bear in mind the need to smooth this transition, if we don't implement it right away.
• IMO the biggest disadvantage with this approach is that in times of heightened trading activity, we are likely to see stake being withdrawn to engage in trading, possibly leading to network instability; the current proposal doesn't give us any method to soften this blow by throttling withdrawals.
• New terminology: instant unfreeze, penalty evasion, shadow stake attack
• Instability from stake migration (including exits, overlay change, and height change especially reduction) deserves further attention.

[significance]

very well done, thankyou @awmacpherson

of course, i agree, this changes storage guarantees somewhat and that i believe will need to be mitigated, at least so as to discourage the sudden exit of many nodes, causing an destabilising reduction in network storage capacity and hence data loss

discussion points:

1/ how to implement exit friction to provide deference to network stability
2/ how many nodes/round
3/ should nodes be able to play during exit period?
4/ should the number of nodes / exit rate linked to stamp storage capacity and if so how?

widened attack vectors for consideration:

1/ exit and restake in different nhd with less financial consequences (with 2 round pause downtime)
2/ exit and restake a different amount (less, currently can be more)
3/ exit many nodes at once with much less financial consequences

[0xCardiE]

I am against any instant withdrawing (even with penalties), as this would be a huge problem in BZZ price spike. As we have such low mcap and liquidity we must have 20-30 days thawing as in that time price surges dont affect withdrawals so much.
Price surge is probably gone at that point and people will not take it all out or at all (speaking from experience) and thawing concept works in easing out number of withdrawals.

In case we come o some +200M mcap and price is stable and there is lot of liquidity we could rethink this, but until then we need thawing.

[awmacpherson]

I enumerated some of the considerations going into withdrawal delay/queue design in a research memo (also shared in Discord):

https://hackmd.io/oT1IOc7iRz-TCz1tYLeD3Q

Price surge is probably gone at that point and people will not take it all out or at all (speaking from experience) and thawing concept works in easing out number of withdrawals.

Good point, I incorporated it into my memo among several other advantages of a delay (or fancier queue). As a finger-in-the-air figure, 30 days sounds like a reasonable delay for starters; it's already a big reduction from ∞.

Some further thoughts about how to design withdrawal delays:

• Most of the benefits of the queue are to do with the fact that it slows down node exits. Therefore, node operators must be incentivised to continue running and participating while in the queue. Thus, they must continue to receive income for participation during the queue, and potentially even penalised for non-participation. This addresses @significance's discussion point (3).
• Whatever opportunities or penalties are incurred by just switching off nodes unannounced without waiting for the queue, some nodes may decide to just accept them and treat it as an exit tax. Ideally, the penalties should exceed the opportunity cost of waiting in most cases. This opportunity cost is increasing in the stake amount.
• If typical stake deposits are much higher than the minimum, and partial drawdowns are allowed without a delay, NOs can mostly evade unannounced withdrawal penalties by drawing down to the minimum stake before turning off their nodes. So we should consider limiting/throttling partial drawdowns.
• Reduction of AoR (by reducing height) has the same effect on network health as an exit, so should probably be subjected to the same queueing treatment.
• Moving AoR by changing overlay address does not reduce average replication rate, but has the same effect as an exit on the source neighbourhood. Perhaps any delay implemented for moving AoR could be based on the relative population of the source and target neighbourhoods?
• For reasons already mentioned in the current SWIP, node operators must not be allowed to instantly increase stake or enter new neighbourhoods in the middle of a round. Currently a suitable delay (2 rounds) is enforced in the validity checks at the start of the commit() call in the redistribution contract — better make sure not to lose it in any refactor.

Some of these relate to @significance's possible threat vectors (1) and (2).

I'll work through this and draft a new SWIP in the coming month.

[significance]

very nice! thank you @awmacpherson

enjoyed the low pass filter analogy 🧡