Consider different intrinsic-gas for fee-currencies in gas-estimation

[ezdac]

Problem

We don't consider the different intrinsic-gas costs for fee-currencies (FeeCurrencyDirectory determined) compared to a native transaction (21000) within the gas-estimation that is accessible via the eth_estimateGas RPC method.

Details

Issue 1

If a user would supply a gas parameter to the estimated transaction that is higher than 21000 but lower than the intrinsic gas for that fee-currency, the gas estimation would fail:

op-geth/eth/gasestimator/gasestimator.go

Lines 61 to 63 in 4eb43bc

	if call.GasLimit >= params.TxGas {
	hi = call.GasLimit
	}

This is because the EVM-call with a gas of the hi value is set as the upper bound of the binary search.

(Note that this is unlikely that clients do that, since the point of gas-estimation is to determine the gas value of a transaction.
However this parameter can be used to set the upper bound of the binary search)

Issue 2

Additionally, not considering the different intrinsic gas for fee-currency transactions will not work with the value-only transaction short-circuit:

op-geth/eth/gasestimator/gasestimator.go

Lines 129 to 140 in 4eb43bc

	// If the transaction is a plain value transfer, short circuit estimation and
	// directly try 21000. Returning 21000 without any execution is dangerous as
	// some tx field combos might bump the price up even for plain transfers (e.g.
	// unused access list items). Ever so slightly wasteful, but safer overall.
	if len(call.Data) == 0 {
	if call.To != nil && opts.State.GetCodeSize(*call.To) == 0 {
	failed, _, err := execute(ctx, call, opts, params.TxGas)
	if !failed && err == nil {
	return params.TxGas, nil, nil
	}
	}
	}

The gas estimation will still work as expected, but the node does more computation than necessary.

Proposed solution

In both mentioned cases, for fee-currency transactions the params.TxGas value should be substituted with the value of the fee-currencies intrinsic gas. This value should be queried from the FeeCurrencyDirectory chain-state prior. This is somewhat unfortunate because at that point there is no EVM-context initialized yet.