Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deploy Bytecode Generated by --via-ir Failed #13311

Closed
hpumengzhao opened this issue Jul 28, 2022 · 1 comment
Closed

Deploy Bytecode Generated by --via-ir Failed #13311

hpumengzhao opened this issue Jul 28, 2022 · 1 comment

Comments

@hpumengzhao
Copy link

hpumengzhao commented Jul 28, 2022

I tested the bytecode generated by IR (compiler version is 0.8.15).

The source code is here: https://paste.ubuntu.com/p/rxH3snBD6Y/

I compile it with the following command to obtain the bytecode.

solc --optimize --bin --via-ir  AIOtherdeed.sol

I used Ganache (v2.6.0-beta.3) to be the local Ethereum environment.

The key part of my deploy script:

deployer_account = '0xEE244D1397baf270C8d9246Cce70B9879c6Bc0e4'
const PRIVATE_KEY = Buffer.from('33c8727299783362b188e150d3405d56314d5bf25896d598affdd1e5010de5a4', 'hex')

var contract = new web3.eth.Contract(ContractABI)

var test = contract.deploy({
    data: bytecode, 
    arguments: []
}).send({
    from: deployer_account, 
    gas: '6721975'
  }, function (e, contract){
   // console.log(e, contract);
   if (typeof contract.address != 'undefined') {
        console.log('Contract mined! address: ' + contract.address + ' transactionHash: ' + contract.transactionHash);
   }
}).then(instance => {
    console.log(instance.options.address)
})

The deployment was revert

  data: {
    '0x112039e3df20d578dd27904bee23abbcb264a20db6ebdd60b320fe1a40704074': {
      error: 'revert',
      program_counter: 351,
      return: '0x08c379a00000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000002e455243373231413a20636f6c6c656374696f6e206d75737420686176652061206e6f6e7a65726f20737570706c79000000000000000000000000000000000000',
      reason: 'ERC721A: collection must have a nonzero supply'
    },
    stack: 'RuntimeError: VM Exception while processing transaction: revert ERC721A: collection must have a nonzero supply\n' +
      '    at Function.RuntimeError.fromResults (C:\\Users\\23120\\AppData\\Local\\Programs\\Ganache\\resources\\static\\node\\node_modules\\ganache-core\\lib\\utils\\runtimeerror.js:94:13)\n' +
      '    at BlockchainDouble.processBlock (C:\\Users\\23120\\AppData\\Local\\Programs\\Ganache\\resources\\static\\node\\node_modules\\ganache-core\\lib\\blockchain_double.js:627:24)\n' +
      '    at runMicrotasks (<anonymous>)\n' +
      '    at processTicksAndRejections (internal/process/task_queues.js:93:5)',
    name: 'RuntimeError'
  }

But the constructor is

constructor(
) ERC721A("AI Otherdeed", "AIO", 100, maxSupply) {
}

where maxSupply is 4444.

The constructor of ERC721A:

  constructor(
    string memory name_,
    string memory symbol_,
    uint256 maxBatchSize_,
    uint256 collectionSize_
  ) {
    require(
      collectionSize_ > 0,
      "ERC721A: collection must have a nonzero supply"
    );
    require(maxBatchSize_ > 0, "ERC721A: max batch size must be nonzero");
    _name = name_;
    _symbol = symbol_;
    maxBatchSize = maxBatchSize_;
    collectionSize = collectionSize_;
  }

However, when I use the command

solc --optimize --bin AIOtherdeed.sol

to generate the bytecode. The bytecode can be deployed successfully.

Actually, I tested 50 real-world smart contracts from Etherscan and 5 of them couldn't be deployed.

Another finding is that the gas consumption of IR generator is higher than the legacy generator.

Update:

If I change

uint256 public  maxSupply = 4444;

to

uint256 public constant maxSupply = 4444;

IR generator works.

@hrkrshnn
Copy link
Member

hrkrshnn commented Jul 29, 2022

The difference is documented in https://docs.soliditylang.org/en/v0.8.15/ir-breaking-changes.html#semantic-only-changes

This is due to the order of initialization of maxSupply, in the IR pipeline the variable is initialized at towards the end. So in the constructor, the value getting read is zero.

Closing this for now. Feel free to reply if you have questions.

petermetz added a commit to petermetz/cacti that referenced this issue May 22, 2023
…et exchange

