OpenZeppelin upgrades support for Optimism

Support Upgrades
1

Hi everyone!

I have a bunch of upgradeable smart contracts that I’m trying to deploy on a local layer 2 Optimism network. However, for some reason I get the following error when deploying:

{ Error: Invalid deployment with address 0xb3eFA799Fc9A17f2978f1e176F96880F285003b9 and txHash 0x2be60f45380138255ec4881e931243275c8cff72b63f91f3d91c21279cb2c86d
    at Object.waitAndValidateDeployment (/home/george/Development/project/node_modules/@openzeppelin/upgrades-core/src/deployment.ts:82:9)
    at process._tickCallback (internal/process/next_tick.js:68:7)
  deployment:
   { address: '0xb3eFA799Fc9A17f2978f1e176F96880F285003b9',
     txHash:
      '0x2be60f45380138255ec4881e931243275c8cff72b63f91f3d91c21279cb2c86d' } }

The deployment succeeds on layer 1. I suppose the upgrades plugin might not be support yet Optimism deployments. I would appreciate if anyone could give some feedback on this.

1 Like
2

Hi @George_Roman, thanks for reporting this. We haven’t tried deploying to an Optimism network. Can you let me know what version of the plugin and of the @openzeppelin/upgrades-core dependency you’re using? Is there a repository we could look at or instructions you could share for us to reproduce the issue? It will help a lot with understanding why this is failing.

1 Like
3

@frangio Thanks for responding. I’m using version 1.5.0 for hardhat-upgrades and version 1.4.4 for upgrades-core. I’ve set up an example repo where the issue can be reproduced (the issue can be reproduced by running the deployment script - one thing to note through is that usually the first time running on a clean network the deployment timeouts, only next runs triggering the exact same issue as here). Here is the example repo: https://github.com/georgeroman/example-ovm-integration.

1 Like
4

@George_Roman I haven’t had time to look into this yet, and I don’t know when I will be able to. But here are some pointers for you to look at…

If I’m not mistaken, what’s failing is that the plugin tries to validate one of the deployments it has made (could be ProxyAdmin, the implementation contract, or the proxy itself), by retrieving the code stored in the contract using eth_getCode. It seems that eth_getCode is returning an empty bytecode, which is strange, so the plugin sees the deployment as invalid. Everything else is normal: the transaction has gone through, it was mined, etc. But once we run eth_getCode the contract isn’t there.

I think this could happen on Layer 1 against Infura, because sometimes Infura nodes are out of sync and a transaction may have been mined in one node but the contract still be missing in another.

But there could be something else going on for Optimism. I would look into this: what reasons could there be for a contract creation transaction that we’ve confirmed has been mined, to not result in there being code at the address of the created contract, at least as we can see through eth_getCode.

Note that the error message includes the contract address which might help investigate.

3 Likes
5

@frangio Thanks a lot for the pointers, I’ll keep looking into this and keep the thread updated if I manage to land a fix.

1 Like