confusing gas usage on a Tx in NEAR Explorer

[amgando]

subject

gas usage i don’t understand: https://explorer.nearprotocol.com/transactions/2tPcYYi6xYzTbHeprZTD6y8siiwxaNVbpGnYudchqa3u

Prior conversation

question:

how can gas_used be higher than attached_gas and still the Tx is successful?

answer:

Attached gas is what gets preallocated for execution, it is 10Tgas exactly for this transaction, and the execution itself burned 9.9Tgas, but there is also a cost of the transaction itself, and it is 2.2Tgas in this case, so in total that is 9.9+2.2 ~= 12Tgas

question:

so where does the extra gas come from if it's not attached?

answer:

we have constant gas cost for the Actions, it seems that FunctionCall action with that size (in bytes) of input arguments costs 2.2 Tgas. Thus, the transaction prepays 10 + 2.2 Tgas, where 10 Tgas is attached for future execution and 2.2 Tgas is known ahead of time.

[mikedotexe]

Yeah, that's still confusing to me after reading it twice. I think a detailed table is useful here. Either we show all the information or only the essential information, "NEAR tokens, It succeeded" This seem to be somewhere in between. Table could have:

• gas price
• gas per action
• number of actions in transaction etc…

[janedegtiareva]

I would definitely rewrite this as well. Can we try to explain it maybe as "fixed component" and "variable component" or something like this?

[ilblackdragon]

I think the easiest way is for our RPC to return gas attached as the amount really attached + the action cost. Like right now transfers are attaching 0 but there is non-zero action cost.

Also looking at this https://explorer.nearprotocol.com/transactions/EfTrMgg6gd1mwfyuK66Tz9D3ezQxkcrjEiT76TouXhPd I thought we are already doing it, as Transfer doesn't take attached gas.

We can also in UI show more detailed per action costs as a separate things.

For documentation - we should have a page dedicated to gas costs, which includes Action gas costs, instruction costs, byte costs etc. Ideally it should be generated out of our Fee config.

[frol]

@ilblackdragon What you describe can be implemented on Explorer side, and currently implemented per your comment:

gasAttached - that either == to gasUsed for non FunctionCall actions or equal to attached gas in the FunctionCall Action.

I guess, we should update that to:

gasAttached should accumulate gas for FunctionCalls and gas_burnt for other action types.

This way, Attached Gas is going to be 10 Tgas + 2.2 Tgas (12.2 Tgas) for this transaction.

WDYT?

[bowenwang1996]

@frol in that case maybe it shouldn't be called gasAttached? It seems to me that gasAttached would specifically mean the gas attached to the transaction (but doesn't include the constant cost of the actions).

[frol]

Any suggested name? Do we need this aggregated value at all?

[bowenwang1996]

I am not sure, but it seems that the confusion comes from the fact that attached gas is smaller than gas used. If that is the case we might want to display the aggregated value.

[frol]

I vote for the following plan:

1. remove attached gas from the transaction details card
2. display the attached gas and burned gas per action (this requires mapping between Action and Receipt; @bowenwang1996 is there a way to map a Receipt to an Action?)

[bowenwang1996]

@frol No because not every action would generate receipts and for those that do, I don't think it is possible to map it back to actions.

[frol]

@icerove Why do you think it is resolved?