Hi langers,
(You can jump to the bottom for the questions, but I’ll start with the context):
After some further discussion with @knoshua in #trading near ~here, to here, I would prefer to optimize for keeping things as simple as possible, and expedite forced exits for rETH withdrawals in Saturn 2. I don’t think we should expect most NO’s to be meaningfully impacted by withdrawals unless the protocol is experiencing significant downsizing/winding down - but in that case most NO’s are likely to be impacted anyways and priority selection shouldn’t make a large difference as most are eventually exited. The goal with UARS is that we should be able to better manage supply vs demand dynamics, and with megapools the cost to recreate the validators after being exited shouldn’t be a huge deal.
In practice I think the most straightforward implementation would be random selection, as it seems the most “fair”. I think it could still be helpful to categorize megapools by: “small” and “not small” and exit randomly from “not small” first, and only exit from “small” if there are not any “not small” megapool validators left. (I’m defining small/not small in the same way as my previous post/current rpip71 as of today). I don’t think the “sort from largest to smallest” within “small” would be necessary as I would expect it to be a rare scenario anyways to exit from “small”.
I plan to delete most of the details I had added to rpip71 to simplify it so that there could be a vote for inclusion in Saturn2 and the research/implementation details could still take place in parallel.
On another note, the other feature I would want to prioritize for Saturn 2 inclusion would be a basic form of “rETH protection”, where significantly under performing megapool validators would be force exited. This could be a stepping stone toward “rETH restitution” (where rETH is made whole from penalized NO’s for their underperformance prior to them being exited). For nodes that are fully offline / causing significant drag on the protocol we could at least start with “rETH protection” by at least exiting them before they incur significant costs on rETH. I think this feature should be simple and feasible for Saturn 2. I think this should be an independent mechanism from withdrawals, and would warrant it’s own RPIP.
TLDR:
I was curious what the teams feedback would be on implementing these two items in Saturn 2 (forced exits for rETH withdrawals, and rETH protection)? At what point would Saturn 2 scope have to be frozen to avoid delays in Saturn 2 release? Does the team find these two items feasible to include in Saturn 2? Would it meaningfully improve the schedule if the GMC were to fund research and spec work in parallel for these two items similar to the rest of the Saturn RPIPs? At what point would the specs need to be completed to avoid delaying the team’s dev work on Saturn 2 if this work were to happen in parallel?