This RPIP would mean that the second stake for a validator can happen shortly after the first, removing the need to go through the Beacon Chain Queue twice.
In the Saturn 2 scoping thread we talked about wanting to monitor how validator queue evolves over time. So far, it dropped to ~45 days in late April and is currently back over 60 days again (see validatorqueue.com).
I think the high-level question for the pDAO with this one is: Do we think this will be an issue long term and is it important enough to include the RPIP in the next upgrade?
When this issue does come up, it is a major pain to deal with. Doing nothing and hoping is not worth it, imo. We don’t want to end up in the situation where we want to and are able to shove more megas through but cannot do it for half a year while we wait twice through the queue.
I am all for including the RPIP in the next upgrade.
To play devil’s advocate, the argument for delaying it might be that the other Saturn 2 RPIPs are even more impactful and including this one would cause Saturn 2 overall to take longer.
Yes. It would certainly depend on how much it delayed the rest of Saturn 2. A couple weeks, fine with me. A couple years, not fine. In between, gray area. More or less.
i think include with the next upgrade. it’s going to be such a drag on APR and also significantly affects our liquidity situation (assuming that TVL oscillates down and up, and not just down). Like we could definitely get to a situation where we have validators waiting in entry and exit queues concurrently. It also disrupts the clear evaluation of risk/benefits of migrating to megapools, because even if the queue looks good when you stake it could rise significantly before your second stake.
I don’t know if it will be an issue at this level in the long term, but even if the queue is only an extra 10 days that’s essentially our expected exit threshold for poor performance (90% at 100 days).
This is assuming there is a relatively straightforward and safe fix. I have no comment currently on the actual proof and will delegate that trust.
This oversight has caused the Saturn 1 launch to be much more painful than needed and less immediately impactful than it could have been. At the time of writing, 3 and a half months after, the entry queue is still significant at 57 days.
We cannot predict what the entry queue will look like in the future, and thus cannot rule out this will become an issue again later on. Because of the significant impact it has on all but the smallest queue sizes, I think this is worth doing in any case.
The only question to me is when to include it. I don’t have a good grasp on the complexity and effort required. I’d like it to be candidate for inclusion for Saturn 2, with lower priority than other items. Possibly raising priority if the cutoff for Saturn 2 gets closer and the entry queue is still significant. And otherwise including it in the next release after Saturn 2.
The team is in a better position to talk about effort, but my sense is that on the smart contract side it is manageable and a good bit of the work will be on the smartnode side to support the proof generation.
The case for having this in Saturn 2 are the underperformance exits. If we are expecting to churn through ~10% of active validators to improve performance, it would be quite costly to have those validators not staking for an extra ~2 months.