Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Enable Partial Unbonding #5
The weaknesses of the current all-or-nothing approach to unbonding are as follows:
This proposal would eliminate all of these weaknesses.
The potential weakness is that it will now be easier to constantly withdraw LPT from the bonded state, and therefore it’s possible that there will be less participating stake. This shouldn’t be a concern however because it just creates more opportunity for those who remain bonded to grow their stake.
Note: this is the start of the discussion so I leave out many of the second order updates that will need to be made until we can discuss whether this approach is reasonable. Examples include calculating the delegator status and how those status' are used, and any logic related to calculating unbonding and withdrawl amounts.
Currently the fact that a delegator is unbonding is tracked via the
and that the delegator struct removes
This design means that:
I need a little more feedback on solidity implementation details to know if the nested array of structs is a good idea within the delegator struct.
I also thought about an
This is a breaking change to the protocol. Clients will need to update in order to actually unbond.
Another option would be to add an overloaded
Copyright and related rights waived via CC0.
Here are some notes and additional thoughts from an offline discussion.
I'd be in favor of using a different name for the struct - in the interest of clarity and to make terminology clearer in discussions, maybe the name should be a noun such as
Another way to manage the locks is to use a mapping instead of an array. The updated data structures would then be the following:
Whenever a new unbonding lock is created
A benefit in using a mapping instead of an array is that it allows the addition of additional variables to the
We should also update the
Clients will be able to use these events to keep track of unbonding locks for users. There is room for client-side optimizations here to help a user manage a set of unbonding locks.
An implication of this design is that there would no longer be any notion of a delegator being in the
One observation made offline is that the concept of an unbonding lock can also be thought of as a contract issuing a single non-fungible token that has some denomination of LPT associated with it in addition to a withdraw round that dictates when the non-fungible token can be traded in for fungible LPT in the future. Let's call these non-fungible tokens BLPT (bonded LPT). We can take this idea one step further - the entire bonding process could be represented as delegators trading in quantities of fungible LPT into BLPT. Instead of delegators transitioning between the
I think it's when
I wonder if a delegator should be
I guess this would only matter if we actually remove them from the delegators mapping when we believe them to be unbonded. We would likely have to keep them around so that they could access their unbonding locks to withdraw.
Yep - fixed.
Yeah I think the original state transition logic I described was wrong. Updated the description.