High gas usage for function call

[ilblackdragon]

This function call that creates a call to create account - 21Tg - https://explorer.near.org/transactions/CY5SNsfk8bpVv2168qzT5P9uAWz6q95giHBioRb1VkYx

In standalone runtime it claims to burn 12Tgas in call itself:

cargo run -- --wasm-file /work/near/near-linkdrop/res/linkdrop.wasm --method-name create_account --input '{"new_account_id": "zest.near", "new_public_key": "ed25519:C1BYE6i7bDoqccHuXfGTHXQzJsdhjN7MQ6h3iCRxycCY" }'

@evgenykuzyakov :
Our minimum cross-contract call cost is around 5Tgas, so with the amount promises, data receipts and returns, it’s expected to have around 20Tgas. This includes action receipts send/execution + function send/execution. Plus you have data receipt for awaiting on a callback of the account creation success, that is around 5TGas as well.

Questions:

• What can we do to reduce 5Tg to much lower value, like 0.5Tg comparable to transfer costs?
• Single function call been 12Tg is also extremely suspicious.

[MaksymZavershynskyi]

Function call involves fetching Wasm file, loading it to the memory, maybe dynamic linking (I am not sure how Wasmer works) and starting up JIT, 200 times per second. I agree however, that we should be working on optimization of it, in fact we have set it as a top priority post Phase 1 launch with @olonho, @willemneal , and @ailisp . However, we should also adjust our expectations, the complexity of a simple transfer is nowhere close to spinning up a general-purpose VM.

Assigning it to @olonho since he is running development of the contract runtime.

[MaksymZavershynskyi]

What can we do to reduce 5Tg to much lower value, like 0.5Tg comparable to transfer costs?

@olonho , @ailisp and @willemneal would need to dig into how Wasmer works.

Single function call been 12Tg is also extremely suspicious.

I don't think it is suspicious. Function call cost is not bounded by anything but our limits. Here is a 109Tgas function call https://explorer.testnet.near.org/transactions/Byd8GjGgCZKYY3dPcJcNi23C4bSWaEPPKQmqDYUGD6NW

[willemneal]

After using @olonho's new gas profiler I got the following:

------------------------------
Total gas: 12_912_414_838_737
Host gas: 305272604007 [2% total]
Action gas: 12247273405752 [94% total]
Wasm execution: 359868828978 [2% total]
------ Host functions --------
base -> 5295362220 [0% total, 1% host]
contract_compile_base -> 35445963 [0% total, 0% host]
contract_compile_bytes -> 108_668_046_000 [0% total, 35% host]
read_memory_base -> 28708495200 [0% total, 9% host]
read_memory_byte -> 764067933 [0% total, 0% host]
write_memory_base -> 11215179444 [0% total, 3% host]
write_memory_byte -> 356814132 [0% total, 0% host]
read_register_base -> 7551495558 [0% total, 2% host]
read_register_byte -> 11334630 [0% total, 0% host]
write_register_base -> 8596567458 [0% total, 2% host]
write_register_byte -> 437179860 [0% total, 0% host]
utf8_decoding_base -> 6223558122 [0% total, 2% host]
utf8_decoding_byte -> 4082126706 [0% total, 1% host]
storage_write_base -> 64196736000 [0% total, 21% host]
storage_write_key_byte -> 352414335 [0% total, 0% host]
storage_write_value_byte -> 1706019645 [0% total, 0% host]
storage_read_base -> 56356845750 [0% total, 18% host]
storage_read_key_byte -> 154762665 [0% total, 0% host]
promise_return -> 560152386 [0% total, 0% host]
------ Actions --------
create_account -> 99607375000 [0% total]
function_call -> 2319980004502 [17% total]
transfer -> 115123062500 [0% total]
add_key -> 101765125000 [0% total]
new_receipt -> 9_610_797_838_750 [74% total]
------------------------------

So it looks like the new_receipt action is 74% of the cost.

[olonho]

Think most important problem we have is proper definition of the fees. I.e. how individual cost to be counted, and here we need consensus. For example, the meaning of the receipt creating (new_receipt) is rather convoluted aggregated cost of several operations, and it's not entirely clear why those operations are accounted this way. So I'd suggest to start effort on cost definition review to be performed by contract and transaction runtime teams.

[bowenwang1996]

Superseded by #4401