PUP-18: Enabling rapid yet stable transition for any allowed node consolidation

Proposals Parameters
1

Update 30/6/22: This proposal has been withdrawn. Please see comments section.

Update 29/6/22: updated the language to focus specifically on the passage of PUP-19. The same concept can be applied to future desires to temporarily shorting UnstalingTime via a new PUP on a case-by-case basis.

Attributes

  • Author(s): @msa6867
  • Parameter: UnstakingTime
  • Current Value: 21 days
  • **Related: PUP-19
  • New Value: 1 day upon start of desired transition period; revert to 21 days thereafter

Summary

This proposal seeks to enable rapid yet stable network transition to a state of consolidation of POKT into fewer nodesr in response to the approval of PUP-19 . Namely it is proposed to temporarily adjust the UnstakingTime parameter to one day to allow node runners who wish to unstake POKT to do so in one day in anticipation that the vast majory purpose of such unstaking would be to add stake to existing nodes to compete for validator slots.UnstakingTime would then rervert to 21 days one week after it being temporarily set to 1 day.

Proposed action:, temporarily set UnstakingTime to 1 day (to allow rapid consolidation to take place in response to approval of PUP-19). Set UnstakingTime back to 21 days following a waiting period of one week counting from when it was set to 1 day

Abstract

A number of proposals have been discussed in the community with the common goal of reducing infra costs. These include:
Raising minimum POKT staked per node (PUP-17, 20)
Enabling a new category of Lite Nodes (PEP-35)
Weighting servicer selection by staked POKT (PIP-23)
Weighting reward per relay by staked POKT (PIP-22)
Increasing proposer allocation (PUP 15,17,19)

All of these have in common the efect of either requiring or incentiving consolidation of staked POKT into fewer nodes (or fwer “full nodes” in the case of LC).

Of these, PIP-22 and PUP-19 have been approved. While PIP-22 has yet to be implemented, PUP-19 is ready to be put into effect immediately.

This proposal allows rapid consolidation in response to proposer allocation being raised to 5%.

As a general theoretical construct, the best way to set UnstakingTime during the transition period to keep the network stable while allowing as rapid a transition as possible to the final state incentivized by the new implementation.
This is accomplished by keeping the transition period short (of order 5 days) and making UnstatkingTime short compared to the transition period (e.g., 1 day) . UnstakingTime would then be reset to 21 days following the transition.

However, in the case of raising proposer allocation to 5%, it is antic pated that it will lead to a significantly smaller percentage of current nodes desiring to unstake simultaneously than most of the other proposals, therefore making transition time long compared to UnstakingTime is not needed for stability purposes, so the only consideration is making the transition rapid by setting UnstakingTime to 1 day (temporarily) with no need to hold off immediately raising of proposer allocation to 5%

Motivation

**NOTE: most of the following discussion that has to do with smoothness of transition or stability is not applicable to raising proposer allocation to 5% since that transition should naturally be smooth and stable), but it is left here for completeness because this is all pertinent to when system is ready to turn on PIP-22 implementation. **

There are two motives to this proposal: (1) to keep network behavior smooth by decreasing the likelihood of mass unbonding on a single day in the event that one or more of the above improvement proposals passes and gets implemented, and (2) allow as rapid a transition s possible to the new system state made possible by the improvement proposal

The first motive is accomplished, counter-intuitively, by setting UnstakingTime short compared to countdown until change implementation. The second motive is accomplished by setting the target date to switch to the new allowed behavior as short as possible while still being large compared to UnstakingTime.

Rationale

Let’s look at the rationale of temporarily setting UnstakingTime to a time short compared to transition time by way of counter-example. Suppose DAO were to announce today the passage of PIP-22 and further announced the dev team had already coded it and was ready to turn it on on July 1 (today’s date being June 20th). The effect would be to drive every validator who could consolidate to unbond roughly 80% of their nodes all on the same day in a mad rush to free up the tokens needed for consolidation. since UnstakingTime is long compared to time until transition, the same immediate action will be taken by all validators.

While the network might handle just fine 80% of nodes getting removed on a single day, why take the chance when it is just as easy to spread the unbonding over several days. If UnstakingTime were temporarily set to 1 day along with the announcement that the transition was taking place July 1, there would be no urgency to unbond the first day, since whether the unbond today or tomorrow or on June 28, their POKT will be free by July 1 to add stake to remaining nodes (or to transition to Lite nodes, as the case may be).

