OpenZeppelin / openzeppelin-upgrades

Plugins for Hardhat and Foundry to deploy and manage upgradeable contracts on Ethereum.
MIT License
621 stars 266 forks source link

Document location of proxy address #270

Open abcoathup opened 3 years ago

abcoathup commented 3 years ago

The location of the proxy address isn't currently documented.

The following could be added to FAQs:

Proxy address is stored in the Truffle artifact of the first implementation contract. Proxy address in Hardhat is not stored as Hardhat doesn't currently have a built in deployment solution.

marsrobertson commented 3 years ago

Arriving here from: https://forum.openzeppelin.com/t/deploying-2-identical-contracts-and-referencing-them-in-the-future-upgrades/5287

I'm the original creator of that forum thread.

The proxy address is stored in the Truffle artifact of the first implementation.

This is not super obvious. Mixing proxy address with the address of the implementation.

Until recently I had build in .gitignore. Now, because the addresses are stored there, I need to keep build in my repo?

BUT

You can add the truffle build artifacts to version control, but please note Truffle artifacts include full paths.

Recommended solution

Keep all the Proxy addresses in .openzeppelin

Benefits:

  1. All in a single location
  2. No need to keep track of build
frangio commented 3 years ago

Hi @marsrobertson, it was a design decision to leave this out of scope of the plugins, which is why the proxy address is not stored in .openzeppelin. We expect users to track their proxy deployments in the same way that they track their non-proxy deployments, so it would not make sense for us to build a specific purpose proxy-tracking mechanism.

We could change this decision in the future, but so far I'm not convinced that it would be the right thing. Tracking deployments is a more general problem that affects non-upgradeable deployments as well.

marsrobertson commented 3 years ago

Thank you @frangio, makes a lot of sense.

Tracking deployments is a more general problem that affects non-upgradeable deployments as well.

Do you know any resources / articles / tutorials / best practices?


I think I can just hardcode address of the proxy right there:

// migrations/4_prepare_upgrade_boxv2.js
const Box = artifacts.require('Box');
const BoxV2 = artifacts.require('BoxV2');

const { prepareUpgrade } = require('@openzeppelin/truffle-upgrades');

module.exports = async function (deployer) {
  const box = await Box.deployed();
  await prepareUpgrade(box.address, BoxV2, { deployer });
};

Code coming from the tutorial: https://forum.openzeppelin.com/t/openzeppelin-upgrades-step-by-step-tutorial-for-truffle/3579

const BoxV2 = artifacts.require('BoxV2');
const { prepareUpgrade } = require('@openzeppelin/truffle-upgrades');

const HardcodedBoxProxyAddress = "0x85A363699C6864248a6FfCA66e4a1A5cCf9f5567";
module.exports = async function (deployer) {
  await prepareUpgrade(HardcodedBoxProxyAddress, BoxV2, { deployer });
};

(I can keep it config, settings, .env, wherever)

Beginner mindset, I'm here to learn 😇 I think that could work, I'll ask a computer.

frangio commented 3 years ago

Yeah you can also use a json file to store the addresses, and read the json file in your scripts. I'm not aware of any articles about this but I know that it's an active area where people are working to figure out the best patterns.