Confirm that the new promise_batch_action_function_call_weight host function doesn't need a separate set of costs

[matklad]

We are adding a new host function, promise_batch_action_function_call_weight. It works just like promise_batch_action_function_call, but allows for a bit of extra logic when attaching gas. Specifically, this fuction supplies each created function call action with a gas weight, and then, in the end of execution, we distribute all the unused gas proportional to the supplied weights.

The question is:

Should the fees for this function be different from from the base one? Currently they are the same.

I think this is fine (we are basically adding a loop and a few arith ops on top of relatively heavy code), but it would be great to get some more concrete benchmarks here.

[matklad]

@jakmeier could you make a judgement call here? The relevant function is this one:

nearcore/runtime/near-vm-logic/src/logic.rs

Line 1602 in bdc9410

pub fn promise_batch_action_function_call_weight(

[jakmeier]

I'm pretty confident we don't need an additional parameter here. The new logic inside the host function is in a part we don't really charge for anyway right now. And it is easily outweighed by the base function-call receipt creation.

However, there is a more interesting question to be raised about the loop you mentioned. The thing is, it happens for all data receipts, no matter their origin. And I believe we have a few cases where this even happens when we fail with gas-exceeded error and never actually pay for the function call itself. With 1000 dependencies and some u128 arithmetic, this might have a non-negligible effect.

I will come up with some estimations and report back. But I don't think this should block anything, we just have to keep an eye on what this does to data receipt costs.

[jakmeier]

Never mind, I was seeing ghosts. Trying to force the case I had in mind, I finally understood that the loop goes over gas_weights: Vec<(FunctionCallActionIndex, GasWeight)> which only contains function call receipts and those are already paid for at this point.

Thus, I don't think we need any benchmarks to answer the question at hand. I will close this issue based on that.

More generally though, we might want to create estimations for different base costs of different host function calls. (Today we estimate only block_index and assume it is representative.) Mostly because functions like the two promise_batch_action_function_call* variant cause indirect computation costs that could be an argument for charging a higher fee.

Unfortunately, our estimation is currently not precise enough to estimate small cost differences like the one at hand. The only way I can immediately think of measuring the difference of promise_batch_action_function_call and promise_batch_action_function_call_weight is to create a bunch of function calls with and without weights and check the difference. But the HostFunctionCall (a.k.a. base) fee is a fraction of 1 Ggas whereas a function call receipt costs 2 x 2.3Tgas. In my tests, our variance of the total is too high to make the difference of two such measurements anything other than measurement error.
We might be able to circle back on this, if we figure out how to separate IO estimation from CPU estimation costs.