Skip to content

Conversation

@kamilsa
Copy link

@kamilsa kamilsa commented Jan 14, 2026

🗒️ Description

Introduces aggregator role and subnet aggregation.

  • Every validator is assigned to one of the attestation subnets
  • Aggregators collect signatures that correspond to validators from their subnet
  • If aggregators collected 90% of signatures from their subnet by the beginning of slot 2, they produce aggregated attestation and propagate it into aggregation topic
  • Validators subscribe to aggregation topic, so that next block proposer may include committee aggregations into the block (without recursive aggregation for now)

Remaining work

  • Process the case when aggregators did not observe enough signatures by the beginning of interval 2
  • Add predicates for gossipsub propagations of aggregated signatures (e.g. do not propagate aggregation if we already observed the one for the same committee, but proving more validators signatures)
  • Update to latest master

🔗 Related Issues or PRs

leanEthereum/pm#56
leanEthereum/pm#58

✅ Checklist

  • Ran tox checks to avoid unnecessary CI fails:
    uvx tox
  • Considered adding appropriate tests for the changes.
  • Considered updating the online docs in the ./docs/ directory.

Copy link
Contributor

@jihoonsong jihoonsong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work! Please excuse leaving some comments while it's still in draft. Just wanted to help iterate faster :)

# Configure the genesis state.
genesis_config = Config(
genesis_time=genesis_time,
attestation_subnet_count=AGGREGATION_COMMITTEE_COUNT,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I admit that I was the one who advocated for attestation committee, but based on the fact that validators only push their attestations to aggregators in their subnet without subscribing to it, I now think aggregation committee gives us slightly better description.

I don't mind whichever we choose—either attestation committee or aggregation committee—but I do think we need to stick to one thing consistently in the Lean spec and pq-devnet-3.md in the pm repo.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have a strong preference too, however I think the rationale for topic names in beacon chain spec is based on the type of messages that are being propagated to this topic. For consistency we should probably stick to the same logic and keep using attestation subnets and attestation committees

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds great! In the same vein, what do you think about this one?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good to me, applied your suggestion

# Conflicts:
#	src/lean_spec/subspecs/forkchoice/store.py
#	src/lean_spec/subspecs/networking/__init__.py
Validators participate in consensus by proposing blocks and producing attestations. This
document describes what honest validators do.
Validators participate in consensus by proposing blocks and producing attestations.
Optionally validators can opt-in to behave as aggregators in a single or multiple
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A validator is assigned to a certain subnet but can they perform an aggregator role in multiple subnets?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question. I think we may add this possibility in future. But lets start with one subnet per aggregator.

I think we may consider similar logic to how validators self-assign themselves for sampling of single or multiple columns data in PeerDAS

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds great! We can update this description to a single committee and modify it later once we introduce multiple subnets aggregator.


When aggregation is added, aggregators will collect attestations and combine them.
Aggregated attestations will be broadcast separately.
Devnet-2 introduces signatures aggregation. Aggregators will collect attestations and combine them. Aggregated attestations will be broadcast separately.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Devnet-2 introduces signatures aggregation. Aggregators will collect attestations and combine them. Aggregated attestations will be broadcast separately.
Devnet-3 introduces signatures aggregation. Aggregators will collect attestations and combine them. Aggregated attestations will be broadcast separately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants