EVM Gas Interpretation
The gas model can be one of the most complex topics regarding the EVM bytecode interpreter, since there are two interacting executions supported at the same time. This document explain in more detail how the interpretation of the EVM gas works.
EVM bytecode interpreter execution flow
From the point of view of EraVM, the EVM interpreter is (almost) a regular EraVM contract. This contract is predefined and can be changed only during protocol upgrades. When an EVM contract is called, EraVM invokes the interpreter code. The interpreter loads the corresponding EVM bytecode and interprets it.
Thus, the interpretation is executed on top of EraVM, uses EraVM opcodes and, most importantly, pays for EraVM operations in native gas (ergs).
This means that ergs are used to pay for all operations on EraVM (and therefore on ZK Chains). Gas and gaslimit values signed in user's transactions are specified in ergs. All refunds are also made by the virtual machine in ergs.
EVM gas model interpretation
Full EVM gas equivalence is necessary to provide an EVM-compatible environment and meet the assumptions made in contracts. However, the cost of EraVM operations differs, and EVM interpretation requires multiple EraVM operations for each EVM operation. As a result, we interpret the EVM gas model.
As mentioned in the previous section, the EVM environment is virtual: it operates on top of EraVM and incurs costs for execution in EraVM ergs. The EVM interpreter, however, has its own internal gas accounting system that corresponds to the EVM gas model. Each EVM opcode consumes a predefined amount of gas, according to the EVM specification. And if there is insufficient gas for an operation, the frame will be reverted.
Ergs to gas conversion rate for gas limit
EVM gas units are not equivalent to EraVM ergs. And both the EVM and EraVM do not provide mechanisms for an EOA or contract to specify how to convert gas from one unit to another. For practical use in the interpreter, a predefined constant is used to convert gas limit from one unit to another.
This means that if a user made a call to an EVM contract with 100,000 ergs, the EVM interpreter will start execution with 20,000 EVM gas. At the same time, underlying EraVM will have all 100,000 ergs available for use and will refund any unused ergs at the end of the transaction.
In the other direction, when calling an EraVM contract from EVM context, if 20,000 gas is provided, the interpreter will try to pass 100,000 ergs (or less, if the amount of ergs left is not enough).
Out-of-ergs situation
Since EVM gas is virtual and does not map 1:1 to EraVM ergs, it’s possible for the interpreter to have sufficient EVM gas to continue execution
while still triggering an out-of-ergs panic at the EraVM level. In such cases, the interpreter raises a special internal panic and reverts
the entire EVM call stack.
This fact should be taken into account by smart contract developers:
Technically, this problem is similar to classic gas-griefing issues in EVM contracts, if not handled appropriately.