Nico Flaig

Reopening until we can confirm this is fixed by upgrading libp2p, see https://github.com/ChainSafe/lodestar/issues/5642#issuecomment-1761433473.

This is still an issue in the latest release as [confirmed by seamonkey](https://discord.com/channels/593655374469660673/593655641445367808/1222518289435988039)

Might be resolved in the next node release, see fix https://github.com/nodejs/node/pull/51526 and another related issue https://github.com/tinylibs/tinypool/issues/54

> It seems like prysm is stuck on requesting genesis state, and stops there. This sounds similar to what is reported in https://github.com/prysmaticlabs/prysm/issues/13852, https://github.com/prysmaticlabs/prysm/issues/13851 and https://github.com/status-im/nimbus-eth2/issues/6175.

Issue has been resolved on the Prysm side, see https://github.com/prysmaticlabs/prysm/pull/14097

~~@tersec regarding the getAggregate error, also reported in https://github.com/ChainSafe/lodestar/issues/6631, is Nimbus by any chance requesting an aggregate attestation even if no validator is aggregator? We had the same issue with...

> even with `--doppelganger-detection=off` I'm getting: > > ``` > ERR 2024-04-05 18:03:31.097+00:00 Beacon node provides unexpected response reason="Serialization error;200;produceBlockV3(best);unexpected-data" node=http://172.16.0.31:8562[Lodestar/v1.17.0/f2ec0d4] node_index=0 node_roles=AGBSDT > WRN 2024-04-05 18:03:31.097+00:00 Unable to retrieve...

> The "unexpected data" might be because we are returning execution_payload_source metadata field in the response After reviewing how Nimbus handles this case it does not seem to be the...

> @tersec regarding the getAggregate error, also reported in #6631, is Nimbus by any chance requesting an aggregate attestation even if no validator is aggregator? We had the same issue...

> @nflaig We have 1:1 setups only. We haven't considered any testing for 1:x testing. Then I have no idea why this happens but something to note is that there...