Support local artifacts in the Makefile

[nkuba]

Depends on: #3126

On developer machine contracts are deployed to local geth instance. We need to use them in the client, instead of downloading a package from NPM registry.

Here we add support for local artifacts. The make command will fetch the artifacts from local directories and use them for client build.

This is useful if a developer wants to generate bindings for locally deployed contracts.

What is more, the client will embed the addresses of locally deployer contracts, so running the client locally won't require setting the addresses in the configuration file or --developer flags.

The directories can be provided by the caller, e.g.:
make local local_threshold_path=/other/path/threshold

If the directories are not provided default paths are assumed:

local_beacon_path := ./solidity/random-beacon
local_ecdsa_path := ./solidity/ecdsa
local_threshold_path := ../../threshold-network/solidity-contracts
local_tbtc_path := ../tbtc-v2/solidity

[dimpar]

When we run Geth on our local we use the "development" name. But here we use "local" name to fetch the artifacts for the "development" env and in the logs I see:

Environment          local

even though the installation scripts run for "development". Do you think we can stick to "development" name in this case?

[nkuba]

Network and environment names got confusing. We've got following networks in hardhat:

• hardhat (default) - local hardhat node
• development - local geth node
• goerli - public test network
• mainnet - public main network

To use contracts packages as dependencies during the development, in the CI we build artifacts and publish them to NPM tagged development. These artifacts can be used as compiled artifacts but we cannot use the addresses to call them, as they were deployed to internal CI's hardhat node during the CI workflow execution.

In the client, we also pull those packages tagged development to build the client with the latest version of contract bindings.

An alternative path is when a developer wants to deploy contracts on their own machine and use the artifacts in the client. The network in hardhat they use is development, to not confuse it with the package the client already expects, I used the name local.

I'm open to straighten it up. But since renaming will have quite significant impact I'd like to have a broader discussion.

CC: @michalinacienciala @pdyraga

[dimpar]

I think it makes sense to have a development name for local geth node. It also was fine for the packages to be named development pre local geth node time. But yea, now it's a bit confusing.

I would rename development npm packages to ex. integration since they run on CI and drop the development package name. However, I'm not sure how much time and effort it takes to do it.

Maybe we can start smaller, and change the logs from Environment: local -> development and add the explanation in the comments?

[nkuba]

We could rename the development network in the hardhat.config.ts in all projects to local. The package we publish to the NPM Registry will still be tagged development.
WDYT @michalinacienciala?

But let's not block this PR on that.

[nkuba]

7f95f56

[michalinacienciala]

We could rename the development network in the hardhat.config.ts in all projects to local. The package we publish to the NPM Registry will still be tagged development.
WDYT @michalinacienciala?

Sounds good to me, I prefer this from changing the names of the packages.

[nkuba]

#3157

[dimpar]

Tested by running installation scripts and building using make local local_threshold_path=../tmp/solidity-contracts local_tbtc_path=../tmp/tbtc-v2/solidity command. The keep-core client was started successfully by running the following command and no contract addresses were provided.

KEEP_ETHEREUM_PASSWORD=password go run . start --ethereum.url ws://localhost:8546 --ethereum.keyFile /Users/dp/ethereum/data/keystore/UTC--2019-08-27T11-40-44.016554000Z--407190f04d838ec47dad4c0e0d2a9c49d7737479 --storage.dataDir /Users/dp/.keep/keep-core/storage/client-v2