After a brief hiatus, I am back with a new installment in my Ethereum development series. Picking up where I last left off, let us dive into the development flow of deploying a contract to the blockchain with Hardhat.
My Opinionated Flow
The Command-Line is Your Friend
The hardhat command-line interface (CLI) is the engine that allows you to compile contracts, run scripts to interact with Ethereum nodes, trigger custom tasks, and run tests to simulate malicious transactions and plug any holes. Running npx hardhat will trigger the Hardhat engine and return a list of global commands and tasks that you can append to this command to tell it to run a certain way. The most common commands you will likely use are:
npx hardhat node- Starts up a local Hardhat Network node that emulates the Ethereum Mainnet.npx hardhat compile- Compiles your contracts into artifacts that are used by the network and client-side interaction.npx hardhat test- Runs through the mocha test scripts that are found in the test directory.npx hardhat run- Allows you to run Javascript files that can serve any purpose from running test transactions on Hardhat Network to deploying your contract to the Mainnet. Since Hardhat does not have a built-in deployment system at this time, the run command on a deployment JS file is required.
Anything that is executable in your development process will flow through the CLI so it is important to know how the system operates!
Side Note: If you are tired of constantly writing npx hardhat, there is a shorthand method, hh that can be used if you install the `hardhat-shorthand` package globally.
Contracts
Previously I focused on the Solidity language and the commonly used components in smart contracts. Now the focus is on how we take our contract and release it to the world. The process is fairly simple and straightforward. Whenever you are finished with the changes to a contract, you need to compile the contract using npx hardhat compile. What this command does is compile the contract in the solidity language stated in the solc compiler and generates two files per contract:
Artifact (ABI): A JSON file that contains information that explains the contract in machine-readable terms and allows someone to interact with it.
Debug File: Information needed to reproduce the compilation and debug contracts. Information that is handy to have when trying to troubleshoot an issue and wasn’t aware of the solc version used to compile the contract.
Hardhat Network
Hardhat comes with a built-in local Ethereum node network called Hardhat Network. This network is super helpful in testing out contract interactions because it mimics the live environment with the added benefits of speeding up processes like mining blocks to see the transaction appear with no delay. This network can be explicitly run for the duration of a script or run as a standalone and contains 20 test wallets containing plenty of ETH that can be used to deploy and test transactions with your contract.
Hardhat Runtime Environment (HRE)
Running the command, npx hardhat run, will access the Hardhat Runtime Environment and compile user-defined tasks before running the script that is passed to the argument, like npx hardhat run ./run-erc20.js When the script is run with this command, HRE is injected into the global scope and allows you to access client-interaction libraries like Ethers.js, as well as any other plugins that are integrated with the project. The contents of the script are up to you to decide, but commonly contain multiple transactions to test all of the functionality of the script.
Tests
Tests are often overlooked, yet essential to deploying a flawless contract. While running scripts in HRE allow you to interact with your smart contracts like a standard user would, tests allow you to test allow of the edge cases to ensure that unintended user behaviors won’t lead to malicious behavior in your smart contract. Using Mocha, a test framework that comes out of the box with Hardhat, and Waffle, a library that integrates with Mocha, you are able to run mock tests of counter-intuitive interactions with a contract.
Deployment to Testnets
Running contracts locally on the Hardhat Network allows you to iterate and debug in a fast manner, but the trade-off with this speed is the lack of real-world testing. This is where Testnets come into play as you are able to deploy and run transactions in an environment that mimics the Mainnet. All of the transactions run on the Testnet are stored on a test blockchain that is accessible and interacted with by users around the world. Testing your contract on a testnet, whether it is Rinkeby, Gorli, Kovan or Ropsten, should be your last step prior to deploying to the Mainnet.
Deployment to the Mainnet
You have finally reached the finish line. After compiling and testing, it is finally ready to deploy your smart contract. As I mentioned earlier in this newsletter, there is no out-of-box deployment solution provided by Hardhat, so a script run through the HRE is required to deploy to the Mainnet. In addition to a deployment script, unless you plan to run your own Ethereum Node which you can use to deploy the contract, you must use a 3rd party service like Alchemy or Infura. Nodes are necessary for deployment as they serve as the gateway to the Ethereum blockchain.
Wrapping it Up
Just like that, you have seen what the general process looks like to develop and deploy smart contracts to the Ethereum blockchain with Hardhat. While it might have felt overwhelming to take on this task when initially learning the language, as you can see now the process after that is not too difficult to follow. Tools like Hardhat streamline all of the logistical parts so you can focus on your contracts and the ways users will interact with them.
Create your profile
Only paid subscribers can comment on this post
Check your email
For your security, we need to re-authenticate you.
Click the link we sent to , or click here to sign in.