[#887] Smarter initial gas limit estimation
NB: I suggest using the simpler (and faster) approach here. Basically, I fail to invent a realistic scenario where this would be insufficient -- the scenario implies a very expensive (in terms of gas) call batched together with one or several very cheap ones. In practice, we mostly want to batch originations and transfers to implicit accounts, and even for larger contracts originations are relatively cheap, so unless we try to batch literally hundreds of originations and throw in some transfers for good measure, we should be fine.
TL;DR: implementing a more complicated and costly algorithm for gas limits estimation is not justified until we have a use case which fails with the simpler one.
Description
Problem: Currently, we're setting initial limit to
hard_gas_limit_per_operation, which is just way too high, and puts a
very low limit on the number of operations we can put in a single block.
Solution: Instead, set initial limit to the smaller one of hard_has_limit_per_operation and (ceil (hard_gas_limit_per_block / num_operations)). This is far from optimal, however for small-ish operations, here batching makes the most sense, and for a reasonable number of operations in a batch, this should basically always work. The set of cases where this new algorithm fails is a proper subset of the set of cases where the current algorithm fails, so this is an unambiguous improvement.
Related issue(s)
Partially implements #887 (closed).
✅ Checklist for your Merge Request
Related changes (conditional)
-
Tests (see short guidelines)
-
If I added new functionality, I added tests covering it. -
If I fixed a bug, I added a regression test to prevent the bug from silently reappearing again.
-
-
Documentation
Stylistic guide (mandatory)
-
My commits comply with the following policy. -
My code complies with the style guide.