twoeths

tested this on `feat1`, see https://github.com/ChainSafe/lodestar/pull/7171#issuecomment-2425472397 ready to review

sha256 works in blocks, each is 64 bytes so perhaps it's more meaningful to reflect that for `chunkBytesBuffer` variable also with holesky, there are 1.7M validators. For every 8 deposits...

`rust-kzg` is awesome, it takes less than 550ms with 20 blobs to recover however, it caused ~100ms more to validate `data_column_sidecar` in the end it causes gossip block processed time...

it's interesting that the more partial columns we have the slower the recover we should only use the 1st 64 columns to recover to save time update: it ranges from...

now the `recover_matrix()` is only called if data is unavailable at 3s the time spent to recover and second from slot are tracked in the last 2h, this `recover_matrix()` resolved...

we already have `chain.nHistoricalStatesFileDataStore` feature flag (false by default) to store checkpoint states on disc instead of db, by default all checkpoint states are stored at `~/beacon/checkpoint_states` file name is...

yes #7005 should be on v2 where we move to new database repositories, a node will not work without checkpoint sync url since we don't go with `StateArchiveRepository` anymore

the block arrival time is actually block time to head, our metrics are not the same to ProbeLab, created the issue in https://github.com/ChainSafe/lodestar/issues/7046

I think [validator performance when subscribing to all subnets](https://github.com/ChainSafe/lodestar/issues/7186) should be included in lodestar 2.0 roadmap too

e2e consistently failed in https://github.com/ChainSafe/lodestar/actions/runs/10518956587/job/29145618824?pr=7043 - test/e2e/chain/lightclient.test.ts > chain / lightclient > Lightclient track head on server configuration - test/e2e/chain/proposerBoostReorg.test.ts > proposer boost reorg > should reorg a late block...