**What type of PR is this?**
Other
**What does this PR do? Why is it needed?**
When an (potentially aggregated) attestation is received **before** the
block being voted for, Prysm queues this attestation, then processes the
queue when the block has been received.
This behavior is consistent with the [Phase0 specification
](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md#beacon_attestation_subnet_id).
> [IGNORE] The block being voted for
(attestation.data.beacon_block_root) has been seen (via gossip or
non-gossip sources) (a client MAY queue attestations for processing once
block is retrieved).
Once the block being voted for is processed, previously queued
(potentially aggregated) attestations are then processed, and
broadcasted.
Processing (potentially aggregated) attestations takes some non
negligible time. For this reason, (potentially aggregated) attestations
are deduplicated before being introduced into the pending queue, to
avoid eventually processing duplicates.
Before this PR, two aggregated attestations were considered duplicated
if all of the following conditions were gathered:
1. Attestations have the same version,
2. **Attestations have the same aggregator index (aka., the same
validator aggregated them)**,
3. Attestations have the same slot,
4. Attestations have the same committee index, and
5. Attestations have the same aggregation bits
Aggregated attestations are then broadcasted.
The final purpose of aggregated attestations is to be packed into the
next block by the next proposer.
When packing attestations, the aggregator index is not used any more.
This pull request modifies the deduplication function used in the
pending aggregated attestations queue by considering that multiple
aggregated attestations only differing by the aggregator index are
equivalent (removing `2.` of the previous list.)
As a consequence, the count of aggregated attestations to be introduced
in the pending queue is reduced from 1 aggregated attestation by
aggregator to, in the best case,
[MAX_COMMITTEE_PER_SLOT=64](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md#misc-1).
Also, only a single aggregated attestation for a given version, slot,
committee index and aggregation bits will be re-broadcasted. This is a
correct behavior, since no data to be included in a block will be lost.
(We can even say that this will reduce by a bit the total networking
volume.)
**How to test**:
1. Start a beacon node (preferably, on a slow computer) from a
checkpoint.
2. Filter logs containing `Synced new block` and `Verified and saved
pending attestations to pool`. (You can pipe logs into `grep -E "Synced
new block|Verified and saved pending attestations to pool"`.
- In `Synced new block` logs, monitor the `sinceSlotStartTime` value.
This should monotonically decrease.
- In `Verified and saved pending attestations to pool`, monitor the
`pendingAggregateAttAndProofCount` value. It should be a "honest" value.
"honest" is not really quantifiable here, since it depends on the
aggregators. But it's likely to be less than
`5*MAX_COMMITTEE_PER_SLOT=320`.
**Which issues(s) does this PR fix?**
Partially fixes:
- https://github.com/OffchainLabs/prysm/issues/16160
**Other notes for review**
Please read commit by commit, with commit messages.
The important commit is b748c04a67.
**Acknowledgements**
- [x] I have read
[CONTRIBUTING.md](https://github.com/prysmaticlabs/prysm/blob/develop/CONTRIBUTING.md).
- [x] I have included a uniquely named [changelog fragment
file](https://github.com/prysmaticlabs/prysm/blob/develop/CONTRIBUTING.md#maintaining-changelogmd).
- [x] I have added a description with sufficient context for reviewers
to understand this PR.
- [x] I have tested that my changes work as expected and I added a
testing plan to the PR description (if applicable).
Prysm: An Ethereum Consensus Implementation Written in Go
📖 Overview
This is the core repository for Prysm, a Golang implementation of the Ethereum Consensus specification, developed by Offchain Labs.
See the Changelog for details of the latest releases and upcoming breaking changes.
🚀 Getting Started
A detailed set of installation and usage instructions as well as breakdowns of each individual component are available in the official documentation portal.
💬 Need help? Join our Discord Community for support.
🏆 Staking on Mainnet
To participate in staking, you can join the official Ethereum launchpad. The launchpad is the only recommended way to become a validator on mainnet.
🔍 Explore validator rewards/penalties:
🤝 Contributing
🔥 Branches
Prysm maintains two permanent branches:
master- This points to the latest stable release. It is ideal for most users.develop- This is used for development and contains the latest PRs. Developers should base their PRs on this branch.
🛠 Contribution Guide
Want to get involved? Check out our Contribution Guide to learn more!
📜 License
This project is licensed under the GNU General Public License v3.0.
