-
Notifications
You must be signed in to change notification settings - Fork 784
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
Fix attestations not getting added to the aggregation pool #5863
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix looks good to me. I will add this to v5.2.0 for testing!
@michaelsproul do you think it would be worth it to run a few testnet nodes without |
Yeah I'm down to try running some nodes with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, nice find. Looks good to me.
The duration is likely to be updated multiple times, but it should do what we expect here.
@Mergifyio queue |
✅ The pull request has been merged automaticallyThe pull request has been merged automatically at fb790de |
Issue Addressed
N/A
Proposed Changes
On receiving unaggregated attestations from the network, lighthouse sets the
should_process
variable on attestations depending on if we have a connected validator having aggregation duties for the same slot .For
should_process == false
, we only validate and forward the attestation, otherwise, we add it to the naive_aggregation_pool so that we can aggregate them.The
should_process
calculation happens in the subnet service where it checks if the duty slot and subnet exists in a delay map.lighthouse/beacon_node/network/src/subnet_service/attestation_subnets.rs
Lines 390 to 393 in 3058b96
The bug is that during insertion into the delay map, we use the default expiration delay of a single slot duration(12s).
Since we implemented #4806 to reduce subscription spam, we don't send subscriptions every slot before the duty, so we get a situation where an entry into the delay map gets evicted before it has been read.
Hence, the
should_process_attestation
function almost always returns false unlessimport-all-attestations
flag is turned on, leading to Lighthouse producing bad quality aggregate attestations.