Age Manning

There is some duplicate code between sync committees and the attestation service. In this update, we should try and group all this logic as the entire attestation service will need...

Update with more specific details: The spec issue contains the latest updates on what we are trying to achieve. From an implementation side: We have two files: https://github.com/sigp/lighthouse/blob/stable/beacon_node/network/src/subnet_service/attestation_subnets.rs and https://github.com/sigp/lighthouse/blob/stable/beacon_node/network/src/subnet_service/sync_subnets.rs...

Some thoughts - I dont think we go too fancy and have dynamic adjustments to load based on time of processing in the queue (but we could if someone really...

Yep, this has been on my radar for a while. See: https://github.com/sigp/lighthouse/issues/1617. In principle, all our networking sub-protocols support ipv6 but there are complexities that require care and thought when...

Ok. I dont think this is an overly large task to complete.We should hopefully have some time to address this and I'll increase this in priority and get proper IPv6...

We might want to shift away from `psutil`. They don't seem to be maintaining it well and I've had to upgrade their deps again: https://github.com/sigp/rust-psutil/tree/upgrade-deps

I've also had to fork a dep of this, which also seems to be fairly unmaintained. https://github.com/AgeManning/darwin-libproc/tree/requirements

> Do you have high level estimates on the numbers on the bandwidth each topic consumes? Primarily beacon_block vs a single attestation subnet. I don't have exact numbers, but will...

> Meaning, I take information about past messages to not duplicate route for future messages? I'd worry that due to the mesh dynamically changing slot-to-slot that this could create gaps...

Yeah, I think it hasn't been done because it wasn't clear how much this would save us vs the overhead of storing every peer for every duplicate. I think in...