SWIP-41: Stake Registry Update Queue

[awmacpherson]

Seeking feedback from SC and bee eng team on implementation and interface.

The main reason for prioritising this SWIP is to provide a delay/queue functionality for stake position changes wanted by withdrawable stake (#77). This SWIP can be introduced as a dependency for the latter in order to institute a delay.

[significance]

this lgtm and a very nice SWIP

one wrinkle is that the height decreases may not exactly work like this within the neighbourhood balancing SWIP itself, and also that without that there will not be any coherent signal of whether height would vary. this is dependent on a current valid chunk count which is not visible onchain in the current incarnation. i would argue for the height aspect to be removed from this initial implementation as it would remove some unusable complexity and that is always a good thing

@zelig wdyt?

other than that gtg from my corner pending final check and wrangle over the details

[awmacpherson]

As discussed with @0xCardiE I'm now planning to adjust this to make it co-dependent with SWIP-40, which simplifies some things.

• Don't need to deal with withdrawFromStake behaviour because SWIP-40 would remove this
• Add delay to withdraw function in SWIP-40. Same delay as reduce height makes sense to me, though I can also see arguments that full withdraw is "worse" than reduce height.

Also need to think a little bit about a "principled" approach to setting the parameters.

[significance]

ok! suggest we close this and move into 40 if you concur?

[awmacpherson]

ok! suggest we close this and move into 40 if you concur?

I think I can structure this so 40 and 41 are cleanly and logically separated. It may be useful to keep them as separate documents since they are conceptually different and may have different upgrade trajectories. Give me a week to figure this out.