Next, regarding the transition period itself, the desire to keep the time until execution of new state as short as possible once the code is finished and tested is, in general, self evident for those who benefit from the new state. However, it is not self-evident that keeping the transition short is also best for the stability of the system. Consider two scenarios ( in both of which UnstakingTime is temporarily set to 1 day) In the first scenario, transition is announced to take place 1 month from now. In the second scenario, transition is announced to take place 5 days from now… In both scenarios nodes that are most unprofitable are likely to unbond right away, so for them, the time until transition makes no difference. But for all the rest of the nodes who are going to consolidate (or transition to Lite node) and are treading water in terms of profitability, their maximum incentive is to hold off unbonding until the last possible day to take advantage of the boost in relay count caused by the first group to unbond. So the network will see a spike of unbonding on the first day the transition is announced and a spike of unbonding on the last possible day to unbond and still the have tokens ready for consolidating on transition day. Since this profit boost to remaining validators due to the first group unbonding is a cumulative effect, the benefit of pushing off unbonding until the last possible moment is diminished the shorter the transition period is, thus decreasing the height of a last-day spike in unbonding.

Avoiding a last-day spike is also best for creating a seamless transition to the post-transition environment since one ore more of the new parameters that get implemented in the code change may be sensitive to the count of how much unbonding takes place, in which case it is helpful for the DAO to get a good handle on what that count is prior to transition without the surprise of a last day spike of unbonding. (Note that temporarily setting UnstakingTime to 2 or 3 days instead of 1 day may help ensure DAO has accurate count of unbonding if having that count is helpful to set new parameters correctly, but does nothing to help prevent a last-day spike of unbonding in case of very long transition period - it only moves forward the day of that spike by one or two calendar days.)

Dissenting Opinions

Analyst(s)

Copyright

Copyright and related rights waived via CC0.

2 Likes
2

TL;DR - this friction node runners are feeling is the incentive doing its job well to minimize network disruptions. It’s worth exploring a reduction in the unstaking time to a level that still maintains the minimum necessary friction but this should be done in the long-term and not for the purpose of facilitating a mass unstake.

The friction and opportunity cost that causes community members to want to reduce this parameter is also exactly the incentive that maintains the network’s consensus power, P2P communication quality, and quality of service.

If the unstake period is temporarily shortened, no matter the length it’s shortened to, we will incentivize node runners to mass unstake while the parameter is set to the temporary value.

This will unquestionably disrupt consensus power, P2P communication quality, and quality of service, as the majority of nodes drop out of the session cycle and consensus/P2P processes.

Conversely, with the unstaking time being as long as it currently is, node runners are incentivized to stagger their unstakes in order to smooth out their income, as well as keeping some nodes in the game to take advantage of a longer period of time during which there is a smaller pool of node competitors.

3

There is some misunderstanding here. Done the wrong way, a proposed action that incentivizes a mass switch in how nodes are staked has the potential to cause a disruptive mass unstaking event, not the shortening of unstaking time. For example suppose the dev team issued an announcement saying “Suprise! We’ve been working in the background to implement and test the code changes anticipated in PIP-22; we plan to push the code change and turn on the weighted rewards tomorrow”. That would lead to a massive single-day unstaking event no matter the 21-day waiting period Why: because the announced time until the behavior time was short compared to the unstaking time. Smoothing out unstaking over a longer period is best accomplished if unstaking time is short compared to the time frame until turning on the change that induces mass unstaking.

That being said, I will rescind this proposal for the following reasons:

It is becoming apparent that it is not needed for the change affected by PUP-19. Not because the change does not have to potential to cause mass unstaking in the medium to long term, but rather because initial feedback indicates that the change is so complex to model and so dependent on other’s behavior that it will take days, if not weeks for node runners to decide how best to adjust their holding in response to PUP-19. Therefore unstaking will naturally get spread out over at least days to a few weeks .

It is also not needed for stability purposes in the case of PIP-22, since the condition of keeping unstaking time short compared to the expectation time of turning on the behavior is ,in this specific case, satisfied without adjusting unstaking time (21 days compared to ~40 days).

Since the nature of PUP-19 (complexity) and PIP-22 (longer than 21 days until implementation) are such that they will naturally experience a stable transition, there is no need to ensure stability by shortening unstaking time. However, this issue may need to get revisited in the future if other changes are turned on that could induce mass unstaking.

(As an aside, I agree with TL;DR… incorporating a 14 day or 21 day unbonding time has been copied from project to project to project with no one actually stopping to figure out if it really works and if there might be a better way. Tackling this issue would be a worthy undertaking sometime in the future with implications not only for pocket but dozens of other projects as well.)

4

To clarify my point, I support revisiting the length of the unstaking time as a permanent long-term change. You also make a good point about it not just being unstaking time that factors but unstaking time relative to the notice time of changes.

However, I feel my point stands that a temporary change in the unstaking time for the purpose of facilitating a mass unstake-consolidation would be disruptive, since you’re creating a limited window in which the unstake transaction would be able to use the temporary parameter value.