Legacy opcode repricing

Each EVM opcode has an associated gas cost. Cost of the opcode is deducted. It is then multiplied by a given gas price, to give out the actual transaction fee the caller has to pay in ether. For times, core developers have find that certain opcode’s gas cost is too cheap, and it makes the chain vulnerable to attack. An attacker can execute a crafted transaction with vulnerable opcodes, pay a small amount of ether, and cause long execution time on all node implementations.

The solution to those kind of problem in the past is to raise those vulnerable opcode’s gas cost, for example, as we have done in EIP-150 and EIP-1884. Those type of raising hard forks sometimes also constitutes an emergency hard fork, because the issue must be fixed quickly, otherwise the attacker can halt the blockchain.

In the mean time, however, it is known that changes like this brings in potentially serious backward compatibility issues, for example, to cause a number of money-owning already-deployed smart contracts to break. The most recent event of this is EIP-1884 security analysis.

This is the problem this article tries to discuss and provide solutions for. How do we apply opcode repricing and emergency hard forks in a backward compatible way?

Account versioning is one of the most important solutions to solve backward compatibility issues. The following discussions about opcode repricing is based on that we already have account versioning 43-VER deployed, and we have already enabled a forward compatible EVM:

Note that any gas repricing on forward-compatible version will not affect backward compatibility with past contracts, as discussed in Addressing Gas Issues in Backward Compatibility.

Applying gas repricing directly on legacy version will cause backward compatibility issues, and the goal of this article is to explain a method to apply repricing without breaking anything.

Ultimately, the miner decides which transaction to be included on chain. Within those transactions are the EVM executions that takes time. A miner can tolerate a certain amount of execution time for all transactions in a block, for example, 1 second. If the time becomes longer, the miner loses time for mining, because it is still building the block, and thus loses rewards.

Users submit transactions of certain gas price, and miners determine transactions of which gas price to be included in a block. The miner ultimately will decide on a safe gas price P, where it would require all transactions to be above this value, and it can also raise or fall the block gas limit L_b, based on a safe block gas limit L.

We can roughly know that P * L is roughly the actual computation cost (in ether), where the value is roughly a constant at any given point of time. The computation time to execute L will be roughly the tolerable time to execute the block.

If we double, triple, or reduce it by half of all gas cost functions, the functionality does not change. For example, when we change all gas cost functions to be 1/2 of what it previously is, if a transaction previously consumes gas cost g, it now always consumes 1/2 * g. In the mean time, the safe gas price for a miner in the network will be raised to 2P, because now safe block gas limit for a rational miner becomes 1/2 * L, and safe gas price times safe block gas limit, which constitutes the actual cost in ether, does not change.

In other words, what is important for an opcode’s gas cost is how it is relative to other opcode’s. The absolute value of the gas cost does not affect functionality.

With the above, in this section we discuss how the actual gas repricing happens. The procedure is roughly like follows, considering we have two account versions (legacy version 0, and forward-compatible version 1).

We’re done! Now, miner’s safe block gas limit will be reduced by factor 1/F, and safe gas price will be increased by factor F. A hard reset of block gas limit can also be done together with the hard fork. Note that we did no change in legacy version, and as a result it is backward compatible.

By not changing the legacy version, it is backward compatible. By the effect on gas price and gas limit, the vulnerability is fixed in the legacy version.