Overridden gas price does not work in London fork

[ZumZoom]

solidity-coverage/lib/api.js

Line 55 in 3c0f3a5

this.gasPrice = 0x01;

Solidity-coverage overrides gasPrice and sets it to 1 wei. This behaviour was acceptable before London hardfork but now coverage fails with
Transaction gasPrice (1) is too low for the next block, which has a baseFeePerGas of 73433802882

I understand the reasoning behind overriding gas and blockGasLimit, but I think gasPrice should not be overridden anymore.

[PaulRBerg]

Hey @cgewecke! Sorry to tag you, but this seems to be an urgent issue. Any chance you could remove the this.gasPrice = 0x01 line and ship a fixed version of solidity-coverage?

We'd all be very grateful.

[alcuadrado]

One possible workaround would be to use set the initial base fee per gas to 0.

networks: {
    hardhat: {
      initialBaseFeePerGas: 0
    }
  }

There's a small chance of this not working, but I think it'd work in most of the cases.

[PaulRBerg]

Another workaround is to set an environment variable as a flag and regress to the berlin hardfork in your Hardhat Network configuration when that flag is set. E.g. how I do it in my solidity-template:

hardhat: {
  hardfork: process.env.CODE_COVERAGE ? "berlin" : "london",
}

Of course, this is not great, because running test coverage on different EVMs might produce different results. But it's good enough as a temporary solution.

[alcuadrado]

There's a small chance of this not working, but I think it'd work in most of the cases.

I should have given more info here. This may not work because sendings txs that use more than 50% of the block gas limit would result in the next block having a larger base fee. Most the time, given the math of eip1559, this would still result in the next base fee being 0 or 1. But if this happens for a few blocks in a row, it may result in base fees greater than 1, and the og problem will happen.

[MoMannn]

👍

[wighawag]

I am getting a similar error but in my case this seems to be coming from hardhat, these lines : https://github.com/nomiclabs/hardhat/blob/4b8cd1b3bea89212ca6b73ea2660fc466383cf43/packages/hardhat-core/src/internal/core/providers/gas-providers.ts#L45-L53

which set the gasPrice to 1.

interestlingly it happen only when running solidity-coverage

[wighawag]

Oh nevermind, this is actually the same thing, did not realise what solidity-coverage was doing

[cgewecke]

This is patched with @alcuadrado's initialBaseFee fix (comment above) in 0.7.17. (Thank you!!!)

(Closing for the moment ... might need to revisit this I guess)

[cgewecke]

Actually, I'm going to leave this open for a bit so it's easy to find because it's so gnarly.

[pedroyan]

Even after I configured the initialBaseFeePerGas property to 0 as @alcuadrado suggested, the problem still persists.

I'm using 0.7.20 for my tests. I think it might be relevant to keep this open to bring visibility to the community?

[cgewecke]

@pedroyan This is now being done automatically as well and the tool works with the London HF without additional config. Is it possible it's being reset somewhere else in your code?

[pedroyan]

Not that I'm aware of - I did some digging before replying and couldn't find a place where we are resetting this value. I will keep digging and see why this might be happening.

Network Info
============
> HardhatEVM: v2.9.2
> network:    hardhat


Version
=======
> solidity-coverage: v0.7.20

Also - I'm using the typescript template provided by Hardhat

[cgewecke]

@pedroyan To be clear you seeing an error that specifically mentions the gas price and the baseFeePerGas? Something like:

Transaction gasPrice (1) is too low for the next block, which has a baseFeePerGas

[pedroyan]

Yeah. Here is the error:

Transaction gasPrice (1) is too low for the next block, which has a baseFeePerGas of 7

[cgewecke]

@pedroyan I see OpenZeppelin's coverage passing in CI (they are on 2.9.1) and aren't setting the base fee in their config: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/3fb25b604bda2af48bab75b8d9179b8ed3b7b87c/hardhat.config.js#L70

And our tests are passing on 2.9.3 in #706. If you have a way to repro this will reopen though.

[pedroyan]

@cgewecke you can find the repro here. Let me know if you have any troubles using it.

I've added some notes with my hypothesis as to why this is happening.

If someone is also facing the same problem, here is the workaround I'm using while I can't get to the root cause of the problem:

networks: {
    hardhat: {
      hardfork: process.env.IS_COVERAGE ? 'berlin' : 'arrowGlacier',
    },
}

[cgewecke]

@pedroyan Still need to investigate this a bit - have opened it as a separate issue and will track in #707. Thanks for the repro, perfect!