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

Maximum clique enumeration for attestation aggregation in op pool #3733

Open
michaelsproul opened this issue Nov 17, 2022 · 8 comments
Open
Assignees
Labels
backlog PR is not currently prioritized optimization Something to make Lighthouse run more efficiently.

Comments

@michaelsproul
Copy link
Member

Description

Presently Lighthouse uses an opportunistic strategy for aggregating attestations added to the op pool. Any new attestation which can be aggregated with an existing one will be aggregated here:

// Greedily aggregate the attestation with all existing attestations.
// NOTE: this is sub-optimal and in future we will remove this in favour of max-clique
// aggregation.
let mut aggregated = false;
for existing_attestation in attestations.iter_mut() {
if existing_attestation.signers_disjoint_from(&indexed) {
existing_attestation.aggregate(&indexed);
aggregated = true;
} else if *existing_attestation == indexed {
aggregated = true;
}
}

In our collaboration with Satalia they prototyped a maximum clique enumeration algorithm for doing optimal aggregation. This issue is about adopting that optimal aggregation algorithm, while keeping our greedy algorithm for max coverage.

If you're interested in working on this issue DM me and I can provide a copy of the code written by Satalia. They wrote a pure Rust implementation of the Bron-Kerbosch algorithm which showed good performance during testing.

We would need to overhaul how we handle unaggregated attestations in the naive_aggregation_pool so that we keep single attestations unaggregated. This might be somewhat delicate.

Version

Lighthouse v3.2.1

@michaelsproul michaelsproul added optimization Something to make Lighthouse run more efficiently. backlog PR is not currently prioritized labels Nov 17, 2022
@ankurdubey521
Copy link

I plan to participate in the 4th cohort of the Ethereum Protocol Fellowship and am highly interested in picking this up as my project for the cohort.

@michaelsproul
Copy link
Member Author

I think @GeemoCandama was also interested in working on this, would you two be open to working together?

@GeemoCandama
Copy link
Contributor

Yes, I am interested in working on this.

@ankurdubey521
Copy link

I think @GeemoCandama was also interested in working on this, would you two be open to working together?

Excited to work on this together @GeemoCandama !

@PatStiles
Copy link

I'm also participating in the cohort and was thinking about working on this @ankurdubey521 @GeemoCandama are you guys down to collaborate?

@GeemoCandama
Copy link
Contributor

GeemoCandama commented Jul 20, 2023

@PatStiles I don't think more people working on this would be beneficial. I think we would have a too many cooks in the kitchen type situation. If you have a different idea feel free to message me on Discord though: @geemo_candama.

@PatStiles
Copy link

No worries, @michaelsproul I Dm'd you regarding other projects.

@michaelsproul
Copy link
Member Author

Hey @PatStiles I'm on leave for the next 2 weeks, please reach out to @paulhauner

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backlog PR is not currently prioritized optimization Something to make Lighthouse run more efficiently.
Projects
None yet
Development

No branches or pull requests

4 participants