Dynamic gas value for special opcodes

[Aniket-Engg]

At present, on event 'step', data for the opcode is getting fetched from the file statically here. but for some opcodes like SSTORE, gas calculation is done dynamically.

This would be great if opcode data can return dynamically calculated fee for such opcodes.

CC: @yann300

[s1na]

Hm, I think the easiest way we could do this is to measure remaining gas after the step, and subtract it from the previous gas remainder.

In future we should have a dynamic gas calculator for each of the opcodes and need it, and we can return the result of this function for the step event.

[Aniket-Engg]

Hm, I think the easiest way we could do this is to measure remaining gas after the step, and subtract it from the previous gas remainder.

This looks fine for time being.

[Aniket-Engg]

Can a timeline be suggested for this? We have multiple issues depending on it.

[s1na]

I guess you can already do what I suggested. Each step event has the gasLeft property which you could compare to the previous event's gasLeft to calculate how much gas in total was spent for this instruction.

[alcuadrado]

Each step event has the gasLeft property which you could compare to the previous event's gasLeft to calculate how much gas in total was spent for this instruction.

Should we implement this as a temporal fix? If we don't give a solution and people start doing this themselves, it would be hard to change it later. What do you think @s1na @holgerd77 ?

BTW, @cgewecke you may run into this same issue.

[alcuadrado]

I was trying to implement this and realized that it's not possible to add this info to the step event without redoing some work in the VM.

We emit step before running the opcode, so we don't know how much it will spend. We may need to add afterStep. What do you think?

@Aniket-Engg can you tell us more about your use case so we can have a better understanding of what an afterStep event should have?

[Aniket-Engg]

@alcuadrado use case is to simply calculate the gas used in the execution of an opcode

[s1na]

We emit step before running the opcode, so we don't know how much it will spend. We may need to add afterStep. What do you think?

That's a good point. We could still compute the dynamic gas before executing the opcode. Opcodes that have a dynamic gas would need a pure function that given the input data (and probably some other parts of state) return needed gas. Geth is doing the same:

https://github.com/ethereum/go-ethereum/blob/aff986958da831d85788f33fe11aab31995ac072/core/vm/interpreter.go#L249-L259

But this is a bigger change than adding an afterStep and could maybe done later. Not sure. What do you think @alcuadrado?

[alcuadrado]

But this is a bigger change than adding an afterStep and could maybe done later. Not sure. What do you think @alcuadrado?

I agree with this.

I can implement it, but I'm not sure what other info that event should have.

[Aniket-Engg]

I think if there are not any other changes available to list in afterStep, this can be managed in the existing object with an extra field. So together, it can show "gasAssumed" & "gasUsed"

[s1na]

measure remaining gas after the step, and subtract it from the previous gas remainder.

I suggested this approach but I just it needs special handling around CALL/CREATE boundaries (i.e. when a new call frame with a different gasLimit can be started). Documenting for future reference. Also I guess it'd be nice to support this in the VM.

[holgerd77]

Will close in favor of #1169 (implementation in progress).