Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Electra open questions #3664

Open
2 tasks
ralexstokes opened this issue Apr 9, 2024 · 1 comment
Open
2 tasks

Electra open questions #3664

ralexstokes opened this issue Apr 9, 2024 · 1 comment
Labels

Comments

@ralexstokes
Copy link
Member

ralexstokes commented Apr 9, 2024

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)

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
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants