Dev Ojha
Dev Ojha
Ah, I was a bit naive in my statement: > The first ValidateBlock inside PoolRoutine can very quickly be sped up, by making a new function that does block validation...
Happy to remove the block gas meter!
I still believe that this would be valuable. A very significant percentage of iterator usage in Osmosis is this use case. (And suffers kind of insane overheads)
That sounds great to me! Would love for these to just be deleted from the codebase
We can query an external service to approximate this (at the cost of leaking our peers IP's to a centralized counterparty) Thinking about it, maybe its preferrable for there to...
I suspect our problem is that in consensus mode: - Nodes don't save data sent from future heights/rounds - Peers as a consequence try to not gossip things too far...
This may be my naiveness, I thought this call (after Commit completes) is what handles crash recovery (makes us not re-run commit), which is here: [blockExec.store.Save(state)](https://github.com/cometbft/cometbft/blob/v0.37.x/state/execution.go#L264)
Didn't review changes in detail (tbh sending it on a live node and seeing if things run seems easiest. Alternatively just that nested cache kv stores work properly) Been wanting...
Sorry for the delay in response here. Yes its not actually covered by that! In Osmosis we often need these conditional proposals, where we only decide that the latter proposal...
The PR / logic change for this is super easy. Its also safe since timeouts just have to be non-decreasing per the paper (and intuitively) Not sure what the process...