Today I would like to kick off the discussion for v3 of the Rewards Tree spec. This is an amendment to the v2 rules that the Oracle DAO must follow when constructing the Merkle Tree that assigns RPL and Smoothing Pool rewards to each Rocket Pool node operator.
Proposed Changes
This proposal includes 1 high-level change to the spec:
Beacon Chain performance and minipool activation / exit dates are now applied to RPL rewards.
Currently, RPL rewards are handled very differently from Smoothing Pool rewards; they are handled on a per-node basis (rather than a per-minipool basis), they are only prorated based on the node’s activation date, they are not affected at all by the minipool’s activation / exit date, and they ignore the minipool’s attestation performance. This leads to many situations where nodes earn more RPL rewards than they ideally “should”. For example: a slashed minipool or an offline minipool still earn as many RPL rewards as a fully active attesting minipool, even though they are not contributing towards rETH’s growth.
In this proposal, RPL rewards would be calculated almost identically to Smoothing Pool rewards. To be more specific:
RPL is now calculated on a per-minipool basis, rather than a per-node basis, based on the total amount of minted RPL that goes to node operators for collateral (analogous to the way the total balance of the Smoothing Pool is divided per-minipool)
The RPL rewards eligibility window begins at the slot when a minipool is activated on Beacon, and ends at the slot when a minipool is slashed or exits Beacon (similar to how the Smoothing Pool works, minus the opt-in / opt-out variables)
RPL earnings per-minipool are weighted by their attestation performance (using the same calculation as the Smoothing Pool’s attestation performance subroutine)
RPL rewards are further weighted by the node’s effective collateral divided by the total network effective collateral, as is done today
Unlike the Smoothing Pool, commission is not factored into this calculation.
Implementation
[Reserved for when a candidate implementation is complete, based on the final spec decision]
Activation Timing
In order to allow for enough time to collect community feedback, iterate on the design, implement, and test the changes (as well as allow extra time for the end-of-year holidays), I propose that these changes would go live on Interval 6 at 2023/2/22 05:35:39 UTC which is 10 weeks away.
So if I understand this correctly, this won’t increase rewards but rather say “hey, if you’re not doing your duties (because you (were) exited or because your node is down) then you get less rewards”.
Making sure I follow the v3 formula (ignoring activation timing):
The current system goes something like this:
If my node has effective collateral of 1000.
And the network effective total is 10000000.
Then my portion today is 0.01% of the RPL inflation that goes to operators.
The change is to add performance scores:
Pretend the network average performance score is 90%.
And pretend my minipools’ average performance scores is 95%.
So now my effective-share gets weighted down to 950.
And the total network effective-share gets weighted down to 9000000.
So my portion would increase to 0.01055%.
This makes sense because I’m performing better than the network average.
If I understand it correctly the proposal is to effectively incentivize operators to do their duties and not neglect their nodes or in other words to have a fairer RPL distribution.
If that is so than I like it.
Sorry I’m gonna be a contrarian here… but I disagree with this quite significantly.
First the bit I’m ok with.
Counting earnings per minipool, and only for the period when active is perfectly fine. It might be a little tricky to implement…
Consider I have one minipool, missing 30% of attestations, and 30 ETH of RPL collateral. Halfway through the period I add another minipool. My performance from here is pristine. What’s the correct amount to pay out? It should be .7*.5*(share for 24 ETH) + .5*(share for 30 ETH) – the spec isn’t clear enough to tell if this is what happens.
Ok. On to the bits that I think need a vote.
RPL rewards have never been linked to attestation performance. This is new. I think there would be support for it, but it’s a real change and I think it should be voted on.
Assuming we take away some RPL rewards for bad performance, who should benefit? To me, the logical answer is the damaged party - rETH holders. This proposal instead benefits other RPL stakers. I see no logical reason for that.
Possible method: the RPL reparations are sent to a multisig (a management committee with a revenue source other than inflation!). That multisig buys rETH and burns it. This increases the value of rETH to make up for the losses from bad NOs.
Assuming we take away some RPL rewards for bad performance, how much should we take away? If someone holds more RPL, they do not damage the protocol or rETH holders more, so I don’t think it should scale with amount of RPL held (as proposed here). Instead it should be related to the value lost by missing attestations. I think we have all the necessary components to figure this out: the smoothing pool gives us a great sample for ETH/attestation on the EL, we could figure out something along those lines for the CL, we have the number of missed attestations, we have an RPL/ETH ratio.
I agree with you that penalties should be used to recompense those harmed, I think thats a fantastic alternative to enriching the bags of other RPL holders whom are otherwise unaffected.
As for how much, one might consider the true value of damage done, or 0.0001Eth/miss - however I’d argue thats a bit too strict and that there should be either a cap or % such that the penalty from RPL is lesser than the penalty of missed eth.
A minimum threshold. There should also be a minimum threshold for missed attestsations. Perhaps giving a minimum threshold of something like 5% attestation miss. This would also simplify the calculations greatly as I’d imagine a large % of missed attestations are actually the rare misses or small outages taken. The idea should be more to discourage going offline for extended periods of time, and not punish node operators who are likely already having a stressful time attempting to recover their node(s).
Very detailed and thought out response, Valdorff! I absolutely love the idea of reparations to the rETH holders (despite my personal desire to increase my own holdings) and I think this is the choice that carries the best ethical choice for the protocol.
I also think a vote is the correct action to take in terms of the change related to attestation performance.
I would like for us to do some modeling to understand what the implied impact would be to both the average user as well as an extreme (not 0%, but let’s say 1 standard deviation and 2 standard deviations on both sides of the avg performance).
On the side of realism, I don’t think NOs will vote to potentially reduce their own holdings. Still, I think this is the appropriate choice for us is to hold a vote on that particular bullet point.
I may offer one sort of alternative to put in with the vote: allow some deviation from avg. performance w/o penalty as we can’t and shouldn’t expect that node operators perform perfectly all the time. Though, if we’re measuring against average pool performance, this likely just averages out with the rest of the group.
Anyway. I think you’ve stated it all quite well and I agree with your stance.
Perform better and earn more as a node operator, yes.
rETH holders, in the long run, will find more value from higher performing nodes/minipools than from indirectly receiving RPL rewards. I believe that directing RPL rewards to rETH holders is a much bigger change than slightly rebalancing how those RPL rewards are distributed to those who stake RPL as a node operator.
rETH holders benefit when node operators are incentivized to perform better.
If we don’t care about measuring well, it’s really not. Rather than calculate the “penalty” and don’t provide it, provide it to a multisig. Same exact math.
If we want to measure the damage caused and account for that, then yes - that’s more challenging.
Agreed that there should only be a penalty below some threshold, e.g., less than some predetermined value, such as < a 95% attestation rate, or N standard deviations from the average attestation rate for the current period.
I also agree that rETH holders should be the direct beneficiary instead of NOs.
It seems overly punitive in its current suggestion state.
RPL staking has been purported to be the “entry price/ticket” to access staking using <32 eth. It is currently incentivised that by being a Node Operator with Rocket Pool you access RPL rewards and staking rewards and commission. These positives remain unchanged.
But now you are suggesting a metric whereby in its current iteration anything less that 100% uptime results in RPL inflation reduction that by its price alone is significantly more punitive than the eth lost by missed attestations.
If the aim of this suggestion is to ensure rEth is not negatively impacted by poor NO performance, then a metric that doesn’t punish NO’s significantly more than the reduced reth return would be preferred. Suggestions such as a “leeway” of 5-10% before punitive measures kick in would be worth considering.
Summary, reducing RPL rewards immediately from 100% uptime is too punitive in comparison to the harm done to rEth
I’m in favour of attestation weighted RPL rewards, though I do agree that any changes to the rewards system should have a vote.
We currently have some under-performing nodes that are acting as a drag on our overall performance and reflects badly in comparisons between other staking providers.
Of course no one running a node wants downtime or poor performance so whether attestation weighted RPL rewards would have any significant impact is an unknown.
At the very least it should increase user awareness of their nodes performance as a factor, this is why I disagree with a mechanism to funnel any additional rewards to rETH.
Node operators would be far more motivated to work to improve their performance if additional rewards are a possibility rather than simply the negative consequence of reduced RPL rewards, the carrot is always more effective than the stick.
This is a both an elegant and more direct way to improve rETH APR without adding inefficient auction/buyback mechanisms.
I don’t think this would be overly punitive though a less than perfect maximum (say 98%) would be reasonable, 95% is fairly poor performance and would render this of limited use.
Hey everyone, here are my thoughts on some of the fantastic discussion.
RPL reparations
I like the idea that we make rETH holders whole through reparations but there are a couple of considerations.
Firstly, RPL reparations do not incentivise the network to self-heal. We should be rewarding node operators that are above the average attestation rate. As a network, this creates an incentive to have great uptime. Although uptime is not as important as decentralisation - it is important to our market competitiveness.
Second, the solutions so far have significant trade-offs. The management committee (MC) adds a manual step that should not exist. Ideally the protocol should be automatic. MCs are really there when human decision making cannot be avoided. Using the auction system is great in theory but adds significant complexity (probably contract changes).
Uptime forgiveness
As I mentioned above, I think it is fair to expect home stakers to lose a little uptime. The network average will naturally reflect that. Although we should be incentivising node operators to maintain as high an uptime as possible - it is important to be competitive with centralised providers.
