Michael Sproul

It's a real mystery! Do you mind trying the unoptimised `v2.3.1` tag instead then? (edit: cc @jmcruz1983)

@jmcruz1983 Thanks! Can you please try building an image manually for the `stable` branch? Following the same process you use to build this PR

Hi @jmcruz1983, I've opened a PR to help us debug the issue here: https://github.com/sigp/lighthouse/pull/3279. Once that lands in `unstable` we'll be able to compare the SigP-compiled `:latest-unstable` image against a...

@jmcruz1983 the metrics have landed in `unstable` if you'd like to test manually-compiled `unstable` vs `:latest-unstable` :pray:

@jmcruz1983 If my suspicions are correct, I expect a large fraction of your VC's memory usage will be freed memory that hasn't been reclaimed, which should show up under `Free...

Thanks @jmcruz1983. We'll do some more investigations on our end to see what could be using so much memory when the VC uses web3signer.

On `tree-states` I've implemented an optimisation that avoids calculating the proposer index at all. Using the existing proposer shuffling cache the index is checked once during block verification and then...

On the backburner, we're hesitant to add this feature without opt-in from other client teams and a good solution to providing access to the historical data.

Hi @GerardBri, There's definitely something very unusual going on with your node. This is the sort of issue we only see a handful of times per year, and usually it's...

hi @zsluedem is this ready for review?