Precompile used gas

[ptrus]

A set of changes that were useful for us to implement a precompile that returns gas usage.

Changes:

• adds fn used_gas(&self) -> u64; to PrecompileHandle to support querying used_gas in precompiles
• propagates the "parent" used_gas into the precompiles (since precompile uses its own gasometer that starts at 0)
• minor typo fix Retreive -> Retrieve

Hope that none of these are too controversial.

[boundless-forest]

propagates the "parent" used_gas into the precompiles (since precompile uses its own gasometer that starts at 0)

I suspect this point. The precompile record_cost implementation like this: https://github.com/rust-blockchain/evm/blob/master/src/executor/stack/executor.rs#L1455-L1462, it uses the parent gasometer directly instead of creating a new one.

[ptrus]

Before executing the precompile a new StackSubstateMetadata with an empty gasometer is created here: https://github.com/rust-blockchain/evm/blob/7ac239a67b8e5075199052aef60fa025a389a612/src/executor/stack/executor.rs#L886

[boundless-forest]

Before executing the precompile a new StackSubstateMetadata with an empty gasometer is created here:

If I remember correctly, the executor will make all tx gas limit as used_gas at first, then reduce this value when executing the opcode or precompile one by one. The gasometer will swallow_commit to edit the accumulated used gas when exiting the executor, search self.gasometer.record_stipend(other.gasometer.gas())?; in the code base. @sorpaas Please help confirm this.

[ptrus]

If I remember correctly, the executor will make all tx gas limit as used_gas at first, then reduce this value when executing the opcode or precompile one by one. The gasometer will swallow_commit to edit the accumulated used gas when exiting the executor, search self.gasometer.record_stipend(other.gasometer.gas())?; in the code base. @sorpaas Please help confirm this.

I believe this is all true as stated. However, this seems a bit tangential to the changes introduced in the PR and doesn’t alter the established behavior.

Breaking down the PR:

• It allows querying 'used_gas' from within the precompiles. (This commit)
• Since the precompile uses its own gasometer, we propagate the parent's used gas into the precompile to accurately respond to the 'used_gas' query. We capture the parent's used gas before the mentioned: "executor will make all tx gas limit as used_gas" step is executed. (This commit)

[sorpaas]

It allows querying 'used_gas' from within the precompiles. (This commit)

Would you mind to explain more this use case? This seems to be about querying the internal state of the actual running machine, so I'm wondering if we should just make a new opcode instead.

Precompiles have rather defined semantics -- they are essentially external code, but following all other rules of a normal call stack. For example, they are supposed to also work with CALLCODE/DELEGATECALL. They are supposed to properly OOG like a normal call stack. We can use it for pure functions. We can use it for dynamic functions (with the caveats that you might want to disallow the case when code_address does not equal to context.address). But for other use cases we might just well create a new opcode.

But...

if you really want to go with this route -- the next branch allows this to work. We generalized the runtime state there. So what you do is that you'll create a new struct implementing AsMut<RuntimeState> (wrapping the existing RuntimeState). Then you just pass the parent_used_gas there, and it'll be accessible in the precompile.