Accounting V2: Delegations can not be re-allocated to a new orchestrator without unbonding period

[kyriediculous]

In streamflow it is possible for a delegator to move stake to another orchestrator without unbonding period. One restriction here is that the delegator would only start earning rewards and fees for the new orchestrator in the next round.

In confluence this restriction is no longer upheld (see #463 ) so in the current confluence implementation it is no longer possible to move stake from an existing delegation without going through the unbonding period first. It is the question whether we could like to allow this in some fashion.

One security concern because of removal of the restriction is that if a delegator is able to move stake around at will multiple times in a round he could potentially front-run reward calls and winning ticket redemptions from several different orchestrators in a single round, which would be considered gaining an unfair advantage.

One possible way to reduce the attack surface would be to introduce a cooldown period whereby a delegator can only move his stake once every N rounds (e.g. Only every other round).

[yondonfu]

The main downside I currently see with requiring unstaking in order to move a delegation to a different orchestrator is that it presents more friction and delays with managing delegations especially if a delegator wishes to split a delegation so that the stake can be used to create smaller delegations for a larger set of orchestrators. If the unstaking requires 7 days that's not that terrible, but if the period is ever extended then the experience would worsen.

One possible way to reduce the attack surface would be to introduce a cooldown period whereby a delegator can only move his stake once every N rounds (e.g. Only every other round).

Seems like this can largely address the problem since as long as the cooldown period > 1 round, a delegator would not be able to move its delegation to another orchestrator within the same round.

At first glance, the cooldown period would end up playing a similar role to the unstaking period, but I think the benefit of defining it as a separate parameter could be a better separation of concerns since the desired # of rounds to wait before moving a delegation can be different from the desired # of rounds to wait before tokens are unstaked (and withdrawable).

[yondonfu]

One way that I think the problem of re-delegated stake earning rewards from multiple orchestrators can be solved is by only adding rewards to the delegation pool in the next round. If stake is re-delegated, it will not be eligible for the rewards from the current round because the rewards will not yet have been added to the pool. As a result, only delegations that remain with an orchestrator until the beginning of the next round will be able to access the rewards minted in the current round. So, even if stake is re-delegated to multiple orchestrators in the current round, the stake will only earn rewards for the orchestrator that it is delegated to at the beginning of the next round.

I've sketched a prototype for this delayed earnings (for both rewards and fees) mechanism here.

[yondonfu]

Another way that I think the problem of re-delegated stake earning rewards from multiple orchestrators can be solved is via time based rewards as originally suggested here. An additional benefit of this mechanism not described in the linked comment is that it makes it easier to increase the duration of time between reward calls either if the round length is increased or if a multi-round reward period is introduced. If the time between reward calls is increased to more than a day then delegations would have stay with orchestrators for longer in order to guarantee earning rewards which would slow down the delegation market. Additionally, older delegations would potentially earn the same as newer delegations despite the older delegations contributing to the stake of an orchestrator for a longer period of time (this is already the case, but longer time between reward calls would make the impact more apparent). If delegations earned rewards based on time as well delegations could move around frequently while still earning rewards instead of risking losing out on all rewards and there would be fairer compensation for older delegations vs. newer delegations.

The formula that both rewards and fees would be based off is the one described in this liquidity mining blog post. The main difference is that we measure shares of a pool vs. total shares in circulation instead of liquidity vs. total liquidity. Additionally, for fees we keep track of a fee rate per second in addition to the reward rate per second that would be tracked for rewards.

I'm sketching a WIP prototype for this time based earnings mechanism here.

[kyriediculous]

I think delayed rewards is the simpler approach and works well for what we want to currently achieve and maintaining the existing behaviour of streamflow

I also agree that time-based rewards have the additional benefit of being more future-proof and allows for more fluidity. But I don't think it fully represents the behaviour we want to see. For example there would still be instant eligibility for fees albeit severely diminished even tho stake wouldn't contribute for that round yet.

I'm wondering if a combination of delayed rewards and time-based rewards is possible where we offset the time-based multiplier with the amount of blocks remaining for the current round

[yondonfu]

See https://github.com/livepeer/protocol/issues/463#issuecomment-937877745