Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delayed broadcasting of voluntary exits #7431

Open
nflaig opened this issue Feb 5, 2025 · 1 comment
Open

Delayed broadcasting of voluntary exits #7431

nflaig opened this issue Feb 5, 2025 · 1 comment
Labels
help wanted The author indicates that additional help is wanted. meta-feature-request Issues to track feature requests. scope-ux Issues for CLI UX or general consumer UX.

Comments

@nflaig
Copy link
Member

nflaig commented Feb 5, 2025

Something to note, we apply the same validation on the api as we do on gossip

export async function validateApiVoluntaryExit(

this is due to the fact that we publish it to the network immediately

await network.publishVoluntaryExit(signedVoluntaryExit);

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 #7379 (comment)

@nflaig nflaig added the meta-feature-request Issues to track feature requests. label Feb 5, 2025
@nflaig
Copy link
Member Author

nflaig commented Feb 5, 2025

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.

@nflaig nflaig added the help wanted The author indicates that additional help is wanted. label Feb 6, 2025
@philknows philknows added the scope-ux Issues for CLI UX or general consumer UX. label Feb 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted The author indicates that additional help is wanted. meta-feature-request Issues to track feature requests. scope-ux Issues for CLI UX or general consumer UX.
Projects
None yet
Development

No branches or pull requests

2 participants