hardhat icon indicating copy to clipboard operation
hardhat copied to clipboard

create2 fails with out of gas when linking library

Open sirpy opened this issue 2 years ago • 7 comments

I've encountered a strange issue. It happens only on hardhat network when running tests. If I run the hardhat VM manually and run a script it works fine. Also tested on a real EVM blockchain and it works fine. it also only happens when trying to deploy a contract with a linked library. Then there's out of gas error > 30000000. Running on latest hardhat/solidity 0.8.8.

I dont have sucint example. You can see the test case I did in our repo here (its the first test case): https://github.com/GoodDollar/GoodProtocol/blob/master/test/utils/ProxyFactory.test.ts

sirpy avatar Oct 04 '21 14:10 sirpy

It happens only on hardhat network when running tests. If I run the hardhat VM manually and run a script it works fine.

What do you mean by that? Do you mean that hh test fails, but if you start a node with hh node and then in another terminal you do hh test --network localhost then it does work?

fvictorio avatar Oct 04 '21 22:10 fvictorio

no, if I run HH node and then HH run script.js which does exactly what the test file does it works.

sirpy avatar Oct 04 '21 22:10 sirpy

Then what do you mean by "If I run the hardhat VM manually and run a script it works fine"? Can you give us precise reproduction steps (even if it means using your repo and not a minimal example)?

fvictorio avatar Oct 05 '21 11:10 fvictorio

@fvictorio it works perfectly fine in any case where I dont use the "hardhat" network. it works when deploying to a blockchain and it works when starting a local blockchain using "hardhat node" and then deploying for example via hardhat console --network dapptest where dapptest is defined as

dapptest: {
      gasPrice: 1000000000, //1 gwei
      url: "http://127.0.0.1:8545/"
    },

to reproduce checkout the project

yarn
npx hardhat test test/utils/ProxyFactory.test.ts

you will see that the first test passes, ie it tests for the existence of the bug. if you will run the same test code in console ie hh console --network dapptest it will work fine.

sirpy avatar Oct 05 '21 12:10 sirpy

I see, thanks for explaining. I wonder if this is the same underlying problem as in #1836.

fvictorio avatar Oct 05 '21 20:10 fvictorio

This issue was marked as stale because it didn't have any activity in the last 30 days. If you think it's still relevant, please leave a comment indicating so. Otherwise, it will be closed in 7 days.

github-actions[bot] avatar Jul 15 '22 18:07 github-actions[bot]

This issue was closed because it has been stalled for 7 days with no activity.

github-actions[bot] avatar Jul 22 '22 18:07 github-actions[bot]

Faced exactly same problem when trying to deploy a contract via create2 by hardhat run deploy.js (forked mainnet). Resolved by setting gas limit create2.deploy(bytecode, salt, {gasLimit: 9000000}) . Btw commenting out all console.log in the code also resolve this. Hope this helps

discoteq-cmd avatar Nov 15 '22 22:11 discoteq-cmd

Hey @sirpy, more than one year later but I guess that's better than never.

I think this is caused by #3469. You can check this comment for an explanation.

The workaround in this case is to use an explicit gas limit, or to explicitly call estimateGas and use that. For example, your test would become something like this:

  it("[@skip-on-coverage] [hardhat BUG] should deploy with linked library", async () => {
    const uf = await ethers.getContractFactory("UniswapV2SwapHelper");
    const uniswap = await uf.deploy();
    const Contract = await ethers.getContractFactory("CompoundStakingFactory", {
      libraries: { UniswapV2SwapHelper: uniswap.address }
    });

    const salt = 308932532;
    const gasEstimation = factory.estimateGas.deployCode(salt, Contract.bytecode);

    const tx = await (
      await factory.deployCode(salt, Contract.bytecode, {
        gasLimit: gasEstimation
      })
    ).wait();

    const event = tx.events.find(_ => _.event === "ContractCreated");
    expect(event).to.not.be.undefined;
  });

@discoteq-cmd I would guess you are running into the same problem, since the bytecodes sent to factories can get huge.

I'm going to close this in favor of #3469.

fvictorio avatar Dec 28 '22 21:12 fvictorio