Electra open questions
Closed this issue · 2 comments
ralexstokes commented
EIP-7251
EIP-7549
How to handle Deneb Attestation
s 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 messagesanother 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 commented
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 commented
moving remainder here to #3799