Devnet 4

[anshalshukla]

🗒️ Description

Implements recursive aggregation. Spec for devnet-4 (draft):

- updates aggregation API to support recursive aggregation
- INV_PROOF_SIZE is defined as a protocol parameter
- changes aggregate_gossip_signatures to aggregate as it will no longer just aggregates gossip signatures but also recursively aggregates children_payloads with them.
- changes aggregate_committee_signatures to aggregate_committee_signatures_and_payloads, it includes both committee gossip signatures and payloads (no committee) and recursively aggregate them using aggregate

🔗 Related Issues or PRs

✅ 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.

[g11tech]

calc and sort them here with participants - covered directly, this is what really will give greedy coverage which imo would be the best coverage algo on average

[g11tech]

Suggested change

	def aggregate_committee_signatures_and_payloads(self) -> tuple["Store", list[SignedAggregatedAttestation]]:
	def aggregate_signatures_and_payloads(self) -> tuple["Store", list[SignedAggregatedAttestation]]:

[g11tech]

it needs to take attestation/attestation data as the params

[anshalshukla]

We have attestation_data from new_payloads and signatures_map

[g11tech]

new payloads are use for aggregator and it can extend with known payloads if the validator indices in attestations for a particular data is not covered.

and known payloads are used for block proposer which will already have new payloads merged in and shouldn't require a lookup in new payloads (which should be an error condition)

[anshalshukla]

new payloads are use for aggregator and it can extend with known payloads if the validator indices in attestations for a particular data is not covered.

Yeah, this function does exactly that, it is for aggregation of payloads and signatures for the aggregator.

and known payloads are used for block proposer which will already have new payloads merged in and shouldn't require a lookup in new payloads (which should be an error condition)

I may not fully understand this, but known payloads refer to payloads that have already been accounted for and included in blocks. While performing aggregation, I use these known payloads if a particular attestation_data exists either in signatures_map or in new_payload, and the same payload is also present in known_payload and can contribute additional participant bits.

[anshalshukla]

Adding these changes to #449