milen

@tobidae-cb hey, haven't heard back from you so I assume your workaround of downloading an Erigon datadir copy from the Polygon website helped and you are up and running with...

> I wrote my conclusions for the first round of tests: https://hackmd.io/@wmitsuda/BkFmxXL6ge > > TLDR; I didn't notice improvement on execution time; aggressive step size reduction was effective in limiting...

Also about https://github.com/erigontech/erigon/issues/16765#issuecomment-3388534767, I remember the chaindata DB would then go up to 500GB when you left it for ~1 day or more. We did some improvements since then about...

> `500GB` - it's clearly when you coming to dead-loop: `DB > RAM -> mdbx disabling ReadAhead -> prune get slower -> amount of steps in db grow with time`...

> [@wmitsuda](https://github.com/wmitsuda) [@taratorio](https://github.com/taratorio) maybe this one is related: [#16918](https://github.com/erigontech/erigon/issues/16918) yes, I think it is related stepSizemaxReorgDepthstepsToKeepInDB(dbSize) are 3 variables that are related (it's like yet another trillema)

The point is to *not* have to do all these manual operations like `rm chaindata`, `erigon snapshots rm-state-files --latest`, `restart erigon`. If a bad event on mainnet occurs and there...

> a way to generate BAL for a block (BAL is only generated in parallel execution) - this should be generated by our block builder when you send forkChoiceUpdate with...

@AskAlexSharov any ideas what may cause this?

this v3 didnt get accepted in ACDE - left for glamsterdam/post-fusaka-out-of-hard-fork-change also v2 reverted to *not* allow partial responses (our current behaviour)

re-opening as this is now needed for BPO3 on mainnet