I’m making this post to let the DAO opine before I unilaterally make some adjustments to v10 that I believe are in the spirit of the RPIP, but disagree with the letter of it. What follows will be a fairly technical explanation of why I want to make these changes, so if you aren’t interested in the minutia, feel free to skip to the poll at the end.
Bonus Commission
v10 adds the concept of bonus commission to rewards trees. Simply, bonus commission is calculated based on a validator’s RPL stake, and ranges from 5% to 9%, bringing overall commission for a leb8 up to 10% to 14%.
Of course, in order to accurately pay out this bonus commission, we need to apply it to the validator’s consensus income. The v10 spec does this by taking the balance of the validator at the beginning/end of its eligibility and subtracting them, and then adding in any withdrawals that occurred during the interval.
Balance Queries
In implementation, we discovered that balance queries are quite slow, on the order of 10-15 seconds per slot. This is because the BN has to reconstruct the state at the queried slot, which it does by taking the least-distant previous state and applying the intermediate beacon blocks to transform it until it represents the queried slot. Not only is this very slow (treegen takes hours), but it’s fundamentally incompatible with the way rolling records was implemented (which assumes composibility of all records). While it’s possible to refactor rolling records to support this workflow, it’s a lot of extra risk.
Is it even accurate?
So, if we can overcome the performance and implementation risks, is it even a good idea to use balance checks?
I am increasingly of the opinion that they are an inaccurate measure of consensus income. Consider the following timeline:
- Interval starts
- Validator A has a balance of 32.5 eth, no staked RPL, and is opted into the SP
- Interval ends
- Consensus Income is 0.5 eth, bonus commission pays the validator 10% on 24/32 from the SP, or 0.0375 eth.
- Before the validator is skimmed, it gets slashed.
- The validator exits with a balance of 31.5 eth. When distributed, reth gets back its 24 eth principle, the node operator gets back 7.5 eth in addition to keeping the 0.0375, which is essentially “stolen” from rETH holders.
It’s my stance that this is sufficiently unintended for us to revise the spec without a pdao vote.
Revision
The solution is conveniently sound. We will remove balance checks from treegen and consensusIncome will be calculated strictly from skimmed eth. Since skimmed eth is what ultimately enters the protocol, it’s a more accurate representation of the validator’s income.
This also removes the performance challenges from treegen, and makes rolling records fully composible without a major refactor.
Paths forward
There’s 2 options here-
- Sentiment agrees this is within the realm of discretion that I may exercise as the implementer of v10, we have time to implement this before 30 trivially
- Sentiment disagrees and we don’t derisk delivery substantially. A pDAO vote follows, and v10.1, if ratified, resolves this.
It’s my view that the fewest people will be upset if we make this adjustment unilaterally. If we miss delivery of interval 30, bonus commission will yet again not be paid to saturn 0 leb8s. If we make delivery, but DDoS the oDAO nodes, we expose ourselves to a certain amount of risk that they won’t complete other duties while thrashing their BNs with balance queries. If we make this adjustment unilaterally instead, it sets a precedent that such adjustments are within discretion, but I believe that precedent isn’t very strong, since it’s in the spirit of the goals of the RPIP.
Poll
Please vote on whether you believe this change should be adopted without a pDAO vote, or ask questions in this thread if you have them.
- This change is within the discretion of the implementer and should be admissible without a full pDAO vote
- This change requires a full pDAO vote
- I don’t understand this well enough to opine