1. Without having it pinned to v0.8.8, some breaking changes that solc
has snuck in [1][2] around v0.8.15 (for IR) are breaking the contract
deployment in a way that opcodes end up in the migration contract's
constructor that Besu does not recognize ("opcode INVALID" in the besu
logs if you set the log level to "ALL") in the Besu logs and then sends
back an "internal error" message via the JSON-RPC response, which is a
bug IMO it should state that the user input was invalid (user input
being the contract)
2. Disabled IR in the truffle (solc) config which is a step backwards
because it's a new feature of the solidity compiler that has certain
benefits to it compared to the legacy compilation mode, but enabling it
breaks the build so it just had to be done. In the future if someone
has time to do a deep dive on why exactly it's failing, then it should
be re-enabled because having the legacy compilation mode being our default
is technical debt that should be paid off rather sooner than later because
we never know how it will come back to cause different issues later on.

When IR is enabled, the following error occurs (even on the pinned v0.8.8 solc):
> Compiling ./contracts/transferInterface.sol
> YulException: Variable var_amount_3290 is 9 slot(s) too deep inside the stack.

[1]: https://docs.soliditylang.org/en/v0.8.15/ir-breaking-changes.html#semantic-only-changes
[2]: ethereum/solidity#13311 (comment)

Fixes hyperledger-cacti#2423

Signed-off-by: Peter Somogyvari <[email protected]>
petermetz added a commit to petermetz/cacti that referenced this issue May 22, 2023
…et exchange

1. Without having it pinned to v0.8.8, some breaking changes that solc
has snuck in [1][2] around v0.8.15 (for IR) are breaking the contract
deployment in a way that opcodes end up in the migration contract's
constructor that Besu does not recognize ("opcode INVALID" in the besu
logs if you set the log level to "ALL") in the Besu logs and then sends
back an "internal error" message via the JSON-RPC response, which is a
bug IMO it should state that the user input was invalid (user input
being the contract)
2. Disabled IR in the truffle (solc) config which is a step backwards
because it's a new feature of the solidity compiler that has certain
benefits to it compared to the legacy compilation mode, but enabling it
breaks the build so it just had to be done. In the future if someone
has time to do a deep dive on why exactly it's failing, then it should
be re-enabled because having the legacy compilation mode being our default
is technical debt that should be paid off rather sooner than later because
we never know how it will come back to cause different issues later on.

When IR is enabled, the following error occurs (even on the pinned v0.8.8 solc):
> Compiling ./contracts/transferInterface.sol
> YulException: Variable var_amount_3290 is 9 slot(s) too deep inside the stack.

[1]: https://docs.soliditylang.org/en/v0.8.15/ir-breaking-changes.html#semantic-only-changes
[2]: ethereum/solidity#13311 (comment)

Fixes hyperledger-cacti#2423

Signed-off-by: Peter Somogyvari <[email protected]>
sandeepnRES pushed a commit to petermetz/cacti that referenced this issue May 30, 2023
…et exchange

1. Without having it pinned to v0.8.8, some breaking changes that solc
has snuck in [1][2] around v0.8.15 (for IR) are breaking the contract
deployment in a way that opcodes end up in the migration contract's
constructor that Besu does not recognize ("opcode INVALID" in the besu
logs if you set the log level to "ALL") in the Besu logs and then sends
back an "internal error" message via the JSON-RPC response, which is a
bug IMO it should state that the user input was invalid (user input
being the contract)
2. Disabled IR in the truffle (solc) config which is a step backwards
because it's a new feature of the solidity compiler that has certain
benefits to it compared to the legacy compilation mode, but enabling it
breaks the build so it just had to be done. In the future if someone
has time to do a deep dive on why exactly it's failing, then it should
be re-enabled because having the legacy compilation mode being our default
is technical debt that should be paid off rather sooner than later because
we never know how it will come back to cause different issues later on.

When IR is enabled, the following error occurs (even on the pinned v0.8.8 solc):
> Compiling ./contracts/transferInterface.sol
> YulException: Variable var_amount_3290 is 9 slot(s) too deep inside the stack.

[1]: https://docs.soliditylang.org/en/v0.8.15/ir-breaking-changes.html#semantic-only-changes
[2]: ethereum/solidity#13311 (comment)

Fixes hyperledger-cacti#2423

Signed-off-by: Peter Somogyvari <[email protected]>
sandeepnRES pushed a commit to hyperledger-cacti/cacti that referenced this issue May 30, 2023
…et exchange

