buidler-deployments plugin

[alcuadrado]

We should offer some functionality to preserve deployments' information between Buidler executions.

One possible solution is to create a plugin that extends the Buidler Runtime Environment with an object containing (at least) these two methods:

• getDeployedContracts: Receives a TruffleContract and returns an array of contract instances. This method should warn if the deployed contract's bytecode doesn't match the local's one.

• saveDeployedContract: Receives a contract instance, and saves its address. This method should warn if the contract was deployed to a testing/temporal network.

Under the hood, these methods should work with a JSON file looking something like this:

interface DeploymentsFile {
  [chainId: number]: {
    [contractName:string]: string[] // the addresses 
  }
}

Any operation involving reading & updating that file has to be synchronous, and, if possible, atomic.

Once we have this plugin, deployment scripts could be written in this fashion:

let [token] = await deployments.getDeployedContracts(Token);
if (token === undefined) {
   token = await Token.new();
   await deployments.saveDeployedContract(token);
}

let [other] = await deployments.getDeployedContracts(Other);
if (other === undefined) {
   other = await Other.new(123, token.address);
   await deployments.saveDeployedContract(other);
}

Writing them this way has the advantage of the scripts being resumable. If, for example, deploying Other fails because 123 wasn't a valid parameter, you can correct it and re-run the script without having to re-deploy the Token`.

Finally, other things that we should consider:

• We should also have some methods to "forget" about a certain contract.
• Should we store the deployment parameters?

[wighawag]

Hey,
You might want to checkout rocketh (https://github.com/wighawag/rocketh) it was optimized for a seamless deployment flow.

I am starting to look at buidler to see if i could implement the same functionality in plugins but I am not sure yet

rocketh supports the following thing :

• stages (aka migrations in truffle parlance) that are run both for tests and deployment
  in test mode you can re-run them so your test can always act on a blank state. No need to duplicate code.
• namedAccounts allow you to configure special account with name for each network.. Your tests can use them too. This make test more readable while preserving compatibility with deployment with real addresses.
• when a failure happen while waiting for a deployment to be mined, rocketh save the tx hash so you can resume even for this case. When the stages are re-run It will wait for that transaction to complete. If this tx never finish, you currently have to delete the pending state. planning to add a prompt.
• it saves a deployment file (only in non-test chain) that contains the solc output as well as the metadata. It also create a separate file for code verification that can be used as input for solc. These are meant to be stored on git and are used to check whether you want to redeploy a contract or not
• Indeed it supports redeploy only if changes were made (checking arguments and/or bytecode) allowing you to feel confident in running the whole stages on the mainnet.
• it supports bitski app wallet for deployment. You can have different wallet for the different networks

[wighawag]

Oh forgot to mention that it also support a keepRunning mode (running ganache or geth) using these features with the extra possibility of exporting the contract info (abi, address, [bytecode]) to an external file (path specified by user)

Very useful for local webapp development as you run it and then your contract are deployed and the info is available to your webapp

[pcowgill]

This feature is the main thing gating my project moving from Truffle over to Buidler.

[fvictorio]

Some thoughts on this.

Addresses location

One open question is where the addresses will be saved. I guess saving them in the artifacts directory makes sense. An alternative is to have a specific file for this. For example, the Gnosis team has a networks.json file in many of their projects (example). This file is versioned and also published to npm, which makes it easier to use in a different project:

const networks = require('my/project/networks.json')

console.log(networks["MyContract"]["1"].address

Of course, this can also be done with artifacts if you commit and publish them.

Multiple instances

The other question I have is how to manage multiple instances of the same contract. In the current proposal, it seems like each new address is added to an array. My problem with that is that working with that seems a little cumbersome: you are relaying on the order in which your original deploy script was written.

The other problem with this, in my opinion, is that it defaults to a complex object when in most cases contracts have only one instance. So I think a nice alternative approach would be using some kind of map, and returning a single address for the given key:

let token = await deployments.getDeployedContracts(Token);
if (token === undefined) {
   token = await Token.new();
   await deployments.saveDeployedContract(token);
}

let anotherToken = await deployments.getDeployedContracts(Token, 'otherToken');
if (token === undefined) {
   anotherToken = await Token.new();
   await deployments.saveDeployedContract(anotherToken, 'otherToken');
}

(This is just to illustrate the idea; I don't like that API for a couple of reasons that I won't detail because this is getting long enough already.)

The next question here is how to represent this on the artifacts/networks file.

Truffle

There's a feature request for this in Truffle since 2016, see ConsenSys-archive/truffle#237. They are also working on a proposal to solve this and other related issues. I haven't read this document in depth; the analysis looks interesting, but the proposal seems unnecessarily complex. I think the approach proposed in this issue covers a lot of ground and it's flexible enough.

[wighawag]

I started to work on a deployment plugin that already have most of the feature https://rocketh.io had :
https://github.com/wighawag/buidler-deploy

It override the builtin task to provide extra features. See github repo for more details

It is still work in progress and would be happy to get feedback,

[nfurfaro]

The "Deploying your Contracts" page of the Hardhat site says "When it comes to deploying, there are no plugins that implement a deployment system for Hardhat yet..."
https://hardhat.org/guides/deploying.html#deploying-your-contracts

This is misleading as you list Hardhat-deploy under the list of available Plugins.
Perhaps this could be updated?

[hashparty1]

Yes it almost makes it seem like Hardhat is discouraging the use of hardhat-deploy because it's so prevalent yet they act like it doesn't exist.

[Madeindreams]

Well I found that deploying contracts with ethers was fairly easy. So far I like how hardhat works with ethers. So I think it would only be a matter of passing the contract name down the line. I'm looking for a complete solution from compiling => deploying => verifying as well.

[alcuadrado]

I totally missed this, @nfurfaro, sorry about that. A lot changed since we first wrote that, and never updated it. How wants to send a PR updating it?

[outdoteth]

So is the consensus to use hardhat-deploy?