Error: Deployment at 0x.. address is not registered

surfer77 · December 7, 2020, 3:26am

We are trying to prepare a contract for upgrade as we always do but get an error, here is our code:

VNFTxV4 = await ethers.getContractFactory("VNFTxV4");
  console.log("Preparing upgrade...");
  vnftxV4Address = await upgrades.prepareUpgrade(proxy, VNFTxV4, {
    unsafeAllowCustomTypes: true,
  });

Environment

Using hardhat-upgrades on osx

Details

the error I get is

Error: Deployment at address 0x4fEd51889672dcF22EDe6CD2421cF2aD74E1B287 is not registered

Code to reproduce

github.com

verynifty/vnftx/blob/master/scripts/deploy_mainnet.js

// scripts/deploy.js

const ACCESSORY = "0x47F42e4d4dE7EBF20d582e57ecd88ff64B2d7910";
MUSE_TOKEN = "0xB6Ca7399B4F9CA56FC27cBfF44F4d2e4Eef1fc81";
VNFT_CONTRACT = "0x57f0B53926dd62f2E26bc40B30140AbEA474DA94";
const proxy = "0x14d4D06B8e8df9B85A37D622aA95784a4FCcB130";
const RopstenProxy = "0x822b6eCB40467F1d3F4779814f323e19168C6E29";
const { ethers, upgrades } = require("hardhat");
const chalk = require("chalk");
const fs = require("fs");
async function main() {
  // const VNFTx = await ethers.getContractFactory("VNFTx");
  // console.log("Deploying VNFTx...");
  // const vnftx = await upgrades.deployProxy(
  //   VNFTx,
  //   [VNFT_CONTRACT, MUSE_TOKEN, ACCESSORY],
  //   {
  //     initializer: "initialize",
  //     unsafeAllowCustomTypes: true,
  //   }

This file has been truncated. show original

abcoathup · December 2, 2020, 3:46am

Hi @surfer77,

I am sorry that you are having this issue.

I reproduced by removing my <network_name>.json file.

$ npx hardhat run --network rinkeby scripts/prepare_upgrade.js
Preparing upgrade...
Error: Deployment at address 0x71a939282aE70747A30007a857c6D7B664554846 is not registered
    at Manifest.getDeploymentFromAddress (/home/abcoathup/projects/forum/surfer77/node_modules/@openzeppelin/upgrades-core/src/manifest.ts:55:13)

What network are you deploying to?
Is your <network_name>.json file checked in if it is a public network?
Is the previous implementation 0x4fEd51889672dcF22EDe6CD2421cF2aD74E1B287 listed in <network_name>.json?

surfer77 · December 2, 2020, 4:55am

Hi! we are trying to deploy to mainnet, the address you provided is not under implems, how should i add it?

It seems I am missing VNFTx3 in mainnet.json because not I was who deployed that version, I am trying to recreate it but any help is welcome as I don’t want to mess up the storage fields.

 "manifestVersion": "3.1",
 "impls": {
   "2576de311ef3c85ba4a60e05ae556342448e097e31b93a1a7516761c41593763": {
     "address": "0xaB03D275cc0a02b607992E5FD455Eb41aEd5fa91",
     "txHash": "0x8d3f3b1df52bfbf40d15f485ff25879745fece67e5d3a24183f39edf6050f561",
     "layout": {
       "storage": [
         {
           "contract": "Initiali```

abcoathup · December 2, 2020, 5:08am

Hi @surfer77,

First I recommend adding your public <network_name>.json files to version control: https://docs.openzeppelin.com/upgrades-plugins/1.x/network-files#configuration-files-in-version-control

This is used to check the upgrade safety of your contract when you prepare the upgrade.

I recommend creating higher level tests to test the upgrade from one version to another to check for upgrade safety.

You may be able to deploy the original version to a public testnet and then copy this to <network_name>.json and update the addresses. Though I would like to confirm that this is the best approach.

Jules_Dourlens · December 2, 2020, 11:26am

I made a duplicated post in same section and removed (we are on same project)

Yes we have the json file for first deployment and second version but missing the third.

Do you have any pointer on how is generated the keys for the impls object? I manage to recreate all the file but keys are different.

Also if we make sure about the storage order, could we just deploy the contract then call manually:
Function: upgrade(address proxy, address implementation)

or would there be potential issues?

Thanks

frangio · December 2, 2020, 9:52pm

The keys are the hash of the bytecode with the metadata part removed.

github.com

OpenZeppelin/openzeppelin-upgrades/blob/7cfc59650cd1b8f2c7615f4ecc791d162bec2e47/packages/core/src/version.ts#L27-L29


export function hashBytecodeWithoutMetadata(bytecode: string): string {
  return hashBytecode(trimBytecodeMetadata(bytecode));
}

Yes, that would be fine, if you check the storage order and your new contract is upgrade safe according to the plugin.

Do you have the source code for the version that is missing? I can take a look if there’s something we can do for you to properly register an implementation in your network file.

frangio · December 2, 2020, 11:16pm

Here is the issue for registering an implementation contract that is already deployed on chain:

I wasn’t able to implement it quickly, so I don’t know when we’ll be able to implement it.

abcoathup · December 7, 2020, 3:28am

Hi @Jules_Dourlens & @surfer77,

Just wanted to follow up and see if you were able to resolve?

abcoathup · December 16, 2020, 11:45pm

Hi @Jules_Dourlens & @surfer77,

We have found an error in Upgrades Plugins for Truffle and Hardhat. Users of the flag unsafeAllowCustomTypes should update their dependencies to the latest version.

See post for more details: Problem in Upgrades Plugins for users of unsafeAllowCustomTypes.

Jules_Dourlens · December 25, 2020, 5:30pm

Hey Thanks for reaching out, yeah I managed to make it back manually and we updated too for future releases
Thanks