1. Without having it pinned to v0.8.8, some breaking changes that solc
has snuck in [1][2] around v0.8.15 (for IR) are breaking the contract
deployment in a way that opcodes end up in the migration contract's
constructor that Besu does not recognize ("opcode INVALID" in the besu
logs if you set the log level to "ALL") in the Besu logs and then sends
back an "internal error" message via the JSON-RPC response, which is a
bug IMO it should state that the user input was invalid (user input
being the contract)
2. Disabled IR in the truffle (solc) config which is a step backwards
because it's a new feature of the solidity compiler that has certain
benefits to it compared to the legacy compilation mode, but enabling it
breaks the build so it just had to be done. In the future if someone
has time to do a deep dive on why exactly it's failing, then it should
be re-enabled because having the legacy compilation mode being our default
is technical debt that should be paid off rather sooner than later because
we never know how it will come back to cause different issues later on.

When IR is enabled, the following error occurs (even on the pinned v0.8.8 solc):
> Compiling ./contracts/transferInterface.sol
> YulException: Variable var_amount_3290 is 9 slot(s) too deep inside the stack.

[1]: https://docs.soliditylang.org/en/v0.8.15/ir-breaking-changes.html#semantic-only-changes
[2]: ethereum/solidity#13311 (comment)

Fixes #2423

Signed-off-by: Peter Somogyvari <[email protected]>
barnapa pushed a commit to barnapa/cacti that referenced this issue Jun 15, 2023
…et exchange

1. Without having it pinned to v0.8.8, some breaking changes that solc
has snuck in [1][2] around v0.8.15 (for IR) are breaking the contract
deployment in a way that opcodes end up in the migration contract's
constructor that Besu does not recognize ("opcode INVALID" in the besu
logs if you set the log level to "ALL") in the Besu logs and then sends
back an "internal error" message via the JSON-RPC response, which is a
bug IMO it should state that the user input was invalid (user input
being the contract)
2. Disabled IR in the truffle (solc) config which is a step backwards
because it's a new feature of the solidity compiler that has certain
benefits to it compared to the legacy compilation mode, but enabling it
breaks the build so it just had to be done. In the future if someone
has time to do a deep dive on why exactly it's failing, then it should
be re-enabled because having the legacy compilation mode being our default
is technical debt that should be paid off rather sooner than later because
we never know how it will come back to cause different issues later on.

When IR is enabled, the following error occurs (even on the pinned v0.8.8 solc):
> Compiling ./contracts/transferInterface.sol
> YulException: Variable var_amount_3290 is 9 slot(s) too deep inside the stack.

[1]: https://docs.soliditylang.org/en/v0.8.15/ir-breaking-changes.html#semantic-only-changes
[2]: ethereum/solidity#13311 (comment)

Fixes hyperledger-cacti#2423

Signed-off-by: Peter Somogyvari <[email protected]>
barnapa pushed a commit to barnapa/cacti that referenced this issue Jun 15, 2023
…et exchange

1. Without having it pinned to v0.8.8, some breaking changes that solc
has snuck in [1][2] around v0.8.15 (for IR) are breaking the contract
deployment in a way that opcodes end up in the migration contract's
constructor that Besu does not recognize ("opcode INVALID" in the besu
logs if you set the log level to "ALL") in the Besu logs and then sends
back an "internal error" message via the JSON-RPC response, which is a
bug IMO it should state that the user input was invalid (user input
being the contract)
2. Disabled IR in the truffle (solc) config which is a step backwards
because it's a new feature of the solidity compiler that has certain
benefits to it compared to the legacy compilation mode, but enabling it
breaks the build so it just had to be done. In the future if someone
has time to do a deep dive on why exactly it's failing, then it should
be re-enabled because having the legacy compilation mode being our default
is technical debt that should be paid off rather sooner than later because
we never know how it will come back to cause different issues later on.

When IR is enabled, the following error occurs (even on the pinned v0.8.8 solc):
> Compiling ./contracts/transferInterface.sol
> YulException: Variable var_amount_3290 is 9 slot(s) too deep inside the stack.

[1]: https://docs.soliditylang.org/en/v0.8.15/ir-breaking-changes.html#semantic-only-changes
[2]: ethereum/solidity#13311 (comment)

Fixes hyperledger-cacti#2423

Signed-off-by: Peter Somogyvari <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

No branches or pull requests

2 participants