[ProjectTracking]: Reduce function call costs

[nagisa]

Background

Currently whenever users request the protocol to execute a function inside a contract, a gas fee has to be paid for setting up the necessary state for execution before the execution itself even begins.

This fee is pretty large and has not been changed for quite some time now, even though we did put some effort into reducing the compute resources necessary for the set up in question.

Part of it stems from the fact, that the fee we charge traditionally had been challenged many times for already being too low – there were plenty of instances where we were wary of reducing the fees primarily because the optimizations were seen more as a fix for an undercharging vulnerability of some sort, rather than as an improvement over an otherwise correct implementation.

However, function call fees have also been pointed out many times over as being too high from the practicality standpoint. Now that we've gone through the low-hanging optimization fruit, it is a good time to see if we can translate all that work into a reduction in fees, thus making the protocol more practical/cheaper to use.

Goals

This project will ultimately end up in a well-motivated and -reasoned downward change (if the fees do indeed decrease) to the fees charged as part of a function call invocation on the NEAR protocol.

Links to external documentations and discussions

Note from Jakob:

The concerns to be cleared up are mostly about how exactly to distribute the cost across parameters. Like, the action send cost is way too high, as we don't do much on the sender shard but still pay half the fn call cost. But the scaling with the parameter size might be too low for what we do on the executing shard. Plus, we don't have any scaling at all with regards to the contract code size. So we should be careful for scenarios with huge contracts and low gas spending.

TODO

Please provide links to external discussions and documents such as google design docs; zulip design discussions; NEP discussions; documentation from other projects; etc. Please take care that all these materials are publicly viewable when appropriate.

Estimated effort

The estimator is currently estimating that a function call costs roughly

ActionFunctionCallBase                         30_974_618_686
ActionFunctionCallBaseSendNotSir                    8_846_250
ActionFunctionCallBaseSendSir                       5_836_250
ActionFunctionCallBaseExec                    143_007_523_750
ActionFunctionCallPerByte                             250_000
ActionFunctionCallPerByteSendNotSir                       724
ActionFunctionCallPerByteSendSir                          461
ActionFunctionCallPerByteExec                       3_541_726

which comes out down to much lower base than the current fee 2_319_861_500_000 (same for all variants) and somewhat higher per-byte fee than the current 2_235_934 (again, same for all variants.)

The project will first of all involve double, triple and quadruple checking how motivated these estimations are, so that we don't dig ourselves into an undercharging hole from which there is no way out. Aside from that the effort is not actually very significant and is basically just applying these new numbers to our config.

Assumptions

The estimations for function call costs are not complete non-sense. The estimator itself currently reports that they aren't particularly certain due to run-to-run variance, but this variance isn't especially high as far as I can tell.

Pre-requisites

None.

Out of scope

We are not re-evaluating fees for compilation, deploy or execution. Deploy in particular may be tempting to look at as well, as we have some unfinished effort in that area as well: there's a new estimation written for that.