Add support for hardhat and hardhat-deploy artifacts and deployments.

[nlordell]

Since we are migrating more and more of our repositories to hardhat and hardhat-deploy, it would be nice to support this natively.

• Rename Artifact to Contract.
• Introduce struct Artifact.
• Implement loader for truffle format.
• Implement loader for hardhat export format.
• Decouple code generation from Truffle artifact. #196
• Allow generating contract bindings from an Artifact without needing the source json #170
• Rework Builder to work with Contract, implement ContractBuilder.
• Support artifact formats in macro.
• Merge and release ethabi.
• Merge feature branch into main.

[taminomara]

I want to look into this during Ecosystem Fridays maybe?

[taminomara]

I'll start with adding this to ethcontract-generate, then move on to macro.

[taminomara]

So, hardhat artefacts are structured differently from truffle artefacts. In hardhat, you get a list of contracts for each network, while in truffle it's a list of networks for each contract. This difference has two major impacts. First, in hardhat it's possible that a contract will have different ABIs on different networks. Second, we have a single json file containing all info about all contracts. So, potentially, we can generate multiple contracts with a single macro invocation.
I don't want to support contracts that have different ABIs on different networks, I think it's ok to fail compilation when we see this.

As for generating multiple contracts from a single macro invocation, I think this could be useful; we won't have to load and parse the same file multiple times. However, that will require changing the interface of both builder and macro.

I'm thinking about what a good interface will look like.

[nlordell]

I don't want to support contracts that have different ABIs on different networks, I think it's ok to fail compilation when we see this.

I also agree. I think having multiple contracts with different ABIs is a huge can of worms that I don't want to open.

Also, as long as we can have a way to specify a single deployment, we can techincally still support different ABIs on different networks by having multiple contract! macro invocations.

So, potentially, we can generate multiple contracts with a single macro invocation.

Just to make sure I understood correctly, would the suggestion be that we can specify multiple paths to JSON artifacts and then the network information would just be merged (erroring if non-mergable differences - such as different ABIs are encountered)?

[taminomara]

we can specify multiple paths to JSON artifacts and then the network information would just be merged

My line of thought was the following. One artifact (that is, one JSON file) may now export multiple contracts. Thus, we should be able to generate all of them in one go.

Merging data form different JSONs sounds interesting, I'll look into it.

[taminomara]

So, we have several formats for artifacts.

Truffle and Waffle:

1. one named contract with networks,
2. one unnamed contract with networks.

HardHat:

1. contracts for single network,
2. contracts for multiple networks.

With these in mind, I propose the following API.

In ethcontract-common:

• struct Contract -- info about a contract: its name, abi, and other things (what's currently known as truffle::Artifact),
• trait Artifact -- a storage for contracts. Allows looking up contracts by name and getting list of all contracts. It will have several implementations. Preliminarily, those are:
  • TruffleArtifact -- loads truffle artifacts,
  • WaffleArtifact -- loads waffle artifacts,
  • HardhatExport -- loads artifacts generated with hardhat --export,
  • HardhatMultiExport -- loads artifacts generated with hardhat --export-all,
  • HardhatDeployments -- lazily pulls contracts from deployments/ folder generated by hardhat (this will be done later).
• perhaps instead of having an Artifact implementation for every artifact format we'll have ArtifactLoaders instead. I'll see which approach is better.

In ethcontract-generate:

• Builder -- builds a single contract, allows changing contract's name, mod and other settings,
• helper functions to create a builder from path to an artifact (i.e. Builder::load_truffle),
• maybe helper functions to generate all contracts in an artifact.

Then build.rs may look like this:

let artifact = HardhatDeployments::new("deployments/")
    .unwrap();

Builder::new(artifact.contract("ContractName"))
    .generate()
    .unwrap()
    .write_to_file(Path::new(&dest).join("rust_coin.rs"))
    .unwrap();

Builder::new(artifact.contract("AnotherContractName"))
    .generate()
    .unwrap()
    .write_to_file(Path::new(&dest).join("rust_coin.rs"))
    .unwrap();

As for macros, I have a few ideas, but none that I'm satisfied with.

[nlordell]

I like the proposed abstractions, as it will make it easier to extend it and add new formats in the future.

[taminomara]

I want to move code that loads contracts from etherscan and other places from ethcontract-generate to ethcontract-common. It can be optional (under cfg). IMO it makes sense to keep all code for loading and parsing artifacts in one place.

[nlordell]

The issue with that is that it means that we would need to pull in curl even if it doesn't get used by ethcontract runtime. Maybe it makes sense to have a ethcontract-artifact crate that does all the Artifact loading and creating of Contract instances which is all that is needed by the runtime.

It also allows some of the JSON parsing code to move out of ethcontract-common which would be nice.

[taminomara]

I was thinking that we may enable curl support conditionally, via a feature flag (i.e. #[cfg(feature = "curl")]).

I'm not sure about ethcontract-artifact. If parsing JSON lives in ethcontract-artifact, then ethcontract users who want to deploy their contracts will have to use it. If parsing JSON lives in ethcontract-common, then it defeats the whole purpose of ethcontract-artifact. In any way, it sounds like a separate issue.

[nlordell]

The idea would be that Contract type, would continue to live in ethcontract-common, which will end up being the common type used by the underlying ethcontract::contract::Instances. This way, all the code for loading JSON artifact files, or retrieving from NPM, Etherscan, etc. as well as the Artifact implementations that take these JSON objects and generates Contract instances can live is ethcontract-artifact.

Then, hopefully, we could even make it so we can create a Contract instance in the generated contract code without requiring lazy_static and JSON parsing (which is what we currently do 😅).

[taminomara]

I see. Then I'll continue with the current structure for now, and we can implement this proposal later.

[taminomara]

This refactoring will also help with #209, #196 and #170.

[taminomara]

So I still don't have any nice API for a macro that could yield multiple contracts at once. So for now, I propose that we live the current macro API, just slightly modify it:

• add format setting,
• if artifact contains any named contracts, contract setting will be used to determine which contract to use. Otherwise, it sets a name for an unnamed artifact.
• add contract_rename setting that can be used to rename contracts.

Example:

contract!(
    pub "build/export.json",
    format = hardhat_multi,
    contract = WETH9,
   contract_rename = Weth,
);

[nlordell]

add format setting,

Would it be possible to try and autodetect this as well? Otherwise I like the format setting.

add contract_rename setting that can be used to rename contracts

We can also use as in a multi-contract context:

contract!(
    pub "build/export.json",
    format = hardhat_multi,
    contract = WETH9 as Weth,
);

[taminomara]

Would it be possible to try and autodetect this as well? Otherwise I like the format setting.

It's possible, but there are corner cases, and it will require parsing JSON into a Value and then exploring said value. Basically, "if source points to a JSON file, and there's abi field in said JSON, and ...". Although it could be useful. I'll add format, and we can add format = auto later.

We can also use as in a multi-contract context

Love it!

[nlordell]

Although it could be useful. I'll add format, and we can add format = auto later.

For sure, just another improvement idea to make the macro as ergonomic as possible.

[taminomara]

Maybe format = auto should take into account artifact source. If it's etherscan, we know format is raw ABI.

[taminomara]

Moved some tasks to separate issues: #514, #563, #564.