With the recent challenges around the creation of the RPL and smoothing pool rewards merkle trees, it is desirable to look at optimizations around improving the treegen performance. One possible way to do this that does not require adding any new statefulness or caching to the generation process would be to reduce the rewards period time. A shorter interval should mean that the consensus layer attestation performance evaluation of every minipool participating in the smoothing pool could be completed faster. A reduction from 28 days to 7 days could accomplish the goals of improving the rewards tree generation performance substantially.
Currently the rewards period is over 28 days. Historically, this period was necessary because under the legacy RPL rewards claim system, the rewards had to be claimed by every operator, every cycle. Given the gas intensiveness of the claim, more frequent claims would have been inefficient and possibly even not worth it for smaller operators. Thus the rewards period was extended from 14 days to 28 days.
However, with the current ‘Garlic Bread’ merkle rewards claim system included in Redstone, claims can now accrue from cycle to cycle, nearly indefinitely, and are much more efficient to execute while claiming multiple periods at once. Thus it could be reasonable to reduce the rewards period again to a shorter interval.
The PDAO shall update the rpl.rewards.claim.period.time setting to a value equivelant to 7 days.
There would be somewhat better security since each rewards period would have a smaller amount of value at risk to be mis-allocated from a malformed merkle tree.
It would open opportunities for more ODAO members to participate in the tree generation process.
There would be more opportunities to upgrade the tree geneneration process with less lag between development and being live.
The flow of liquidity from the smoothing pool to the rETH contract would be somewhat smoother, as there would not be as large of a lump sum showing up every 28 days.
There would be a marginal increase in gas costs to operators that don’t claim as often. Each incremental claim period adds approximately 7000 gas to a claim transaction. Thus an operator that had been claiming every 28 days, would have an additional cost of about 21,000 gas to continue claiming at that interval.
The performance improvements may still end up swamped by minipool growth. As the number of minipools grows (as we hope) the improved performance from the shorter cycle may end up being outpaced. That said, the merkle rewards V5 specifications is said to be subtantially more performant on its own.
The smoothing pool opt-in and opt-out cooldown timer is linked in the contract code to the rewards period timer. Shortening the rewards period also shortens this cooldown.
The RPL unstaking cooldown after a stakeRPL() for operators that can withdraw excess RPL collateral is also tied to the rewards period. Shortening the cycle also shortens the cooldown.
Per RPIP-4 this proposal includes an informal sentiment poll to determine there is ‘Promising Community Sentiment’. Feedback and critique of this proposal is welcome ahead of drafting a formal RPIP.
Leave the rewards period interval at 28 Days
Change the rewards period interval to 7 Days
Change the rewards period interval to some other time frame (please explain)
You can read about the rewards v5 specification here -
And the actual specification here -
The key performance hangup is that for smoothing pool rewards, the tree generation process has to figure up the attestation performance for every minipool particpating. That means looking at all 7500+ attestations, for every epoch, over the 6300 epochs in a 28 day period. As the number of minipools participating in the smoothing pool increase (which we all hope will happen), the processing time to determine that attestation performance will increase at a linear rate at best. Right now, unless you put the whole beacon chain into ram the way the lighthouse folks do it, this is a 2+ hour process. With double the minipools, this timeframe also roughly doubles. Given community angst around how long this takes now under the best circumstatnces, it might be worth looking at managing the processing time by chopping the time interval up. If folks are comfortable and expectations are well managed about this taking longer and longer as we grow, then this proposal really isn’t needed.
The only other obvious optimisation would require statefully caching the minipool attestation performance over the whole period. This works to great effect (I beleive Rocketscan does this for its’ rewards previews), but can add some trust assumptions that the data hasn’t been tampered with after it’s been logged.
The oDAO issues this last time around require changes on the oDAO side. More own archive nodes - some of us were already running those. The current discussion is that running an archive node becomes mandatory for oDAO members, instead of a voluntary nice to have.
And scheduled treegen tests ahead of the rewards interval to catch potential client bugs or infra issues. Making those mandatory would also make sense to me.
That can be handled with communication I think. Just set expectations that rewards tree generation takes 2-3 hours now and may take longer in future. As long as the tree gets generated within 12-24 hours, that seems entirely reasonable to me.
V5 speed-up certainly is welcome to keep that time down. I don’t see a strong economic reason to squeeze every last minute out of the process, though.
I think it is safe to say that this proposal does not enjoy “promising community support”. And it should be noted that Patches has worked up some very promising and impressive improvements to the treegen processing time that hopefully will be upstreamed. In addition JCRPT has indicated that futher improvments by caching the attestation performance in the watchtower live memory are likely to be forthcoming. With these improvements, this whole proposal is moot.