Evm gas estimation

[ailisp]

Mostly done, comments by @ilblackdragon isn't addressed, some clean ups needed. Didn't have a proper way to pre-cap evm gas limit from near gas limit, but this should be possible. Please review regarding how number is calculated. From my machine, it's a very stable number that change 3% or less.

• figure out why gas usage is negative
• add evm runner in runtime-params-estimator, measure deploy_code and function call cost from runtime-param-estimator (Y), gas_used (X) of different contracts
  • deploy_code
  • function call
  • call precompiled function
• Calculate near cost of any evm deploy/function call operation in near, with possibly call precompiled function
• cap evm prepaid gas calculated from prepaid near gas, so evm won't use more gas than corresponding prepaid near gas
• address Evgeny's comment
• stablization cost counting numbers in different runs

[gitpod-io]

[ilblackdragon]

Hm, I'm curious how is this done in other places? Seems like this is wrong level where evm gas should be surfaced.
And the normal gas is in the VMOutcome

[ailisp]

run_evm is only called at two places, one is actual call evm in vm runner:

where i'm going to convert evm gas and add into near gas (it could be also add somewhere else, in that case, this return arg is ignored)

Another is in runtime_param_estimator:

where we're only interested in evm_gas used, and are measuring number of cpu instructions and calculate a relationship between evm_gas used vs cpu instructions (cost).

how is this done in other places?

In near gas estimator, there is a feature costs_counting turn on measure mode and it's turned off in production, turned on in param estimator. but it's not necessary here, because evm crate will always calculate you evm gas used, and it's not expensive to return one more argument. In the case you don't need, you can ignore it.

[ailisp]

@ilblackdragon @nearmax @evgenykuzyakov done in finalizeing numbers, volatility, 200K accounts: #3495 #3396 #3502, and updated the numbers, I think it's ready, please review again

@evgenykuzyakov for counting action receipt cost i had a new approach now. by inspecting every step of txn outcome/receipt, gas_used, gas_burnt, I found:

• process_block: txn send to evm account, action receipt created, gas_used and gas_burnt is correctly count to action receipt cost for the wrapped FunctionCallAction.
• process_block_until_no_receipts: actual place run_evm is invoked, produce no receipt and one outcome of evm execution result. cost of this part should only count evm execution.
  When run in a real node, runtime.apply did is same as above, first sent txn to evm account and in this step, gas_counter has count gas_used & gas_burnt with action receipt cost, then second step process_receipt would trigger run_evm with remaining gas from first step. It's same as a cross account function call of a wasm contract. Therefore I only measure process_block_until_no_receipts for evm execution part and in real node runtime will deduct total cost correctly