twoeths

I have a branch (`tuyen/eth1_use_fallback_url`) to switch between 2 different eth1 provider urls every 5 minutes and it still can fetch deposits successfully (this is on mainnet) also the log...

> Right! Notice this also when working on this issue. What are the implications of always passing the same pair of new and old balances? the impact is not much...

As of Oct 2023, we already implemented network thread and batch attestation validation so this is not an issue anymore

lodestar changed a lot since v0.37.0 v1.3.0 rc.1 has been great in terms of mesh peers - a goerli node with 1k validators - a mainnet node subscribing to all...

one proposal for this work with some criterias: - keep state-transition async, no need to change it, just add some simple apis - ShufflingCache is only managed by beacon-node given...

another idea is to model `ShufflingSource` for next epoch. We always need previous/current shuffling, not the next shuffling so it could be lazily computed at `beacon-node` side after an epoch...

looks like this time has been stable over time, this is in the last 30 days on mainnet node it's quite good

yes I strongly support the idea because having shuffling inside both EpochCache and ShufflingCache is not great. Some more contexts: - the cache of shuffling inside state-transition is not for...

~~it's not possible to get rid of shuffling inside CachedBeaconState, it's needed in at least 2 places~~: - upgradeStateToAltair() - processSyncCommitteeUpdates() ~~this is required in the `processSlots()` where it spans...

`curl http://localhost:9596/eth/v1/lodestar/peers` shows too many `NA` peers, which means `agentVersion` is not set for them https://github.com/ChainSafe/lodestar/blob/v1.15.0/packages/beacon-node/src/network/peers/peersData.ts#L38