EIP-7251 open questions / tasks

[ralexstokes]

• 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_withdrawals works as it is backwards incompatible with that function's signature in previous forks. It is possible we could do something like pop on the pending_partial_withdrawals list, although also see this
• Revisit how deposits are handled between pre-EIP-7251 and post-EIP-7251 (cf. Fix EIP-7251 tests #3656)
• Add EIP-7549 tests and Electra random tests #3670
• EIP-7251: Stricter bound for consolidation queue #3661 note: decided unnecessary
• EIP-7251: Enforce Activation Rate Limit at Fork Transition #3659
• Handle top-ups to exiting/exited validators #3776
• EIP-7251: update exit churn logic #3677
• Handle TODO to update light client g-indices Add EIP-7251 to Electra #3668 (comment)
• Revisit balance processing and exit epoch calculation Add EIP-7251 to Electra #3668 (comment)
• 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: EIP-7251: Fix off-by-one in churn computations #3682 and add a test case for the underlying issue EIP-7251: update exit churn logic #3677

Tests to write

Test this: #3679
Revisit this test: #3681 (comment), may just need to manually check "is partially withdrawable", like we do in some other tests

[yksnyn]

class AttestationData(Container):
slot: Slot
index: CommitteeIndex
# LMD GHOST vote
beacon_block_root: Root
# FFG vote
source: Checkpoint
target: Checkpoint

[seongyun-ko]

I know it is not in the current spec. Is it possible to allow the consolidation of the validators with different withdrawal addresses? @ralexstokes

[mkalinin]

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.

[seongyun-ko]

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?

[mkalinin]

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?

• Consolidation request contract on EL
• process_consolidation_request on CL

[seongyun-ko]

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?

• Consolidation request contract on EL
• process_consolidation_request on CL

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

[mkalinin]

@seongyun-ko answered in #3775 (comment)