ChainSafe / ChainSafe/lodestar
Include SingleAttestation when producing block
- Dominant language
- TypeScript
- Stars
- 1.4k
- Forks
- 483
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 150
Description
### Problem description
right now we have `AttestationPool` of `SingleAttestation` and `AggregatedAttestationPool` of aggregated `Attestation`. When producing block, we only query `AggregatedAttestationPool`. We should also scan through `AttestationPool` so that:
- lodestar has more attestations in its produced block, that brings more consensus value produced
- it's easier to identify lodestar block
cc @nflaig
### Solution description
- enhance `AttestationPool` so that it does not only preaggregate attestations but also store validated `SingleAttestation` instances
- index by `committeeValidatorIndex` so that it's easier to query
- when producing block:
- loop through slots
- for each slot, loop through att_data of both pools. Make sure all `att_data` pass validation in order not to include conflicted attestations
- for each att_data, loop through committee index
- merge data from both pools in getAttestationsForBlockElectra
### Additional context
Note:
- this will take more time, but we already produced attestations while waiting for responses from EL/builder in https://github.com/ChainSafe/lodestar/pull/7814
- Teku time boxed the process, maybe we don't need it as I'll suppose it does not take so much time as we should loop through `AggregatedAttestationPool` first and left only few "not seen attesters" but could be a nice too have when network is unstable https://github.com/Consensys/teku/pull/9487/files#diff-b0952debf32597dcee62e41a8381d3d1ca354b519b3eec1995be0651e7a0f616R516
- we can bound it by some constants as we already did in `AggregatedAttestationPool`
- Analyze memory consumed. Each SingleAttestation = 240 bytes but it's way more than that due to NodeJS inefficiency to store Uint8Array (this happen to the signature). Good news is AttestationData is shared in the `SeenAttestationDatas` cache
Contributor guide
Assessment
This issue has not been assessed yet.