Electra open questions

[ralexstokes]

EIP-7251

#3673

EIP-7549

How to handle Deneb Attestations that can be included in Electra but won't be compatible with the new format?

There will be an epoch's worth of attestations scheduled in the last Deneb epoch that are valid to include in the first epoch of Electra but are incompatible with the new attestation format.

What should we do, if anything about this transition period?

• one suggestion: clients broadcast both formats in the last deneb epoch, with care taken to not produce slashable messages
• another suggestion: extend block with extra field for the pre-electra attestations and just allow the deneb style during the first epoch of electra (otherwise validate this new list is empty in electra)

Update: after discussions with client teams, we decided to do nothing here.

TODO

• revisit these tests once we decide how to handle 353bbb0
• revisit the 'randomization' tests, to ensure we have good coverage across all operations types and scenarios

[dapplion]

Another option:

- assert data.index == 0
+ assert data.index == 0 || compute_epoch_at_slot(data.slot) < ELECTRA_FORK_EPOCH

Which allows block proposers to re-package deneb attestations into electra ones for the first epoch. This condition can be changed to wait for electra finaility

[ralexstokes]

moving remainder here to #3799