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.
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.
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.