Dev Ojha
Dev Ojha
> But adding the solution to the consensus reactor is not really the best approach. In fact, the consensus reactor should not take the consensus state lock for every received...
Should we table this until theres time to investigate the corner case?
Awesome, thanks for the breakdown! For questions: 1. I'm personally only concerned about state size of the live chain. (For import, export times, and state-syncing/snapshot-syncing a new pruned node) 2....
Apologies for delayed replies, going to go through them somewhat sequentially: > Implementing such functionality in ibc-go is fairly straightforward. v7 of ibc-go consolidates the light client interface such that...
> *technically applications could choose to utilize async acknowledgements in which case receipts/acks cannot be deleted until an acknowledgement is written sometime after receipt (but no guarantee an ack is...
> Incentivization Good point, I think we have a couple options. Likely depends on complexity for navigating between them. - Force relayers to have to do this. E.g. after N...
> Is it possible for you to look at the client genesis and determine how much persisted state is for expired consensus states? As @colin-axner mentioned, we currently only prune...
Did this in the Osmosis fork in this PR: https://github.com/osmosis-labs/cometbft/pull/125 (and did the next step of removing the concurrent launching of these, as starting a thread was longer then the...
We still want precommits for the last block to get into the consensus mutex if they aren't duplicate, so perhaps this should be: ``` // if vote is late, and...