AFIAK you would only have reduced RPL rewards if you are below the network average. So it wouldn’t be 100%.
Joe’s plan is good, and I would support it. It is ‘fair’, and any NOs who would be substantially penalized should be substantially penalized, and probably shouldn’t be running minipools at all. A 1% haircut for a 99% performing node doesn’t seem punitive at all to me, that’s a rounding error. The plan protects rETH holders in two ways: first, by providing direct incentives to run high performing nodes, and second by increasing the percentage of LEB 8/4 that are run by high performing NOs.
My main criticism is that it adds some complexity from a coding and explanation standpoint, and the harms it is looking to prevent are relatively minor. I don’t think a vote would be necessary if there was general consensus, although that test seems to have failed already.
The alternative laid forth by valdorff seems also to be a good plan, but comparatively adds far more complexity, may not offer more protection for rETH, and definitely would require a vote because of tokenomic changes. In this case, I don’t think the tradeoff is worthwhile.
Some back of the envelope numbers -
- Right now with RPL at ~.016 RPL/ETH, a 10% collateralized, perfect performing minipool would earn about .648 RPL per cycle. At 150% collateralization this would be about 9.72 RPL per cycle. So, highly collateralized minipools would be impacted more by each missed attestation. WIth 6300 attestations per cycle, that would roughly be a 0.000103 RPL for each miss on a 10% collateralized minipool or 0.001542 RPL for a 150% collateralized minipool.
I’m not sure if that disparity is a healthy thing or not. It might make more sense to just set each miss at a flat amount of RPL – maybe equivelant to what the penalty would be for the median collateral minipool?
- Last cycle there 411611 missed attestations amongst the 4874 minipools participating in the smoothie pool. Assuming (big assumption) that non-smoothie nodes perform roughly the same as smoothie nodes that works out to about 840K missed attestations every cycle for all operators. With about 10,240 gwei lost per missed attestation, that translates to about 8.6 eth worth of total losses per cycle, of which about 3.6 eth would be “owed” to rETH stakers.
With an average collateralization (on a per minipool basis) of 75% that would be roughly worth 0.0007725 RPL per miss, or about 648 RPL recovered to be redistributed amonst other node operators, or sold to compensate rETH stakers. That RPL would be worth 10.37 Eth at the current ratio.
I’d love to see these numbers firmed up and cross checked. Maybe a custom build of treegen that looks at the performance of all minipools? But I think we need some good, hard numbers to make good decisions about this.
Our ETH rewards already behave exactly like this. Anyone that cares to maximize rewards already has that as an incentive to maximize uptime.
My impression is that we are dragged down primarily by massive uptime failures, not by many small uptime issues. We have a thread tracking folks in our top 60 nodes by size under 90% effectiveness
https://discord.com/channels/405159462932971535/1029031967947231242/1052223238660431892. We see folks under 50% routinely. We see a person with over 200 minipools losing themselves more than 50 ETH/year due to carelessness. Uptime would be great if we can get it… but if we can’t, then we should protect our market competitiveness via reparations.
1 Like
Better performing nodes get better rewards already. The incentive would become higher with rpl reparations. Yes, with redistribution to other nodes it would be even higher. But there is no evidence that this is an incentive problem, that the incentives under reparations are insufficient or that incentives under redistribution are sufficient.
Without all of that, I am sceptical about the redistribution change being able to improve performance. The reparation approach basically guarantees a better outcome for rETH.
And yes, I think the auction approach would require contract changes. I believe a vote and audits are appropriate for this type of change.
1 Like
In a future LEB4 and beyond world, the effect of downtime is magnified for rETH holders. The person with 200 minipools Val mentioned could be screwing up 800 minipools instead. Behaviorally, it’s the same for the node operator, but the effect is drastically different. Instead of 3,200 stale ETH, there is now 22,400 stale ETH. The losses could add up and as long as each validator sits above 32 ETH, the rETH holders will inherit all the losses.
Fundamentally, I would prefer to change this such that losses are not socialized above 32 ETH. However, RPL reparations provide a way of redirecting existing value toward solving a problem. Ideally, rETH is protected in all cases by NO ETH and RPL rewards are distributed by performance. Realistically, I think that’d involve too much contract work and RPL auction and distribution would be simpler.
EDIT: Some problems with the auction method. What to do about very small auctions? If a single minipool node was down for a month in which no sync committees or proposals happen, the costs associated with an auction would likely make the system too inefficient. Too few bidders for small token sizes, especially in bull market conditions where gas is an issue. One way to get around this could be a debt system. In cases where the losses are small, rewards are deferred from the node operator until rETH is made whole. At a certain debt size an auction would be triggered for the staked RPL.
1 Like
Let’s do out a scenario to think through if they move the needle.
I’ll assume 60% RPL collateral for everything.
Base boring scenario: everyone 100% attestation
- Current: x per minipool, y rETH APR
- RPL shuffling: x per minipool, y rETH APR
- Reparations: x per minipool, y rETH APR
The key thing here is that all options are identical
Test scenario: 5% of minipools are pretty bad and miss 30% of their attestations
- Current: x per minipool, y rETH APR
- RPL shuffling
- 1.036x per good minipool
- 0.7x per bad minipool
- 0.965y rETH APR
- Reparations: x per minipool
- x per good minipool
- 0.7x per bad minipool
- y rETH APR
Let’s look at the impact on APRs. I’ll use ballpark reasonable numbers of 7% ETH APR (counting commission) and 8.5% RPL APR.
First the good minipools (shuffling):
original_apr = (16*.07 + .6*16*.085)/(16 + .6*16) = 7.56%
new_apr = (16*.07 + .6*16*.085*1.036)/(16 + .6*16) = 7.68%
Do we really expect significantly different NO behavior for 0.12% APR? I don’t. So I don’t think having this or not changes how our good folks act.
Now the bad ones (shuffling and reparations):
original_apr = (16*.07*.7 + .6*16*.085)/(16 + .6*16) = 6.25%
new_apr = (16*.07*.7 + .6*16*.085*.7)/(16 + .6*16) = 5.29%
From the hypothesized state of affairs, we know these folks won’t act to go from 6.25% to 7.56% (1.3% delta). Under reparations, would they act to go from 5.29% to 7.56% (2.3% delta)? Under shuffling, would they act to go from 5.29% to 7.68% (2.4% delta)?
I believe the set of folks that would act for a 2.4% delta and a 2.3% delta are essentially identical.
And lastly rETH (reparations):
original_apr = (.07/1.15)*.85*.965 = 4.99%
new_apr = (.07/1.15)*.85 = 5.17%
Honestly - this number won’t move the needle imo. What will move the needle is saying that bad performance by NOs is covered by NOs and rETH is protected.
In short:
- Shuffling doesn’t bring enough extra profit to act as a reward incentive vs reparations
- Both act as reasonably strong disincentives
- Reparations lets us say rETH is protected from bad NO performance, which is fantastic for market competitiveness (eg, Lido can’t say this).
1 Like
Lots of great discussion. I want to replay a suggestion I’ve made before–the smartnode stack should come with notifications out of the box.
Incentives are an important factor in getting NOs to have good uptime, but they aren’t the only factor. Make it trivial for NOs to get emailed when their node has issues and I bet you see much better overall performance without changing the incentives.
5 Likes
Weekly ‘performance’ summary emails might be useful too, with breakdown -
- Missed attestations
- Wrong source/head/targets
- Late attestations
And then some performance diagnositc tools that can help operators identify where things are having a problem. Slow disk iops? Insuffiscient internet bandwidth? Unstable internet? Peering problems? Port forwarding not working?
That kind of thing would probably do well as a GMC bounty for a set of smartnode addons.
1 Like
I think the core issue is that folks that are willing to use tools (eg, beaconcha.in alerts) aren’t the folks with the major issues anyhow. I like @Dondochaka’s idea of including it out of the box, maybe even having it be (slightly) annoying to skip.
1 Like
Is there any way of knowing how many missed proposals there were? The cost to rETH stakers could well be more than the 3.6 ETH mentioned, especially if these network performance losses were extrapolated across all RP node operators.
The concept of ‘reparations’ is selling RPL to artificially subsidise rETH APR, this is not confidence inspiring and was rightfully dismissed the last time it was suggested as poor economics.
1 Like
I’m not following? What’s artificial about it? It raises rETH APR to what the level would be if all of our NOs were operating well. This need not be 100%; I’m currently aware of an NO with 64 minipools at literally 0% effectiveness. It’s unclear to me why rETH should be punished ahead of the NO at fault. It’s even less clear why, if we punish the NO at fault, the payout should go to other NOs instead of to rETH.
The miss rate in the smoothie pool is 1.41%. Rated.network shows about 1.3% by their metric. I’ll use 1.35%. (shoutout to yokem for those numbers) We’ll use that miss rate as a proxy for missing value of all kinds - block proposals, mev, sync committees, attestations.
The rETH peg at the beginning and end of last rewards period were 1.0431 and 1.0483 respectively. There were about 150k rETH in existence in that period - using a round and constant number to keep it simple.
actual_gain_factor = end/start - 1 = .00504
ideal_gain_factor = (end/start - 1) * (1/(1-.0135)) = .00511
ETH_lost = 150k * (ideal_gain_factor - actual_gain_factor) = 10.35 ETH
Probably better to just think of it in terms of missing 1.35% of rewards than absolute numbers tho.
It is obviously preferable that a NO suffers the consequences of a poorly performing node before rETH holders, in the case of what is proposed we can choose to reduce RPL rewards to such a NO with minimal changes.
If you choose to do so you now have surplus RPL, what you decide to do with it is a separate issue. I don’t see why there is a stronger case for using such funds to increase rETH APR in this scenario rather than at any other time. If this was desirable there would be an argument for reducing inflation to NOs to redirect it for this purpose.
Directing the extra RPL to other NOs is consistent with it’s intended purpose along with providing additional incentive for nodes to perform well and again requires minimal changes.
1 Like
I don’t think it will be minimal, as v2 of tree gen is showing. The incentive difference is minimal as valdorff has pointed out above. I would not expect behavior change based on it and at that point I think it would be better to keep things as is and let Joe focus on something more productive.
2 Likes
A poorly performing node harms rETH APR, as the penalties and missed income are socialised between the NO and rETH. This is not in line with Rocket Pool’s general philosophy of the Node Operator being on the hook first for performance.
I think using a portion of RPL rewards here to ‘repair’ rETH makes sense and closes this long existing gap between the protocol as advertised and reality. It also adds a valuable use case to answer to ‘why RPL’ questions.
It doesn’t really make sense to scale reparations with the NO’s RPL stake though. It should be more in line with (a proximate value for) the actual damage caused by attestation misses etc.
Also, I’m in favor of a treshold before penalties kick in. Even if ‘near-perfect’ performance would result in very small penalties, there’s still a psychological effect which could discourage slightly worse performing minority clients. We’re already seeing this effect now, with just the minor difference in ETH attestation rewards, and I’d rather not see more people switching back to a majority client because they’d also be getting (slightly) less RPL rewards.
4 Likes
This would make sense if it was the node operators staked RPL required with the stated purpose of insurance, however before it is rewarded to a NO this RPL is an expenditure of the protocol as a whole.
I believe responding to ‘why RPL’ with ‘it is minted then systematically sold to boost rETH APR’ would not be a reassuring answer to that question.
Of course we are talking about small values and I do agree with @knoshua that there are more important things to spend time on.
I’m in favor of using staked RPL from poorly performing nodes to make whole rETH investors. There is little difference to my mind in using RPL collateral for that purpose than when the validator is slashed for poor performance. However given that this is a change to the current operating rules I concur that such a policy should be the subject of an RPIP and voted on accordingly.
In the meantime I do believe that highlighting poorly performing nodes using the statistics from rated.network could be a good way of bringing node performance to an NO’s attention when they may not otherwise be aware of the situation. In that way they at least cannot claim to know nothing about it.
Following that logic it makes sense to celebrate NO’s doing an excellent job perhaps by publishing a leaderboard on Rocketpool Explorer. I believe that if we have NO’s doing better than those of Lido or the so called professional NO’s then Rocketpool should highlight this as widely as possible.
This PR opportunity becomes invaluable when SAAS becomes available as RP needs all the tools at its disposal to show that we are not just a bunch of amateurs. Any institution wanting to invest with a RP based SAAS will do due diligence and approval may well rest on ticking the NO credibility box.
Finally in much the same way as the Rescue Node is being promulgated for emergency situations I would like to see its services extended to facilitate an NO being able to ask for (or have it strongly suggested to them) a check mechanism being available to help them optimise their node performance. Rocketpool’s overall performance on rated.network is not that good and I suspect that we need to improve our quality control if we are to avoid the non professional tag as a group.
Ok, there has been a pretty significant amount of feedback on this proposal. What I have gathered is the following.
Parts that do not seem controversial, which people either agree with or haven’t commented on:
- Switch from node-based rewards to minipool-based rewards
- Prorate RPL rewards for minipools based on their activation time and their exit time (i.e., an exited minipool will no longer earn RPL rewards)
More complex ideas that have generated some debate:
- Prorating RPL rewards based on node performance
- Who ends up getting the RPL taken from poorly performing node operators
- In the case of being given to rETH holders, the mechanism for getting it there
- Whether or not there should be a “grace window” where anything above 90% effectiveness gets full rewards, and what the value of that window should be
- Alternative methods for incentivizing good node operators
- Notification systems in the Smartnode
- The development costs associated with all of the above
I do think it’s important to sunset RPL rewards for exited validators prior to Capella, because I don’t want people sitting on exited validators and collecting RPL with the ability to withdraw at any point since they’re exited already. Now that the watchtower is responsible for distributing RPL instead of the smart contracts, this logic needs to be incorporated into the rewards spec for it to apply.
With that in mind, what makes sense to me is to fork this discussion into two things: a “short term” iteration which does the first two things and targets the original date of Interval 6 (February 22), and then a much larger, longer discussion around the latter points involving an RPIP and number crunching and analysis and stuff.
How do you guys feel about that plan?
5 Likes