Anton Puhach
Anton Puhach
@walnut-the-cat 1. I've added more detailed description for that dashboard 2. Yes, it means caching state values with no compression 3. decompression time is already included, added that to the...
@walnut-the-cat yes, #10566 is pretty much the same as "Caching large state values" but with a slightly different approach
@shreyan-gupta `size_of_contract * num_times_called_in_prev_epoch` makes sense if we have a lot of cache churn. In my experiments with `N=1000` per each shard it didn't fill even half-way in 6 days:...
Compression was implemented in #10715 Closing this for now, a new issue will be created for the long-term (Top N values as part of the Protocol) solution
Progress update (created together with @Longarithm): - Refactoring #8577: spent 2 weeks to agree on the plan, **2 more weeks** to implement - Tests #8500: not started, need **1 week**...
@mm-near > Do we have info on how big the state witnesses are going to be on average ? (based on current traffic patterns) Please find the metrics based on...
@akashin I suggest implementing that as part of runtime if possible. So currently we [set the same gas_limit to NewChunkResult](https://github.com/near/nearcore/blob/16904837e2f3f7db1699010682f0a5e1f70c4d09/chain/chain/src/update_shard.rs#L219). Instead you can add `gas_limit` to `ApplyChunkResult` and then use...
@akorchyn just FYI global contract are planned to be release in 2.6, not 2.5.0
fixed in https://github.com/near/nearcore/pull/11036
Overall the implementation makes sense to me.