Discussion topic for EIP-8061
The validator arrays aren’t great to iterate now, which kind of remains un-addressed, so going to an increased churn may exacerbate that problem again - its less about active validators and more about the size of the array because we iterate it so often (several times at epoch transition).
If we addressed that array structure it’d potentially become academic, either through reuse or allowing us to have a sparse array or something, haven’t thought through exactly but the max index at time of writing on mainnet is 2122156 (over double the number active now)
I do think we should have an open discussion about whether we really need to maintain the separate consolidation path long term, it seems like we’re better off not fragmenting the exit queue and creating an uneven playing field. That is probably better as a separate eip, but arguably may make this eip very different if theres one exit path and no consolidation to consider.
Just to capture side chat
- talked about retaining the deposit cap
- talked about why we want separate consolidation, and makes sense
- eip got updated reflecting those things.
Probably to remove the deposit cap we’d want to address how heavily we iterate the validators during epoch transition which is definitely out of scope (and now not a problem because deposit cap is remaining).
Hi @fradamt and @anderselowsson — could you clarify whether the churn-cap identifier and unit in EIP-8061 are intended to be generic, or should the text name the Gloas-specific constant explicitly?
The motivation describes a 256 ETH/epoch cap, while the table writes uint64(2**8) (=256) without an explicit unit and the pseudocode refers to MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT. The Gloas consensus spec uses MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT_GLOAS with an explicit Gwei conversion. I also saw PR #10980 discussing the _GLOAS suffix on a different churn constant, so I wanted to ask before suggesting an edit.
The clients I checked follow the spec. This looks like a documentation clarification rather than an implementation issue.