Discussion: Integrate deployed contract address

[0xjjpa]

Background

Right now, the deployment of contracts includes both the types and the artifacts (e.g. ABIs) needed to interact with the smart contract. Unfortunately, the deployed contract address is still something that has to be tracked manually somehow, either via documentation or via some proxy registry. I brought up this topic to @PaulRBerg on the following tweet, and documentation was brought again, but I feel it's not really a full solution (e.g. I tried to play around with the hifi-protocol contracts and I couldn't find the address in the repository's README for any network).

What's the problem?

I'm trying to refactor the way scaffold-eth uses the smart contracts in the front-end to highlight the benefits of hardhat-packager (see @austintgriffith's tweet). Right now it expects a tightly coupled monorepo where artifacts are easily built or assembled within the front-end, but more often than not, this isn't the case. This is a great example of how hardhat-packager can help by getting the contracts into a neatly npm package.

That being said, while trying to add hardhat-packager, I realized that the smart contract address was written into the file disk after deployment, and then fetched in the front-end. Unfortunately, hardhat-packager has no mechanisms to write the contract address on file disk or provide the front-end with a way to fetch the deployed and thus, need further work on top of the types and ABI import.

Describe the feature you'd like to discuss

I would like to open a discussion about how to tackle the problem in question. Here are some ideas:

• Provide hardhat-packager with an additional task able to write a deployed contract address into file disk so it's also tracked as part of the npm package.
• Provide hardhat-packager with the ability to use a Singleton Factory approach to either fetch or deploy the bytecode to a specific network.
• Provide hardhat-packager with a proxy-like (e.g. ERC1820Registry) smart contract that can keep track of the contract addresses given a specific contract.

I'm aware that hardhat-packager isn't necessarily the best place to solve this, and I envision some hardhat.config.ts with another plugin could look something like this:

import "@typechain/hardhat";
import "hardhat-packager";
import "hardhat-deployer";
import "hardhat-registry";

where packager makes sure you have all the contracts' types/artifacts, deployer ensures they are deployed to a given network, and registry registers the address being used to fetch a specific contract version.

Looking forward to some feedback, thanks!

[PaulRBerg]

I tried to play around with the hifi-protocol contracts and I couldn't find the address in the repository's README for any network.

The addresses are on docs.hifi.finance, a website which is referencend at the top of the README.

Unfortunately, hardhat-packager has no mechanisms to write the contract address on file disk or provide the front-end with a way to fetch the deployed

This is true, but this tool was never meant to handle addresses. Actually, it is not meant to handle everything that may go into an npm package. It's just that the artifacts and the TypeChain bindings that I was concerned about. I couldn't think about a better name to capture what this tool does - I considered hardhat-preparator, but it sounded weird.

an additional task

The problem is that the same set of artifacts and Solidity ode could be mapped to (1) multiple networks and (2) multiple deployments. The hypothetical additional task would have to handle these possibilities and let the user provide the chain id, the rules for how an overriding deployment should be handled, etc.

the ability to use a SingletonFactory

There is no one-size-fits-all solution. It is common for factory users to fork other factory contracts and add functionality on top. Additionally, there are all sorts of edge-case scenarios, like upgradeable proxies being deployed with OpenZeppelin's hardhat-upgrades.

proxy-like (e.g. ERC1820Registry)

This is interesting. I will think about whether I can add support for something like this without compromising on user experience. Perhaps via an optional flag.

[PaulRBerg]

How do you envisage the addresses become part of the npm package, @jjperezaguinaga?

Couple of ideas:

• addresses.json file at the root of the project
• addresses directory, then CHAIN_NAME.json file per chain
• addresses directory, then CHAIN_NAME directory, then VERSION_NAME file per version

Also:

• Should the CLI prompt the user to enter the deployed contracts' addresses?

[0xjjpa]

@PaulRBerg sorry only got back to you now, replying to previous comments as well.

You are totally right that there's no one-size-fits-all solution, and having now worked a bit more in other projects I see that everyone has their own ways to manage their deployments addresses. I did check out your suggestion for hardhat-ignition but you are totally right that it's a batteries-included sort of solution.

The way we solved these whole artifacts vs chain vs version at @hoprnet was by creating versions on the networks and separated via folders within our repository. In our case we need to deploy multiple "instances" of our contracts because we want a clean slate every "release", if that makes any sense.

To do so we,

• First versioned each smart contract within our package.json
• Used that version during deployment as a salt
• Executed deterministic deployments that use create2 under the hood

You can see the deployment script if that helps somehow... We also have something even more complicated to allow multichain, multi-instance smart contracts, but that's unlikely to be something anyone else really needs.

Answering your particular question, I like the second approach: /address/CHAIN_NAME.json. I would imagine that a specific major version would work with any minor and patch npm package given that particular deployment, so if cat ~/[email protected]/lib/address/polygon.json returns 0x111 then I would expect cat ~/[email protected]/lib/address/polygon.json to return 0x111 but cat ~/[email protected]/lib/address/polygon.json to return 0x222. That's maybe an "unspoken" convention, but it gives at least some reference to developers to know "oh, this npm package can interact with this smart contract".*

* As mentioned we did something more complicated and put a map of releases inside our monorepo.

[PaulRBerg]

Thanks for sharing more details. I will keep this feature on hold until we agree what are the best practices here 😬

It is also the case that when one uses a solution like deterministic-deployment-proxy, separating addresses by CHAIN_NAME doesn't make much sense. The addresses would be the same across all chains.

There's a lot of different ways to handle deployments.