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

[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)