EIP-7251 open questions / tasks
- [ ] Reconsider use of effective balances in computing consolidation (and likely also exit) churn, as the limits are also a function of effective balance and it seems to prevent the possibility of having multiple validators exit each epoch. see here for an example where going one unit past the churn limit does not move to the next epoch
- [ ] Reconsider how the "partial withdrawals processed" counter in
get_expected_withdrawalsworks as it is backwards incompatible with that function's signature in previous forks. It is possible we could do something likepopon thepending_partial_withdrawalslist, although also see this - [ ] Revisit how deposits are handled between pre-EIP-7251 and post-EIP-7251 (cf. https://github.com/ethereum/consensus-specs/pull/3656)
- [x] https://github.com/ethereum/consensus-specs/pull/3670
- [x] ~https://github.com/ethereum/consensus-specs/pull/3661~ note: decided unnecessary
- [x] https://github.com/ethereum/consensus-specs/pull/3659
- [x] https://github.com/ethereum/consensus-specs/pull/3776
- [x] https://github.com/ethereum/consensus-specs/issues/3677
- [ ] Handle
TODOto update light client g-indices https://github.com/ethereum/consensus-specs/pull/3668#discussion_r1560445851 - [ ] Revisit balance processing and exit epoch calculation https://github.com/ethereum/consensus-specs/pull/3668#discussion_r1562268491
- [x] Add EIP-7251 validator guide
- [ ] ~Add EIP-7251 new gossip topics~ note: shouldn't need any with EL-init'd consolidations
- [ ] Consider consolidating the logic across the two functions touched in this PR: https://github.com/ethereum/consensus-specs/pull/3682 and add a test case for the underlying issue https://github.com/ethereum/consensus-specs/issues/3677
Tests to write
Test this: https://github.com/ethereum/consensus-specs/pull/3679 Revisit this test: https://github.com/ethereum/consensus-specs/pull/3681#discussion_r1568642616, may just need to manually check "is partially withdrawable", like we do in some other tests
I know it is not in the current spec. Is it possible to allow the consolidation of the validators with different withdrawal addresses? @ralexstokes
I know it is not in the current spec. Is it possible to allow the consolidation of the validators with different withdrawal addresses? @ralexstokes
It is possible with the existing design. Consolidations are initiated via EL triggered consolidation requests which are signed by the withdrawal credentials and submitted on the EL via system smart contract, and this design doesn’t require withdrawal credentials of the source and the target to be same.
I know it is not in the current spec. Is it possible to allow the consolidation of the validators with different withdrawal addresses? @ralexstokes
It is possible with the existing design. Consolidations are initiated via EL triggered consolidation requests which are signed by the withdrawal credentials and submitted on the EL via system smart contract, and this design doesn’t require withdrawal credentials of the source and the target to be same.
That is great news! Maybe I was referencing some out-dated articles. Can you point me to the relate docs or codes that I can check it?
That is great news! Maybe I was referencing some out-dated articles. Can you point me to the relate docs or codes that I can check it?
That is great news! Maybe I was referencing some out-dated articles. Can you point me to the relate docs or codes that I can check it?
Nice! I see that the constraint existed, but removed by this PR https://github.com/ethereum/consensus-specs/pull/3775/files#diff-ecc9c1ba13f4c2bf31208a56061f23431b62a644cbb6db6ea1480a32976f2fe3L1324-L1325
Wonder why it was not allowed initially and what has changed
@seongyun-ko answered in https://github.com/ethereum/consensus-specs/pull/3775#discussion_r1780058538
I am closing this issue because it seems stale. Please, do not hesitate to reopen it if this is a mistake