Withdrawals tracking issue

[djrtwo]

Withdrawals (code name Capella) will be specified as three features:

1. Withdrawable 0x01 validators -> withdrawn (at epoch boundaries) and core withdrawal mechanism -- Withdrawals push #2836
2. 0x00 -> 0x01 withdrawal credentials change operation -- 00 to 01 cred change #2855
3. Partial withdrawal on amounts above 32 eth for 0x01 validators -- Partial withdrawals #2862
4. consider removal of withdrawn_epoch added in (1) remove withdrawn_epoch #2998
   • just utilize withdrawabl_epoch and zero balance to know if safe to re-use
5. consider deposits into withdrawn validators remove withdrawn_epoch #2998

[djrtwo]

My scratchpad notes I'm working off of
https://notes.ethereum.org/BHG6JUibQ8CNqpUeVHd1dw?edit

[hwwhww]

@djrtwo Should we add a task item of creating an EIP to handle WithdrawalReceipt?

[djrtwo]

yes

[arnetheduck]

Apart from the economic stuff, do we want to do something about the size of the validator list in the beacon state before pulling the trigger on this one? Those lists are becoming quite nasty to manage, specially with the multiple linear scans (quadratic if you do it the pure spec way, but linear with the right optimizations) that we do regularly.

[djrtwo]

@arnetheduck do you mean re-using indices?
The way this is spec'd allows for re-use but does not enable re-use

Or do you mean something else entirely?

[arnetheduck]

@arnetheduck do you mean re-using indices?

yes indeed - re-using, making the list sparse or any other approach.

[mcdee]

Is it worth attempting to optimize here before withdrawals are implemented, seems a little premature as we don't know how many exited validators there will be. Currently there are 869 out of 431,496 validators exited, or a little over 0.2%. I know that is the lower bound, but until we have some sort of idea of the real-world number we'd be doing a fair bit of work for what could be minimal gains.

Once capella goes live we should have some idea of the churn, which would help to inform the best way to approach reduction in size of the validator list.

[Where-2]

Lost Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Jacek Sieka ***@***.***> Sent: Tuesday, September 20, 2022 3:51:19 AM To: ethereum/consensus-specs ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [ethereum/consensus-specs] Withdrawals tracking issue (Issue #2758) Apart from the economic stuff, do we want to do something about the size of the validator list in the beacon state before pulling the trigger on this one? Those lists are becoming quite nasty to manage, specially with the multiple linear scans (quadratic if you do it the pure spec way, but linear with the right optimizations) that we do regularly. — Reply to this email directly, view it on GitHub<#2758 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AV4C5HRO5ZOSEXO5OR6HVODV7CRZPANCNFSM5JFYEUUA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[gigamesh]

Could someone point me to an ELI5 of how the withdrawal process will work for the end user? After reading the specs, its not clear to me how the priority is determined. EIP-4895 mentions the withdrawal "has no associated gas costs", but there is a max per block. So what determines who gets to go first?

[dapplion]

Could someone point me to an ELI5 of how the withdrawal process will work for the end user? After reading the specs, its not clear to me how the priority is determined. EIP-4895 mentions the withdrawal "has no associated gas costs", but there is a max per block. So what determines who gets to go first?

Full withdrawals: First come first serve
Partial withdrawals: Sequential order by index starting at 0