trufflesuite / truffle

:warning: The Truffle Suite is being sunset. For information on ongoing support, migration options and FAQs, visit the Consensys blog. Thank you for all the support over the years.
https://consensys.io/blog/consensys-announces-the-sunset-of-truffle-and-ganache-and-new-hardhat?utm_source=github&utm_medium=referral&utm_campaign=2023_Sep_truffle-sunset-2023_announcement_
MIT License
14.02k stars 2.32k forks source link

Error message "<Contract> ran out of gas..." is mistaken in some cases. #1655

Open elliotolds opened 5 years ago

elliotolds commented 5 years ago

Issue

Deployments can fail with the message " ran out of gas (using a value you set in your network config or deployment parameters.)" when the problem is actually that the bytecode is too long.

EIP 170 created the following consensus rule:

If block.number >= FORK_BLKNUM, then if contract creation initialization returns data with length of more than 0x6000 (214 + 213) bytes, contract creation fails with an out of gas error.

I'm not sure why Vitalik wanted the error to be "out of gas" here, but when a developer sees this it can waste a lot of their time. Truffle should check whether the size of the bytecode is > 24576 and if so return a more informative error.

Note that this is probably the root cause of https://github.com/trufflesuite/truffle/issues/1308 too.

Steps to Reproduce

Create a contract with a lot of code, such that the size of the bytecode when compiled is over 24576.

Run "truffle migrate"

Expected Behavior

The error should indicate that the bytecode is too large to deploy.

Actual Results

" ran out of gas (using a value you set in your network config or deployment parameters.)"

Environment

gnidan commented 5 years ago

The work here would be to intercept OOG exceptions and determine if the reason is EIP-170, not an actual out of gas error. This should be a fairly straightforward check to add on Truffle's side.

Thanks for suggesting this!

w5pand commented 5 years ago

The work here would be to intercept OOG exceptions and determine if the reason is EIP-170, not an actual out of gas error. This should be a fairly straightforward check to add on Truffle's side.

Thanks for suggesting this!

I have the same question,and i see "Ganache-cli" supported "EIP-170",but i prefer "Gananche". Is there a plan to add a setting to support for "EIP-170" in "Gananche"? It would be nice to have this setting.

wangxuw commented 5 years ago

Hi, I was trying to implement a decryption contract of AES algorithm and write the solidity code according to an C implementation version. And I encountered the same problem as below.

Deploying 'AES'
   ---------------
Error:  *** Deployment Failed ***

"AES" ran out of gas (using a value you set in your network config or deployment parameters.)
   * Block limit:  0x201c061
   * Gas sent:     6721975

    at /usr/local/lib/node_modules/truffle/build/webpack:/packages/truffle-deployer/src/deployment.js:364:1
    at processTicksAndRejections (internal/process/task_queues.js:86:5)
Truffle v5.0.9 (core: 5.0.9)
Node v11.13.0

I used the solc compiler to generate the OPCODE

       4    9082   49002 OPCODE.txt

and this is the wc output of the compiled OPCODE

Environment:

I have tried to use --allowUnlimitedContractSize flag but it seems only for debug use. The question is should I split the contract into two or more parts to successfully deploy? Or any other best practice?

cliffhall commented 4 years ago

Getting the same issue with ganache-cli 6.7.0. Same question. Split contract or abandon ganache?

gnidan commented 4 years ago

Best practice probably dictates that splitting up contracts is the right move... We had to do this internally inside Truffle's Assert.sol, for instance.

But, it depends on your use case. If you're targeting mainnet for future deployment, then you probably want to make sure that your contract fits inside the bounds dictated by EIP-170, etc. If you are targeting a private network without those limitations, well, I believe Ganache's settings cover that?

It looks like this issue is specifically related to error message + extra detection. Is there something else actionable here?