RPIP-71* will define how we select validators to exit for withdrawal liquidity, RPIP-73 does the same for underperformance. This RPIP is about what happens after a validator has been selected for exit by either. First, there will be a window for the node operator to exit the validator themselves. This could be automated by smartnode. After that, the protocol allows for triggering the exit.
A big decision point for the pDAO with this is how to handle minipools. The proposal makes the case that we should try to exit minipools and use penalties if it’s not possible. I realize that this could be controversial and am hoping to get pDAO input here.
*: There is still ongoing discussion in Discord about mechanics of RPIP-71.
“The protocol SHALL be able to request a validator to exit for underperformance (RPIP-73) or withdrawal liquidity (RPIP-71).”
Don’t think this belongs here, not in this form. I’d word it more generally: “The protocol SHALL be able to request a validator to exit if certain conditions are met. These conditions are specified in other RPIPs and not in scope here.”
And if I’m writing anyway, here’s a question:
What is the requested_eth variable used for, specifically. Because I’m asuming you don’t get to choose which validator to exit, you need to exit the requested validator. It would make no sense to request the exit of an underperforming 16 ETH validator and then two good performing 8 ETH ones are exited. So, if we know exactly which validators should be exited, why do we need to track requested ETH? Just for easy visualization of to-be-freed ETH?
requested_eth will be relevant for withdrawal liquidity exits. Very roughly, there will be a withdrawal queue where people can put rETH and we will need to decide if and how many validators to exit. Say the withdrawal queue needs 500 ETH and there is 400 ETH from underperforming nodes that has already been requested to exit, then we would only want to exit 100 extra ETH, not 500.
RPIP-71 will also track exiting ETH, which would include voluntary exits already in progress.
Very supportive of this. I think the penalty system is best, to at least remove the ostensible financial incentive to avoid ULD/upgrades. We really don’t have a great way to interact with minipools that are both not allowing the RP upgrades and simultaneously not following protocol rules.
We could think of some other manner of enforcement (eg smartnode generates presigned exits that trigger when exit of a validator is called and would only require internet connection rather than synced node, if for example a NO died/password lost etc), but they would probably all seem equally invasive. And folks (like SAAS) who are not utilizing smartnode are a potential source of failure, so aligning financial incentives with the RP protocol makes sense.
I think 72 hours is going to be challenging for folks where it’s not automated by smartnode. I think that expanding the cooperative exit phase by a few days would be reasonable (particularly as going from zero ability to exit to let’s say a week is markedly improved liquidity). Could consider doing an escalating penalty that goes linearly from -0.01 at 0 days to 0.1 at 28 days so as to reward folks who have missed the deadline but quickly exit, and to reward those who have figured a way to exit at 0 days rather than 2.9 days.
I know that there was discussion of preferentially exiting minipools over megapool validators. i don’t see that in here so i won’t expand on my thoughts but i would not support that.
Open to increasing the cooperative exit phase. The escalating penalty is an interesting idea, but at first glance seems difficult to implement. We don’t really know when a voluntary exit happens and the time ETH becomes available isn’t directly related to it.