7. Hardhat | Fund Me

Linting

  • solhint is a linter for solidity which will analyze code for potential errors, checks for best practices of code and does formatting


Hardhat Deploy

  • hardhat-deploy is an npm package which automates the process of writing deploy scripts for our contracts

    • Needs to be overriden as per github instructions

  • Add a require statement in hardhat.config.js

  • Make a deploy folder in the project which will contain deployment configuration

deploy/01-deploy-fund-me.js

// Method 1
// function deployFunc() {
//     console.log("Hi!")
// }

// module.exports.default = deployFunc

// Method 2
// module.exports = async (hre) => {
//     // hre.getNamedAccounts, hre.deployments
//     const { getNamedAccounts, deployments } = hre
// }

// Method 3
module.exports = async ({ getNamedAccounts, deployments }) => {
    const { deploy, log } = deployments
    const { deployer } = await getNamedAccounts()
    const chainId = network.config.chainId
}

Mocking & helper-hardhat-config

  • Mocking which is used in unit testing is creating objects that simulate behaviour of real objects

  • We want to use mock when using localhost or hardhat network for the price converter contract

  • helper-hardhat-config is a javascript file taken from aave repository which deploys their code to multiple different chains and multiple different addresses, it will help us get priceFeed address (of chainlink) for the chain that we uses

  • When we run a local hardhat node, it will automatically deploy all the contracts

contracts/FundMe.sol

Added priceFeedAddress in constructor for dynamic chain eth/usd mapping

contracts/PriceConverter.sol

Adjusted this contract as per FundMe contract to accept dynamic priceFeed contract address

contracts/test/MockV3Aggregator.sol

helper-hardhat-config.js

deploy/00-deploy-mocks.js

01-deploy-fund-me.js


Utils Folder

  • We put commonly used scripts in this folder like the verify contract so that every one uses it (OOP)

utils/verify.js

deploy/01-deploy-fund-me.js


Solidity Style Guide

  • We are going to follow solidity docs official style guide to make our code much neater and readable by following orders and conventions

  • We use Natspec format to document our code

    • Used later on to automatically generate code documentation for other developeres


Test FundMe

  • We make seperate tests for staging & unit

  • In unit tests, individual components are tested

    • They are done locally

      • on local hardhat network

      • fored hardhat network

    • Similar to SimpleStorage tests written in previous notes section

  • In staging or integration tests, whole flow is tested, usually done before deploying to production

    • They are done on a testnet


Debugging & Breakpoints

  • We can pin a breakpoint in vscode & use javascript debug terminal to debug the code and see variable values on the breakpoints


Solidity-Console-Log

  • In solidity, we can import hardhat/console.sol; and use console.log() inside the solidity code to debug the contract


Storage in Solidity

  • Each global/storage variable is stored seperately in the storage

  • Each slot is 32 bytes long and represents the bytes version of the object

    • e.g, uint256 25 is 0x000...0019 since thats the hex representation

    • For aa "true" boolean, it would be 0x000...001 since thats its hex

  • For dynamic values like mappings and dynamic arrays, the elements are stored using a hashing function. More info in documentation

    • For arrays, a sequential storage spot is taken up for the length of the array

    • For mappings, a sequantial storage spot is taken up, but left blank

  • Constants and immutable variables are not stored in storage, but they are considered part of the core of the bytecode of the contract

getStorageAt

We can query smart contracts to find out values of stored variables at a particular slot

Gas & OpCodes

  • When we compile our contracts, in our bytecode object, there are opcodes present. Each opCode represent an operation in the contract

  • Each opCode has a gas price associated with it

  • SLOAD opcode is used to load word from storage and it costs 800 gas

  • SSTORE opcode is used to save word to storage and it costs 20000** gas

  • Therefore, in our contracts, we prepend s_ keyword with variable names to denote that they are storage varaibles and will cost a lot of gas


  • For normal contract users, we should make the s_<variables> private and make naming friendly getter functions for them.


Reference Code

https://github.com/Noman-Aziz/Hardhat-101-FundMe


Last updated