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

Release v1.5.0-beta.0 #4078

Merged
merged 93 commits into from
Jan 10, 2025
Merged

Release v1.5.0-beta.0 #4078

merged 93 commits into from
Jan 10, 2025

Conversation

jtraglia
Copy link
Member

@jtraglia jtraglia commented Jan 8, 2025

etan-status and others added 30 commits November 21, 2023 08:38
Currently, the best LC update for a sync committee period may refer to
blocks that have later been orphaned, if they rank better than canonical
blocks according to `is_better_update`. This was done because the most
important task of the light client sync protocol is to track the correct
`next_sync_committee`. However, practical implementation is quite tricky
because existing infrastructure such as fork choice modules can only be
reused in limited form when collecting light client data. Furthermore,
it becomes impossible to deterministically obtain the absolute best LC
update available for any given sync committee period, because orphaned
blocks may become unavailable.

For these reasons, `LightClientUpdate` should only be served if they
refer to data from the canonical chain as selected by fork choice.
This also assists efforts for a reliable backward sync in the future.
In the gossip specification, the `GOSSIP_MAX_SIZE` constant is specified
for the uncompressed payload size in the gossipsub message.

This PR clarifies how this limit applies to the various fields of the
gossipsub message and provides additional limits derived from it that
allow clients to more aggressively discard messages.

In particular, clients are allowed to impose more strict limits on
topics such as attestation and aggregates - an `Attestation` for example
takes no more than `~228` bytes (to be verified!), far below the 10mb
limit, though implicitly clients should already see these limits imposed
as rejections by their SSZ decoder - this clarification mainly
highlights the possibilty to perform this check earlier in the process.
etan-status and others added 18 commits January 6, 2025 12:28
New tests were added in #4032 with incorrect EL block hash, fix these.
Emit correct block hash in random Electra tests
Fix a few nits dealing with updated makefile
Update blob sidecar subnet computation for EIP-7691
Fulu: Remove V3 of blob sidecar by root/range RPC
Use SubnetID for sync committee
Remove reference to electra.BlobSidecar in EIP-7691
Restrict best LC update collection to canonical blocks
@jtraglia jtraglia merged commit 9a0b3ef into master Jan 10, 2025
45 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.