Withdrawals tracking issue

[djrtwo]

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

1. [x] Withdrawable 0x01 validators -> withdrawn (at epoch boundaries) and core withdrawal mechanism -- #2836
2. [x] 0x00 -> 0x01 withdrawal credentials change operation -- #2855
3. [x] Partial withdrawal on amounts above 32 eth for 0x01 validators -- #2862
4. [ ] consider removal of withdrawn_epoch added in (1) #2998
   • just utilize withdrawabl_epoch and zero balance to know if safe to re-use
5. [ ] consider deposits into withdrawn validators #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 iOShttps://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 GitHubhttps://github.com/ethereum/consensus-specs/issues/2758#issuecomment-1251347998, or unsubscribehttps://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

[Where-2]

I’m lost not sure what’s happening. Can u help

Get Outlook for iOShttps://aka.ms/o0ukef

---

From: Jacek Sieka @.> Sent: Tuesday, September 20, 2022 5:29:10 PM To: ethereum/consensus-specs @.> Cc: Subscribed @.***> Subject: Re: [ethereum/consensus-specs] Withdrawals tracking issue (Issue #2758)

@arnetheduckhttps://github.com/arnetheduck do you mean re-using indices?

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

— Reply to this email directly, view it on GitHubhttps://github.com/ethereum/consensus-specs/issues/2758#issuecomment-1251951262, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AV4C5HSN4226OS4K7CZSQCTV7FRUNANCNFSM5JFYEUUA. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[Jiggnubs]

Whatever is specified but to avoid newbies like me, include an dummy note walk-through would help speed the process up a bit. To also answer what new quest arises. I am frank to say, pairing abilities without cost or cause but back to basics what is pure simple. Can some body recite the alfabetical randomly always at any given time? Or tell my goosebumps to wave at your command? Remember good always prevails and being bad at everything gives perfect a sense to humor. Thank you for quick response dear One... don't hesitate on my weirdness, I'm just like another conscience?

On Mon, Sep 19, 2022, 1:12 PM Danny Ryan @.***> wrote:

@arnetheduck https://github.com/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?

— Reply to this email directly, view it on GitHub https://github.com/ethereum/consensus-specs/issues/2758#issuecomment-1251373420, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYWK4GQKSCRUFU5YS4Q5LODV7CUKPANCNFSM5JFYEUUA . You are receiving this because you commented.Message ID: @.***>