twoeths

yes it'll produce something similar to `dev` network but we don't need to set up validators/beacon chain, we want test utils to be consumed by different unit/e2e tests

that looks really great @matthewkeil

It was analysed by lighthouse that flood publishing may contribute to this delay, we should experiment the same. See https://github.com/sigp/lighthouse/pull/4383 and https://github.com/sigp/lighthouse/pull/5357

I'd make this as medium as it's all about logging only, it does not change any functionalities. And we want it for all blocks we receive, not only the block...

this PR is not aligned with the high level design stated in in #6386 where it's recommended to move shuffling from `state-transition` to `beacon-node`. Some benefits of that approach: -...

@ensi321 there is a conflicting file `packages/fork-choice/src/forkChoice/interface.ts`

the optimization is in `us` per message so it's not easy to find an improvement on "received block time" metric. As long as we don't see memory issues I think...

yes got similar issues in the past when we upgrade gossipsub. If it's consistently takes not much higher memory than previous version then it's acceptable with lodestar, otherwise it needs...

ganache-cli seems not to be finished ``` eth_subscribe (only for websocket connections. "syncing" subscriptions are not yet supported) eth_unsubscribe (only for websocket connections. "syncing" subscriptions are not yet supported) ```...

I can get receipt for that same transaction some minutes later with the same node