Delayed broadcasting of voluntary exits
Something to note, we apply the same validation on the api as we do on gossip https://github.com/ChainSafe/lodestar/blob/06831cfc79ab667f4ce4ee897320ce3f4a495854/packages/beacon-node/src/chain/validation/voluntaryExit.ts#L7
this is due to the fact that we publish it to the network immediately https://github.com/ChainSafe/lodestar/blob/06831cfc79ab667f4ce4ee897320ce3f4a495854/packages/beacon-node/src/api/impl/beacon/pool/index.ts#L185
but something we could consider is that we separate out some transient checks which would become valid eventually, there are like 3-4 of them and post-electra we add another one which checks that there are no pending withdrawals. Meaning we would keep the volunary exit in the cache and publish it to the network only after those conditions are met.
As this has worked like this since phase0 it seems like no issue but something to consider to improve UX, on the other hand I can also see that accepting the voluntary exit but not publishing it immediately might be confusing as well.
Originally posted by @nflaig in https://github.com/ChainSafe/lodestar/issues/7379#issuecomment-2602912610
Feedback from discord
The --exitEpoch by contrast is for setting up an automatic future-dated withdrawal, especially for more closely aligning the exit to the upcoming withdrawal sweep.
Broadly, I kind of would've expected there to be an "exit pool" in much the same way as there's a transaction pool, with exits just loitering there until they meet the transient conditions to be consumed and acted on. In that model, submitting a future-dated exit would behave much the same as submitting a transaction with too low of a basefee; it'd just hang out until it could go. Ofc you'd need commonsense restrictions on how far in the future the epoch was for something to be added to the pool, to prevent attacks from wasting space in that pool.
can you please assign this issue to me?
Can I take up this issue?