Using a reward period to reduce the frequency of reward calls

Protocol
1

Background

As Ethereum gas prices have increased recently to as high as 200-300 gwei, so has the tx cost for calling reward.

This table shows the USD tx cost for the last 1000 reward calls. When the gas price is 300 gwei, the tx cost of calling reward can exceed $40. While the value of the LPT rewards minted by the reward call still exceeds the tx cost in most cases, the value that the orchestrator itself earns based on its rewardCut and its self-delegated stake may be less than the tx cost.

Consider the following reward call tx:

  • The orchestrator’s rewardCut is 25%
  • The orchestrator’s self-delegated stake represents 2.4% of its total stake
  • The reward call minted $127
  • The orchestrator earns $34.79 based on its rewardCut and self-delegated stake
  • The tx cost was $68 at a gas price of 325 gwei
  • As a result, the orchestrator lost $33.21 for this reward call

An orchestrator can avoid calling reward at a loss by increasing its rewardCut and/or increasing its self-delegated stake. Both strategies allow an orchestrator to earn more of the LPT minted in a reward call. However, the effectiveness of both strategies will continue to diminish as gas prices rise. This is not as big of a problem for larger orchestrators (in terms of stake), but can be a problem for smaller orchestrators especially as the inflation rate on the network continues to decrease.

Ideally, the tx cost of reward calls could be reduced such that even if gas prices rise, the rate at which an orchestrator might need to increase its rewardCut and/or increase its self-delegated stake to avoid calling reward at a loss would be slowed down (and hopefully in many cases this wouldn’t be required at all).

Moving the reward distribution system into a L2 would be one solution, but that is out of scope for this post (although it is an area of research right now). Instead, this post explores an update that could be made to the existing reward distribution system deployed on Ethereum mainnet.

Reward Period

At the moment, an active orchestrator needs to call reward every round which is roughly a day. As a result, the orchestrator pays the tx cost for calling reward every day. Instead, an active orchestrator could call reward every rewardPeriod rounds. Every rewardPeriod rounds there is a “reward round” where active orchestrators in that round can call reward to earn rewards minted for the last rewardPeriod rounds. In this scenario, an active orchestrator only needs to pay the tx cost for calling reward every rewardPeriod rounds. For example, if rewardPeriod = 7, then the tx cost is paid every 7 days which effectively results in a x7 reduction in reward call tx costs for an orchestrator.

A downside of decreasing the frequency of reward calls to once every rewardPeriod rounds is that if an active orchestrator is deactivated (i.e. the active set is full and another orchestrator accumulates enough stake to evict another orchestrator from the set) in the reward round then it will earn 0 rewards even if it was active in multiple rounds prior to the reward round.

Alternatives

An alternative to having active orchestrators calling reward every rewardPeriod rounds is to increase the roundLength parameter. For example, if roundLength = 5760 * 7, then the tx cost for a reward call would be paid every 7 days resulting in the same tx cost savings when active orchestrators call reward every rewardPeriod rounds. However, a downside of increasing the roundLength is that it also increases the time it takes to update the active set. The active orchestrator set is updated at the beginning of every round based on staking activity in the previous round. So, if roundLength = 5760 * 7, then the active set would only be updated once a week. As a result, there would be a long waiting period for a new orchestrator to activate on the network. The reward period based approach avoids this outcome because the roundLength does not need to change.

1 Like
2

is it possible to unstake without claiming my earnings?
the fees, if i claim are much more than my rewards would be.

3

At the moment, no, but it’s being addressed by https://github.com/livepeer/LIPs/issues/52, so if you sit tight for a couple weeks you will probably be able to access all your token + earnings without a high txn fee to do so. Let’s take any followup to that linked issued though, so this thread can stay focused on the rewardPeriod discussion.

4

Thanks for starting the discussion on this Yondon. A few thoughts:

  • In general, I think the negative impact of a multi-round reward period is pretty small at the moment, relative to the benefits of decreasing the reward call costs.
  • This feels like a parameter that can, and perhaps should, move fairly frequently as the network undergoes different scaling/congestion phases, with only a small impact to the user and node operator experience (barring any extreme values for rewardPeriod). You could even envision using some sort of oracle that adjusts it automatically within a range of acceptable values, rather than needing a governance process to adjust it back and forth every time.
  • With only ~50 out of 100 available O slots taken, it seems like it might be awhile before there’s enough competition for the active set amongst nodes with enough stake to make calling reward worth it anyway, so I wouldn’t worry too much about the chance for lost rewards if you get bumped within the rewardPeriod.
  • There is probably some more complexity than mentioned to this point in trying to maintain the exact inflation schedule/accounting versus using an approximation that only requires accounting at each rewardPeriod. TBD what the community would want to do on this front.

I also can’t help but notice that nodes with large amounts of stake/delegation can very easily cover the reward call costs with a low reward cut, but new nodes or nodes with smaller amounts of delegation would need a much higher reward cut to do so. Lowering the reward cut is the main way to attract delegation right now, so this would lead to even more centralization. My head is spinning with ideas around a mechanism to fund the reward calls for all active nodes with LPT from the inflation prior to distributing the rewards pro-rata based on delegation. Will follow up if it lands on something concrete.

1 Like
5

One solution could be to continue minting LPT each round during the reward period based on the current inflation schedule and then divide the LPT minted during the reward period amongst active orchestrators that call reward during the reward round.

The technical changes for this solution should be small and would involve:

  1. Mint all inflationary LPT for a round when it is initialized.
  2. Keep track of all inflationary LPT minted during a reward period
  3. When an active orchestrator calls reward during the reward round calculate its portion based on the inflationary LPT minted during the last reward period

One notable difference from how the current system works is that instead of having active orchestrators mint LPT when they call reward, LPT would be minted when a round is initialized. Previously, if an active orchestrator missed a reward call for a round, its portion of the inflationary LPT simply wouldn’t be minted. If based on the inflation rate, there could’ve been 1000 LPT minted, there may only be 800 LPT minted due to a missed reward call. Using this solution with this example, the 1000 LPT would always be minted and missed reward calls would not impact the amount of LPT that is minted.

6

A draft LIP has been created that uses the solution described in the OP. The draft LIP can be found here. Further discussion on the solution and the LIP should be directed to the LIP discussion issue.

7

Question: what are the downsides to e.g. changing the protocol parameters to:

RoundLength = 20160 blocks (5760*7/2)
UnbondingPeriod = 2

This would reduce the number of reward calls required, without needing to change any contracts (only parameters).

8

However, a downside of increasing the roundLength is that it also increases the time it takes to update the active set.

The downside is described in more detail in the “Alternatives” section of the OP.