DEV Community: Jamiebones

Indexing Smart Contract Data Using The Graph Protocol

Jamiebones — Wed, 27 Jul 2022 14:24:00 +0000

Introduction

Smart Contracts emit events that operate as a rich supply of data which can be aggregated. For instance, when tokens are transferred, an ERC20 token produces a transfer event. A developer or a user might index and aggregate this transfer event data and then run queries against it to learn more about the token's performance, such as the top holders, the volume of transactions, etc.

Blockchain data can be organized using the decentralized indexing technology known as the Graph Protocol. It uses the Graph Token (GRT), an ERC20 token, as a financial inducement for network security. The protocol allows for participation in four different roles, which are:

Developer
Indexer
Delegator
Curator

Developer

A subgraph is created by a developer who writes a schema and creates mappings to pull data into the schema entities. The subgraph is deployed to the Graph network, where an indexer indexes it.

Indexer

A node in the Graph Network is run by an indexer. An indexer stakes GRT so that it can run a node and index subgraphs. The indexer is compensated through network query fees.

Delegator

A delegator is a person who bets GRT on an indexer. A delegator is not required to run a node, but he or she can benefit from query fees by staking GRT on an indexer.

Curator

A Curator is someone who has enough money to tell indexers which subgraphs are worth indexing. They inspect the quality of subgraphs and assign weight to them by using GRT as signals on subgraphs so that indexers can find and index the subgraph.

You can read more about the roles here.

Creating a subgraph

Navigate to the Graph Studio and connect your wallet by signing a transaction. (No Eth will be charged ). Next, click on the Create Subgraph button to create and select the blockchain network you want the subgraph to index. I selected the Ethereum Mainnet because I want to index the Maker Dao Token found at this address. (0x6B175474E89094C44Da98b954EedeAC495271d0F).

Next, give your subgraph a unique name (In my case I named mine daitoken) and click on the continue button. Fill in the fields, describing what the subgraph does and click on save.

We will then proceed and create the subgraph in our development machine.

Take a note of the name of the subgraph. It will be needed when creating the subgraph on our machine.

Install the Graph CLI tool in our system by typing the code below at the terminal:

You must have Node installed on your computer

 npm install -g @graphprotocol/graph-cli

After installing the CLI, we will need to initiate the subgraph by using the slug name which we created in the Graph Studio earlier.

graph init --studio <slug_name>

Replace slug_name with the name of your created slug. Mine was daitoken, so my command to init will be:

graph init --studio daitoken

After running the above command, you will be ask the following question by the tool:

Select Protocol Network : you should select Ethereum
Confirm your slug name : click on enter
Directory to create the subgraph in
Select the Ethereum network: mainnet
Contract address (the address of the contract you want to index) : 0x6B175474E89094C44Da98b954EedeAC495271d0F (this is the Maker Dai Token ) The tool will fetch the ABI from Etherscan, if it was not successful, you will have to compile the contract yourself and pass the location of the ABI to the tool.
Contract name : name of the contract you are indexing

Finally, the tool generates and creates your subgraph. Move into the created folder and take a look at the folders content. We are most interested in three files which are:

schema.graphql
subgraph.yaml
src/mappings.ts

Creating a Schema

The entities of the subgraph are contained in a schema. An entity is analogous to a table in a database, and its fields are analogous to columns. An entity may have a relationship with another entity at times. This is how an entity is represented:

  type Customer @entity {
    id: ID!
    name: String!
    address: Bytes!
  }

Each entity must have a id field that cannot be null and is denoted by the ! sign, indicating that the field cannot be null.

If an entity will not be updated after it is created, it is usually written as immutable; this aids performance.

  //Immutable Customer Entity
  type Customer @entity(immutable: true) {
    id: ID!
    name: String!
    address: Bytes!
  }

When representing a one-to-many relationship between entities, the one side is saved while the many side is derived. Consider a one-to-many relationship between a Customer entity and an Orders Entity. The one side of the relationship is saved in Orders, while the many side is derived in Customer.

   type Orders @entity {
     id : ID!
     amount: BigInt!
     token: String!
     buyer: Customer!
   }

    type Customer @entity {
    id: ID!
    name: String!
    address: Bytes!
    orders: [ Orders!]! @derivedFrom(field: "buyer")
  }

We only save values for the id, name, and address fields when mapping data for the Customer entity. When we query the Customer's entity, the orders field will be derived from the 'Orders' entity.

The schema for the Maker Dai Token will consist of a User entity, a UserCounter entity and a TransferCounter entity. The created entities will be mapped to data inside the mappings.ts file. Open the file schema.graphql and paste the code below.

type User @entity {
  id: ID!
  address: String!
  balance: BigInt!
  transactionCount: Int!
}

type UserCounter @entity {
  id: ID!
  count: Int!
}

type TransferCounter @entity {
  id: ID!
  count: Int!
  totalTransferred: BigInt!
}

The User entity contains fields of id, address, balance and transactionCount. These fields resolves to types of ID!, String, BigInt and Int respectively. The ! means that the field cannot be null. We are interested in saving the users of the token and their balance and the number of transactions they have made. We are also interested in the total user count and the total number of transfers made. Next, we will edit the manifest file.

Updating the Manifest file.

Open the file subgraph.yaml which is a configuration file. We will list the entities created above here, and also define the events on the smart contract we are interested in and handlers to pull the data into the entities.

specVersion: 0.0.2
schema:
  file: ./schema.graphql
dataSources:
  - kind: ethereum
    name: DaiToken
    network: mainnet
    source:
      address: "0x6B175474E89094C44Da98b954EedeAC495271d0F"
      abi: DaiToken
      startBlock: 8928158
    mapping:
      kind: ethereum/events
      apiVersion: 0.0.5
      language: wasm/assemblyscript
      entities:
        - User
        - UserCounter
        - TransferCounter
      abis:
        - name: DaiToken
          file: ./abis/DaiToken.json
      eventHandlers:
        - event: Transfer(indexed address,indexed address,uint256)
          handler: handleTransfer
      file: ./src/mapping.ts

The startBlock which is under the source key signifies which block in the blockchain should the indexing start from. If we don't specify the startBlock, the indexing will start from the genesis block. You can get the block on which the contract was created from Etherscan.

Under the entities key we listed our created entities of :
User, UserCounter and TransferCounter. The event we are interested in is the Transfer event of the Token. The Transfer event takes three parameters of "indexed address,indexed address,uint256".

We define an handler to fire when the Transfer event occurs in the contract. This handler is named handleTransfer and it will be defined inside the mapping.ts file.

Lastly run the command below to auto generate types:

 graph codegen

When we change our entities we should remember to run the above command so as to correctly generate the types.

Creating mapping handler

Open the mapping file located in the directory src/mapping.ts. The subgraph mapping is written in AssemblyScript, which appears to be similar to Typescript.


import { Transfer as TransferEvent } from "../generated/DaiToken/DaiToken";
import { User, UserCounter, TransferCounter } from "../generated/schema";
import { BigInt } from "@graphprotocol/graph-ts";

export function handleTransfer(event: TransferEvent): void {
  let day = event.block.timestamp.div(BigInt.fromI32(60 * 60 * 24));

  let userFrom = User.load(event.params.src.toHex());
  if (userFrom == null) {
    userFrom = newUser(event.params.src.toHex(), event.params.src.toHex());
  }
  userFrom.balance = userFrom.balance.minus(event.params.wad);
  userFrom.transactionCount = userFrom.transactionCount + 1;
  userFrom.save();

  let userTo = User.load(event.params.dst.toHex());
  if (userTo == null) {
    userTo = newUser(event.params.dst.toHex(), event.params.dst.toHex());

    // UserCounter
    let userCounter = UserCounter.load("singleton");
    if (userCounter == null) {
      userCounter = new UserCounter("singleton");
      userCounter.count = 1;
    } else {
      userCounter.count = userCounter.count + 1;
    }
    userCounter.save();
    userCounter.id = day.toString();
    userCounter.save();
  }
  userTo.balance = userTo.balance.plus(event.params.wad);
  userTo.transactionCount = userTo.transactionCount + 1;
  userTo.save();

  // Transfer counter total and historical
  let transferCounter = TransferCounter.load("singleton");
  if (transferCounter == null) {
    transferCounter = new TransferCounter("singleton");
    transferCounter.count = 0;
    transferCounter.totalTransferred = BigInt.fromI32(0);
  }
  transferCounter.count = transferCounter.count + 1;
  transferCounter.totalTransferred = transferCounter.totalTransferred.plus(
    event.params.wad
  );
  transferCounter.save();
  transferCounter.id = day.toString();
  transferCounter.save();
}

function newUser(id: string, address: string): User {
  let user = new User(id);
  user.address = address;
  user.balance = BigInt.fromI32(0);
  user.transactionCount = 0;
  return user;
}

We imported our Transfer type and renamed it TransferEvent at the top of the file. To generate the types, we had to use graph codegen. We also imported our User, UserCounter, and TransferCounter entities.

import { Transfer as TransferEvent } from "../generated/DaiToken/DaiToken";
import { User, UserCounter, TransferCounter } from "../generated/schema";

Inside the file we defined and exported a function with the following signature.

 export function handleTransfer(event: TransferEvent): void 
 {}

This function receives as a parameter the TransferEvent. This function will be called for every transfer event that was created in the contract. The function does not return any output hence the return type of void.

All of the data that we want to save in the Graph node is contained in the event input parameter. We extract the day from the timestamp by dividing it by 86400 because this variable will be used as an identifier to save the unique transaction and user count reached each day.

let day = event.block.timestamp.div(BigInt.fromI32(60 * 60 * 24));

The transfer event contains information about the user who made the transfer, the recipients of the transfer, and the amount transferred. To represent this, we created variables called userFrom and userTo.

let userFrom = User.load(event.params.src.toHex());

We load the User entity from the Graph store if it exists, using the user's wallet address saved in the event.params.src property. Using the .toHex() method, we convert the wallet address to hexadecimal.

If userFrom is null, we use the utility function newUser to create and return a new 'User'. We subtract the amount transferred from the balance of the userFrom and increment the userFrom transaction count by one before saving the entity to the store.

The userTo variable is the beneficiary of the transfer, we check if the userTo exists by loading the data from the store.

 let userTo = User.load(event.params.dst.toHex());

If userTo is null, we create a new user using the newUser function. Since this userTo address is new, we will want to add it to the UserCounter entity. We want to save and increment the UserCounter.count field and also save the historical user count on each day.

    let userCounter = UserCounter.load("singleton");

This line loads the UserCounter from the store using the id singleton. If we don't have a UserCounter, it creates one and save the current count.

    if (userCounter == null) {
    //code removed
    userCounter.save();
    userCounter.id = day.toString();
    userCounter.save();

After saving the userCounter created by using the singleton key as an id, we then defined another id which we equate to the day.toString() and also save the historical day count.

// assuming this is the current user count which we have saved
 userCount = {
       id : "Singleton",
       count: 4567
    }
//assuming day.toString() = 18219
userCount.id = day.toString()

userCount.save()
//calling userCount.save() again will save the example entity //into the store. This is the historical count data
userCount = {
  id : "18219",
  count: 4567
}

We save the TransferCounter in the same way that we saved the UserCounter. We save the daily count and amount transferred, as well as the cumulative sum of the amount transferred and transaction count, to the store.

Deploying the subgraph to the studio

We have to authenticate from the terminal by running this code:

 graph auth --studio <deployment_key>

Your deployment key can be found on the dashboard of your Graph studio.

Next we build the project by running:

 graph build

To deploy the graph to the studio we run :

graph deploy --studio <slug_name>

The slug_name is the subgraph's name. It must be the same as what was specified in Graph Studio. You'll be prompted to enter a version number for the deployed subgraph.

You will not be able to delete a deployed subgraph.
You can only change it and republish it as a new version.

After deploying my subgraph, I was given a development url for testing purposes. The Graph's hosted service will begin indexing the subgraph. It will take some time before you can begin querying the subgraph.

Writing queries to query our subgraph

Our deployed subgraph contained three entities namely User, UserCounter and TransferCounter. We can use the studio playground to write GraphQL queries to retrieve our entities. We can retrieve a single entity or a collection of entitites.

See below some sample queries we could make to our subgraph.

query to retrieve the first 100 users records

  {
    users(first: 100){
      id
      address
      balance
      transactionCount
   }
  }

query to retrieve the top 10 Dai token holders

  {
  users(first:10, orderBy: balance, orderDirection: desc){
    id
    balance
    transactionCount
    address
  }
}

query to get the total number of users that have used the Dai token

 {
   userCounter(id: "singleton"){
     id
     count
  }
}

query to retrieve a singe user

  {
  user(id: "wallet address"){
    id
    balance
    transactionCount
    address
  }
}

Finally, we could make our subgraph available to the decentralized network. The Graph hosted service is currently indexing our deployed subgraph. To make our subgraph decentralized, we should publish it to the network, where indexers will pick it up and index it. The code for the tutorial is available here

I hope you learned something useful from this tutorial. Thank you for your time.

Gas Saving Techniques in Solidity

Jamiebones — Sat, 09 Jul 2022 20:12:55 +0000

Gas is a unit of computational measure in Solidity. This is the amount that we pay to interact and transact with a smart contracts. The gas is calculated via a simple formulae which is:
Gas = Gas Price * Gas used.
The gas price is not constant and it is dependent on the congestion of the network. The more users pushing transaction through the network the higher the gas price. The amount of gas used is determined by the operation performed by the smart contract.

This blog post will discuss some techniques we might employ to reduce the gas spent when sending transaction to a smart contract. We will consider the following listed techniques to reduce the gas foot print of a smart contract.

Use constant and immutable variables for variable that don't change
Cache read variables in memory
Incrementing and decrementing by 1
calldata and memory
Calling view function
Integer overflow/underflow
Use revert instead of require
Avoid loading too many data in memory
Other tips

Use constant and immutable variables for variable that don't change

Using the constant and the immutable keywords for variables that do not change helps to save on gas used. The reason been that constant and immutable variables do not occupy a storage slot when compiled. They are saved inside the contract byte code. Lets see an example.

//SPDX-License-Identifier:MIT
pragma solidity ^0.8.3;

interface IERC20 {    
 function transfer(address to, uint256 value) external returns (bool);    
function approve(address spender, uint256 value) external returns (bool);    
function transferFrom(address from, address to, uint256 value) external returns (bool);   
//rest of the interface code
}

//Gas used: 187302
contract Expensive {
   IERC20 public token;
   uint256 public timeStamp = 566777;

   constructor(address token_address) {
       token = IERC20();
   }

}

//Gas used: 142890
contract GasSaver {
   IERC20 public immutable i_token;
   uint256 public constant TIMESTAMP = 566777;

   constructor(address token_address) {
       i_token = IERC20(token_address);
   }
}

The first contract Expensive has a public variable of type IERC20 and a uint256 also defined as public. When we deployed this contract, the contract deployment used up a total of 187302 gas when deployed to Remix. The second contract named GasSaver also have the same variable structure as the Expensive contract but we made use of constant keyword for the TIMESTAMP because we will not be changing the value. For the interface we used the immutable keyword which means we can no longer modify the value of the i_token variable after setting it inside the constructor. This action alone reduced the gas consumption from 187302 to 142890.

Cache read variables in memory

Reading from a variable in storage cost gas. When we access a variable for the first time it cost 2100 gas and subsequent access will cost 100 gas. If we have an array and want to perform some computation on the array elements. It could be more gas effective to read the length of the array and store it in a variable. If the array is not too large we could also read the whole array into memory and access it from memory instead of continuously reading from storage.

 //SPDX-License-Identifier:MIT;

pragma solidity ^0.8.3;

contract Expensive {
   uint256[] public numbers;

   constructor(uint256[] memory _numbers) {
       numbers = _numbers;
   }

   //Gas used: 40146
   function sum() public view returns (uint256 ){
       uint256 total = 0;
       for (uint256 i=0; i < numbers.length; i++) {
          total += numbers[i];
       }
       return total;
   }
}

contract GasSaver {
   uint256[] public numbers;

   constructor(uint256[] memory _numbers) {
       numbers = _numbers;
   }

   //39434
   function sum() public view returns (uint256 ){
       uint256 total = 0;
       uint256 arrLength = numbers.length;
       uint256[] memory _numbersInMemory = numbers;
       for (uint256 i=0; i < arrLength; i++) {
           total += _numbersInMemory[i];
       }
       return total;
   }
}

The contract GasSaver above saved the length of the array in a variable arrLength and also loaded the array into memory. This helps to reduce the gas spent inside the function.

Incrementing and Decrementing by 1

There are four ways to increment and decrement a variable by 1 in Solidity. Let us see an example.

//SPDX-License-Identifier:MIT;

pragma solidity ^0.8.3;

contract One{
   uint256 public number;
  //Gas used : 43800
   function incrementByOne() public returns (uint256){
      number += 1;
      return number;
   }
}

contract Two{
   uint256 public number;
   //Gas used : 43787
   function incrementByOne() public returns (uint256){
     number = number + 1;
     return number;
   }
}

contract Three{
   uint256 public number;
   //Gas used : 43634
   function incrementByOne() public returns (uint256){
       return number++;
   }
}

contract Four{
   uint256 public number;
   //Gas used : 43628
   function incrementByOne() public returns (uint256){
       return ++number;
   }
}

The example above list four contracts which shows the way we could increment a number variable by a value of 1. The contract Four is more gas effective out of the lot when ran. To save more on gas when incrementing a variable use the method of increment in contract Four (++number) which is more gas efficient.

calldata and memory

When running a function we could pass the function parameters as calldata or memory for variables such as strings, structs,arrays etc. If we are not modifying the passed parameter we should pass it as calldata because calldata is more gas efficient than memory. Let's see an example:

//SPDX-License-Identifier:MIT;
pragma solidity ^0.8.3;
contract GasSaver {
    //Gas used: 22471
    function passParameterAsCallData(string calldata _name) public returns (string memory){}
    //Gas used: 22913
    function passParameterAsMemory(string memory _name) public returns (string memory){}
}

Calling these two functions in Remix and passing the same parameter to the functions, you will noticed that setting a function _name parameter as calldata reduced the gas used.

You can only used calldata when you are not going to modify the value of the variable passed as calldata inside the function.

Calling a `view` function

A view function does not use gas when called, but if we decide to call a view function inside of another function which is a transaction, it then uses gas.

//SPDX-License-Identifier:MIT;

pragma solidity ^0.8.3;
contract GasSaver {
    uint256[] private numbers = [2,3,5,67,34];

    function getNumberAt( uint256 _index ) public view returns (uint256){
        return numbers[_index];
    }
    //Gas used when getNumber was called: 44778

    //Gas used without calling getNumber() 44450
    function sumAndMultiply() public {
       uint256[] memory _numbers = numbers;
       uint256 arrlength = _numbers.length;
       for(uint256 i=0; i < arrlength; ++i){
          numbers[i] = _numbers[i] * i;
       }
       //getNumberAt(2);
    }
}

The above is a simple contract to illustrate the point about calling view functions inside of a transaction. The function getNumberAt is a view function that returns the value of the array at the passed index. Calling this function uses no gas because it is a view function, but if we decide to call this function inside of the sumAndMultiply function, we can see that the gas usage of sumAndMultiply
has increased because the view function is called within it.

Gas used when sumAndMutiply functions is called: 44778.
Gas used when getNumberAt view function is also called inside the sumAndMultiply function: 44450.

So, we can see that calling a view function inside a transaction increased the amount of gas that should have been spent, if the view function was not included in the call.

Integer overflow/underflow

Prior to Solidity 0.8.0 version, interger overflow and underflow checks were performed by using the SafeMath library. From Solidity 0.8.0 upward, the compiler does that check for us.

This extra check cost gas. If we know that the mathematical operations we will perform inside the contract will not overflow or underflow, we can tell the compiler not to check for overflow or underflow in the operation.

//SPDX-License-Identifier:MIT;

pragma solidity ^0.8.3;

contract OverFlow {
    uint256 public numberOne;
    uint256 public numberTwo;

    //Gas used: 43440
    function setNumberOne() public {
        ++numberOne;
    }
    //Gas used: 43339
     function setNumberTwo() public {
       unchecked {
           ++numberTwo;
       }
    }
}

The above contract OverFlow has two functions used to set two variables inside the contract. The compiler in setNumberOne checks and prevents the number from overflow or underflow. In the second function setNumberTwo we are telling the compiler to mind its business and not check for overflow or underflow. Using unchecked means that the code block will not be checked for overflow or underflow.

If we know that our mathematics will be safe we could safe a little gas by using unchecked.

Use revert instead of require

We use require to check if a statement is true. If the statement evaluates to false the transaction is reverted and the remaining gas returned to the user. Since the advert of custom error in Solidity we could use the revert statement to throw a custom error. Using revert instead of require is more gas efficient. You can run the code below to see the the amount of gas saved when revert is used instead of require.

//SPDX-License-Identifier:MIT;
pragma solidity ^0.8.3;
error NotEnough();
contract GasSaver {
   uint256 public number;
   //Gas Used: 21898
    function setNumber(uint256 _number) public {
        require(_number > 10, "number too small please");
        number = _number;
    }
     //Gas Used: 21669
     function setNumberAndRevert(uint256 _number) public {
        if ( _number < 10 ){
            revert NotEnough();
        }
        number = _number;
    }
}

Avoid loading too many data in memory

Loading data in memory in a single transaction has the effect of increasing gasused. The gas used increase in a quadratic factor when more than 32kb of memory is used in a single transaction. Let's see an example.

//SPDX-License-Identifier:MIT;
pragma solidity ^0.8.3;
contract One {
    //Gas used: 29261
    function setArrayInMemory() public pure {
        uint256[1000] memory _array;
    }
}

contract Two {
    //Gas used: 276761
    function setArrayInMemory() public pure {
        uint256[10000] memory _array;
    }
}

//Gas used: 922855
contract Three {
    function setArrayInMemory() public pure {
        uint256[20000] memory _array;
    }
}

contract Four {
    //Gas used: 3386918
    function setArrayInMemory() public pure {
        uint256[40000] memory _array;
    }
}

The above example defined four contracts and each contract has a function named setArrayInMemory where memory space is reserved for an array of uint256.

Contract One loads reserves space in memory for 1000 uint256 numbers and when the function is executed it uses up 29261 gas. Contract Two creates memory space for 10000 uint256 numbers and we can see that the gas used is 276761 which is roughly about 10 times of the gas used by Contract One.

Things gets interesting in Contract Three which reserves space for 20000 uint256 numbers. From the gas used which is 922855, we can see that once the memory used in a single transaction exceeds 32 kilobyte, the quadratic factor of the memory expansion cost kicks in thereby increasing the gas used in a quadratic way.

Do not populate arrays with enormous amounts of items in a single transaction to prevent gas used increase in a quadratic way.

Other tips

Always put your require statement on top in the function before making any state change so that if the require statement fails, the remaining gas is refunded to the user on revert.
When comparing operation using && or || with a require statement; you should put the cheaper part of the operation first so that if it fails, the compiler will not compare the second part thereby saving on gas used.

In conclusion We can use a combination of these techniques highlighted here to improve the gas consumption of our smart contracts thereby saving our users from spending too much on gas when interacting with our smart contracts.

Thanks for reading.

Getting Started With GraphQL and Apollo-Server

Jamiebones — Sun, 26 Jun 2022 10:36:19 +0000

GraphQL is a query language used to query and retrieve data. It is an alternative to REST and it gives the ability to describe our data as types since it is a strongly-typed language. We describe a schema and query for the exact data or portion of data we want.

Describe your data (Schema):

 type Student {
   studentId: ID!
   name: String
   sex: Male
   courses: [Courses]
 }

Ask for what you want:

 {
   student(name: "Ada"){
      name
      sex
   }
 }

Retrieve predictable result:

{
  student: {
    name: "Ada",
    sex: "Female"
   }
}

Schema

We define a schema to represent the shape of our data and queries. A schema can be liken to a blueprint which describes the different types, queries and mutation allowed by our GraphQL server.The GraphQL engine validates any incoming request against our defined schema.

  //example schema 
  type User {
    name: String!
    userId: ID!
    sex: String!
  }

In the above example we have a User type that consist of the name, userId and sex. fields. These fields resolves to a GraphQL built-in scalar type of String, ID and String respectively.

Fields that resolve to a single object and cannot have sub-selection in the query is refer to as a scalar type.

  query {
      getUsers{
         name
         userId
         sex
      }
   }

The above query field getUsers resolves to a concrete data of scalar type of String, String and String for the name, userId and sex fields. These fields do not have a further sub-selection hence the name as scalar. The scalar type represent the leaves of the query.

  query {
    allBooks{
      title #scalar type of string
      authors{ #non scalar it has a further sub-selection
        name
      }
   }
  }

The above example is a sample query with a field of allBooks which resolves to a scalar type of string for the title ( no sub-selection) and an authors fields which has a further selection of name of the author.

Some examples of GraphQL scalar types are:

String: A UTF‐8 character sequence.
Int: A signed 32‐bit integer.
Float: A signed double-precision floating-point value.
Boolean: true or false.
ID : This is a unique identifier like a database key

Query and Mutation types

A GraphQL server has a Query and a Mutation type. These are special types that define the entry point of every GraphQL query.

  type Query {
     #all the fields of the query object are listed
    allStudents: [User]
    student(studentId: String): User
  }

type User {
  name: String!
  age: Int!
  sex: String!
  studentId: ID!
}

The above describe a GraphQL User type and queries that can be performed on the server. The field allStudents in the Query object resolves and returns a list of User object while the student returns a single User object. How does the GraphQL system know how to get the data for these fields?

Resolvers

A resolver is a user defined function that resolves the fields of a type with data. Looking at the Query object; it consists of two fields which are allStudents and student. We will need to define two resolvers function with the same name to pull out the data from our database or store.

//resolvers
  Query{
    allStudents:() => {
     //this function should return a list of users
    },

    student:() => {
      //this should return a single user
    }
  }

Data can be retrieved from any data source inside a resolver function as GraphQL does not care about the database or source you are using. You only need to point it to the resolver function which it calls to retrieve the data.

Apollo Server

Lets see an implementation of GraphQL using Apollo Server.

We can build a production ready GraphQL server using Apollo Server.

Create a new NodeJS project

make a new directory by typing:

  mkdir graphql_tutorial

navigate into the new directory by typing:

 cd graphql_tutorial

Navigate to your project directory and type the command

 npm init --yes

The above assumes that NodeJS is installed on your machine.

create a new file named index.js

 touch index.js

create another file named data.js This will serve as the data store to query against.

//data.js file content
 const StudentData = [
  {
    studentId: "1",
    name: "John Parson",
    sex: "Male",
    booksCollection: ["1", "2"]
  },
  {
    studentId: "2",
    name: "Pokemon Geshia",
    sex: "Female",
    booksCollection: ["1"]
  },
  {
    studentId: "3",
    name: "Samson Loken",
    sex: "Male",
    booksCollection: []
  },
];

const BooksData = [
  {
    bookId: "1",
    title: "The Law Of The Land",
    authors: [
      { authorId: "1", authorName: "John Mason" },
      { authorId: "2", authorName: "Favour Damen" },
    ],
  },

  {
    bookId: "2",
    title: "The Next day is Close",
    authors: [{ authorId: "1", authorName: "John Mason" }],
  },
];

const AuthorData = [
  {
    authorId: "1",
    name: "John Mason",
    sex: "Male",
    address: "East West Lane",
    books: ["1", "2"]

  },

  {
    authorId: "2",
    name: "Favour Damen",
    sex: "Female",
    address: "Best Avenue Drive Zone",
    books: ["1"]
  },
];
module.exports = { StudentData, AuthorData, BooksData}

Copy the above code block and dump inside the data.js file.

install dependencies

npm install apollo-server-express apollo-server-core express graphql

Run the above command on the terminal to install the packages needed to create the GraphQL server.

install nodemon to auto run our code

 npm install --save-dev nodemon

open the package.json file and under the scripts section add a start script that will run the server.

  {
  "name": "graphql_tutorial",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "start": "nodemon index.js"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "apollo-server-core": "^3.9.0",
    "apollo-server-express": "^3.9.0",
    "express": "^4.18.1",
    "graphql": "^16.5.0"
  },
  "devDependencies": {
    "nodemon": "^2.0.18"
  }
}

create two files inside the project namely schema.js and resolver.js

  touch schema.js
  touch resolver.js

open the index.js file and put the content below inside.

const { ApolloServer } = require('apollo-server-express');
const { ApolloServerPluginDrainHttpServer } = require('apollo-server-core');
const express =  require('express');
const http = require('http');
const resolver = require("./resolvers");
const schema = require("./schema");

async function startApolloServer(typeDefs, resolvers) {
  const app = express();
  const httpServer = http.createServer(app);
  const server = new ApolloServer({
    typeDefs,
    resolvers,
    csrfPrevention: true,
    cache: 'bounded',
    plugins: [ApolloServerPluginDrainHttpServer({ httpServer })],
  });

  await server.start();
  server.applyMiddleware({ app });
  await new Promise(resolve => httpServer.listen({ port: 5000 }, resolve));
  console.log(`🚀 Server ready at http://localhost:5000${server.graphqlPath}`);
}
startApolloServer(schema, resolver);

At the top we required Apollo Server and other boiler plate code needed to run the server. Next, we defined an async function called startApolloServer which receives as an argument the typeDefs and resolvers (schema and resolvers). We are going to define the schema and resolver for our Graph and pass it as an argument to the startApolloServer function. The server is available on http://localhost:5000/graphql

Creating the Schema

We are going to write our schema inside of the schema.js we created earlier. Our schema will consist of a User type and some queries and mutation.

const { gql } =  require("apollo-server-express");

  module.exports = gql` 
   type Query {
      allUsers: [User]
      user(studentId: String):User
   }
   type User {
    studentId: ID!
    name: String!
    sex: String!
 }
`

The above schema describes a User type and two queries field of allUsers and user. At the top of the file we required gql from the apollo-server-express. The schema is written inside the template string of gql. The content of the file is exported for use using module.exports.

We will need to create a resolver function for the fields of allUser and user.

Open the file resolver.js which was created earlier and let's update it with our resolver function.

const { StudentData, BooksData, AuthorData } = require("./data");


module.exports = {
  Query: {
    allUsers: (parent, args, context, info) => {
      return StudentData;
    },
    user: (parent, args, context, info)) => {
       const user = StudentData.find(student => 
       student.studentId == args.studentId);
     return user;
    }

  },

A resolver accepts four positional arguments which are :

parent:
args:
context:
info You can read more about them in the documentation Here

The above resolves retrieves data from our static data file data.js. The allUsers resolvers do not take any arguments and return all the list of students. If we are pulling data from a database, this is where we would have performed the queries to retrieve the data. The return value must conform to the schema described.

Lets start and execute the query we just wrote:
Run the server:
At the terminal run:

 npm run start

This will start up the server and you will see a message on the terminal : 🚀 Server ready at http://localhost:5000/graphql

Open your browser and navigate to http://localhost:5000/graphql. You will be presented with a playground where you can test your queries and mutation.

Click on the explorer tab to open a new window for you to write out your query.

query{
  allUsers {
    sex
    studentId
    name
  }
}

Paste the above query inside the tab and click on the Run button. The above query is executed against your server and the result is displayed.

{
  "data": {
    "allUsers": [
      {
        "sex": "Male",
        "studentId": "1",
        "name": "John Parson"
      },
     <--- rest of the result -->
    ]
  }
}

Apollo server will return a data object with the result of the query. The result of the allUsers query is an array with the list of the user object (sex,studentId and name). If you look at the file data.js you will noticed that the StudentData also consist of a booksCollection field which is an array of strings. You had notice that the returned data does not contain this field. This is because the booksCollection field is not defined inside our schema.

Let's write a query to get a particular user. The user query requires we pass in a studentId which will be used to fetch the user data.

 query($studentId: String){
  user(studentId: $studentId) {
     name
     studentId
  }
}

At the top we defined a studentId variable that is of type string and we passed the value of the variable to the user field.

The variables are entered below the query tab in the circled location of the image above. Run the query and put in a studentId that existed in the data file. The query runs and we get our result.

Let's introduce some new types into our schema. We want to add a Book and an Author type to the schema. We will want to be able to query for the books owned by a student. In the StudentData array in the data.js file, we have a booksCollection which is a list of books by ID owned by a user.

Open the schema.js file and add the following code to it.

type User {
   #previous fields above
    booksCollection: [Book] #added the field booksCollection
 }

 type Book {
    bookId: ID!
    title: String!
    authors: [Author] 
 }
 type Author {
    authorId: ID!
    name: String
    sex: String
    address: String
 }

We have added a Book type and an Author type to the schema as well as extend the User type by adding a booksCollection field. Looking at the new types added, we can notice that the User type has a field called booksCollection which resolves into a list of Book.

The Book type has a field called authors that resolves into a list of Author type. We have to tell our GraphQL how to retrieve the values for these listed fields. That is where our resolvers come in, we will need to add functions that the GraphQL server calls when it encounters these fields so as to resolve them.

Open the file resolver.js and let's add the resolvers for these field.

{
//resolver.js
//rest of the resolvers file

 Book: {
    authors: (book) => {
      const authors = AuthorData.filter((author) => {
        return author.books.includes(book.bookId);
      });
      return authors;
    },
 },
User: {
    booksCollection: (parent) => {
        const student = StudentData.find(s => s.studentId == parent.studentId);
        const booksArray = student?.booksCollection;
        const collection = [];
        booksArray?.map((bookId) => {
            const book = BooksData.find(e => e.bookId == 
   bookId);
            collection.push(book);
        });
        return collection;
    }
  }
}

In the Book type we have a field called authors that we will need to write a function for so as to retrieve the authors of a book. Remember that a resolver function takes 4 positional arguments of which the first is refer to as the parent of the field, we are resolving. In the case of the authors resolver the parent is a book field that we want to resolve its list of authors.

The authors resolver returns a list of authors from the AuthorData array where the book.bookId is included in the author.books property of the AuthorData array. It simply means, return all the list of authors that wrote the particular book.

Same above also applies to the booksCollection field of the User type which is resolved by finding the user by the studentId of the parent. The parent is the User collection. (we could as well name parent as user ). Once the user is found, the books owned by the user is retrieved by mapping over the student.booksCollection array. For each item, in the array, we retrieve the corresponding book and save it into another array called collection. Once we are done with the loop, we return the collection array.

Let's run another query to retrieve a particular user and their collection of books.

  query($studentId: String){
  user(studentId: $studentId) {
     name
     studentId
     sex
     booksCollection {
       title
       authors {
         address
         sex
         authorId
         name
       }
     }
  }
}

Put a valid value for the studentId. The GraphQL server runs the query and makes use of the defined resolver above and returns a user with the complete list of all the books owned.

We have seen how to retrieve data using the query object of GraphQL. Now, let us see how to mutate or change data in our data store.

Mutation

To change data in our server, we will add the Mutation type. This type has fields which when resolved performs some changes to the data store.

Open the schema.js file and lets add the Mutation type.

#rest of the code above
type Mutation {
    saveUser(studentId: ID!, name: String!, sex: String!, 
    collection: [String]): UserDataSaved
}

interface MutationResponse  {
    code: String!
    success: Boolean!
    message: String!
 }

 type UserDataSaved implements MutationResponse {
    code: String!
    success: Boolean!
    message: String!
    user: User
 }
#rest of the code below

Add the above code after the Query type. Looking closely at the added code, you will notice that we added an interface defined which we call MutationResponse. An interface in GraphQL is similar to interfaces in other programming language. It is a contract that an implementing type must execute, meaning any type that implement this particular interface must define a code, success and message field.

We defined a UserDataSaved type that implements the MutationResponse. To fulfil the interface contract we added the fields of the interface to the type and also added the user field which is the new user added.

When making a mutation, it is recommended to return the new object that was added or changed in the response.

The Mutation type has a field called saveUser which accepts four variables and it resolves with the UserDataSaved type. Let us write the resolver function for the saveUser

Open the resolver.js file and create a Mutation object:

   Mutation: {
    saveUser: (_, { studentId, name, sex, collection }) => {
      const newuser = {
        studentId,
        name,
        sex,
        collection
      };
      StudentData.push(newuser);
      return {
        code: "200",
        success: true,
        message: "New user record saved",
        user: newuser
      }
    },
  },

The saveUser resolver accepts as argument, the studentID,name, sex and collection as arguments. Remember that the second positional arguments of the resolver function is the args object that is passed to the resolver. We destructured the args object to retrieve the studentId, name, sex and collection. We created a newUser variable using these values and we push it into the StudentData array. we return an object which matches our schema as response to the mutation.

Let add a new user via the Apollo playground.

 mutation($studentId: ID!, $name: String!, $sex: String!, $collection: [String]){
  saveUser(studentId: $studentId, name: $name, sex: $sex, collection: $collection) {
    code
    message
    success
    user {
      name
      studentId
      booksCollection {
        authors {
          address
        }
      }
    }
  }
}

After running the query, we get a response back showing that the user has been added to our student list. Note that the added user is to persisted to file. We can query for our newly added user.

We have just covered the basics of GraphQl, in the next post we will explore further and learn more about GraphQL. The code for this tutorial can be found Here

Thanks for reading!

How to Create and Deploy an NFT Smart Contract

Jamiebones — Thu, 19 May 2022 06:58:38 +0000

This block post will show how to create and deploy your NFT to Opensea market place. An NFT can represent anything of value, it can be a character in a game, a digital art, title deeds of an apartment and so forth.

Openzeppelin has implemented code for the ERC1155 standard. The ERC1155 standard is a contract interface that is used for both fungible tokens and NFT.

Before writing our NFT smart contract we should save our image to IPFS (InterPlanetary File System). IPFS is used to save digital media on the blockchain.

Uploading NFT Media File

The media file for the NFT smart contract will be saved on nft.storage. Navigate to the to Nft Storage. We can save our NFT media file on IPFS. Login using your Github account or use your email to sign up for the service.

Click on upload button and you will be presented with the a screen that looks like the image below.

If you want to upload just one file you can click on the upload button to do that but if you have a directory of files you will need to upload them as a CAR. A CAR is a Content Addressed Archive that allows you to pre-compute the root CID for your assets.

Since we will most likely be uploading a directory of files lets proceeds to Upload CAR.

Click to open the directory and select the NFT's Assets files. Click on the download button to download the CAR file. Go back to the site NFT Storage and upload the CAR file to upload your assets to IPFS.

Uploading NFT Metadata

The next step is to upload the metadata that will be read by Opensea. A metadata file is a JSON file that contains a JSON object with the description of the assets.

Sample JSON Object

 {
   "id" : 1,
   "name" : "the name of the image or assets",
   "description": "description of the image or assets",
   "image" : "the location of the assets"
 }

The location of the assets is got from NFT Storage. Click on the Actions button of the uploaded asset.

A dropdown is displayed. Click on View URL. Clicking on the View URL button takes you to a page where all the images that was uploaded via CAR is listed. Click on the link to show the image on the browser. Copy the image link and use it as the image value of the JSON file.

you should name your images using numbers like: 1.png, 2.png; so it will be easy to retrieve the image location.

You will have to upload one JSON file for each image assets uploaded. Also name your JSON file using numbers like 1.json, 2.json and so forth.

We need to upload the metadata file to IPFS using the same method we used for the upload of the image file. Make a CAR file of the content of the directory of JSON metadata and upload the CAR file to IPFS via NFT Storage.

Create the Smart Contract

//SPDX-License-Modifier: MIT

pragma solidity ^0.8.7;

import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";
import "@openzeppelin/contracts/utils/Strings.sol";


contract DASHNFT is ERC1155 {

  uint256 public constant TOKEME = 1;
  uint256 public constant VODERMOT = 2;
  uint256 public constant CYRUS = 3;
  uint256 public constant FLASHBOT = 4;

  constructor() public ERC1155("https://bafybeigjypyqmqby2hu3rqpljezi44adnb3ttlinlz77nuzqlq33c2tyta.ipfs.nftstorage.link/{id}.json") {
      _mint(msg.sender, TOKEME, 100, "");
      _mint(msg.sender, VODERMOT, 100, "");
      _mint(msg.sender, CYRUS, 100, "");
      _mint(msg.sender, FLASHBOT, 100, "");
  }

function uri(uint256 _tokenId) override public view returns (string memory){
    return string(abi.encodePacked(
      "https://bafybeigjypyqmqby2hu3rqpljezi44adnb3ttlinlz77nuzqlq33c2tyta.ipfs.nftstorage.link/",
      Strings.toString(_tokenId),
      ".json"
    )
    );
  }

}

We are making use of OpenZeppelin implementation for ERC1155. At the top of the file we imported the ERC1155.sol file, we also imported an utility contract file that is used for concatenating strings together. Our contract inherits from the ERC1155 contract.

We defined four constant variables which we initialized with values from 1 to 4. The URL of the metadata of the assets is passed to the constructor of ERC1155.

https://bafybeigjypyqmqby2hu3rqpljezi44adnb3ttlinlz77nuzqlq33c2tyta.ipfs.nftstorage.link/{id}.json

Notice the id in curly braces {id}. This id represents the number that we named the JSON file. For each minted NFT, the contract will call the function uri to get the complete location of the metadata. We are calling the _mint function to mint 100 copies each of the four types of NFT we have and assigned them to msg.sender.

Our custom implementation of the uri function concatenates the id of the NFT with its base URL and returns the complete URL of the NFT metadata.

Deploy your contract to a blockchain testnet and copy the contract address and proceed to the testnet of Opensea and search using the deployed NFT contract address. Your NFT contract and its image will be displayed on Opeansea.

Thanks for reading

How To Call Other Contracts In Solidity

Jamiebones — Mon, 25 Apr 2022 14:32:15 +0000

This blog post will show how to call the functions of a smart contract from another smart contract. Assuming we have two smart contracts defined below:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.3;

contract CallContractOne {
  function setValueX() {

  }

}

contract ContractOne {
  uint public x;

 function setX() external {
  //we will want to set the value of x from CallContractOne
 }

}

The first thing to know is, we need to mark the visibility of any function we want to call from outside the contract as external .

To call the smart contract ContractOne from the smart contract CallContractOne. We can decided to initialize the contract we want to call. Let see how this is done :

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.3;

contract CallContractOne {

function setValueXByInitializing( address _contractOneAddress, uint _x ) public {
     ContractOne(_contractOneAddress).setX(_x);
  }

function setValueXByType(ContractOne _contract, uint _x ) public {
     _contract.setX(_x);
  }

function setValueXByPassingValue(ContractOne _contract, uint _x ) public payable {
     _contract.setXAndReceiveEther{value: msg.value }(_x);
  }
}

contract ContractOne {
  uint public x;
  uint public value;

 function setX(uint _x ) external {
  //we will want to set the value of x from CallContractOne
  x = _x;
 }

function setXAndReceiveEther(uint _x ) external payable {
  //we will want to set the value of x from CallContractOne
   x = _x;
   value = msg.value;
 }

}

Looking at the function above setValueXByInitializing we used the address that ContractOne is deployed to initialize the contract. Once we have initialize ContractOne, we can then call the external methods defined on it.

Another way we can also call external function of another contract is by using the contract we want to call as a type. Take a look at the function above setValueXByType. We are passing ContractOne as a type. This is the address in which ContractOne is deployed.

Passing value to an external contract call

We can pass ether when we call an external contract. Take a look at the function setValueXByPassingValue. This function calls the function setXAndReceiveEther inside ContractOne and forwards ether to it.

You can copy the code and try out on Remix. Deploy both of the contracts and copy the address of ContractOne to use inside the smart contract CallContractOne.

Thanks for reading.

Creating Upgradable Solidity Contract With Hardhat

Jamiebones — Tue, 05 Apr 2022 13:43:06 +0000

Smart contracts are immutable meaning once deployed on the blockchain, they can no longer be edited. This is a good thing but what if the deployed contract is buggy or you need to add a specific function to an already deployed smart contract without deploying a new contract thereby losing the state of the previous deployed contract.

OpenZeppelin comes to the rescue by providing upgradables that allow smart contract to be updated without state loss. This tutorial makes use of Hardhat and OpenZeppelin upgradable contract.

Create a new npm project by opening your terminal and typing: ( this tutorial assumes the user already has Node and npm installed in the system )

Tutorial Code lives here

Project Dependencies
Project
How Upgradable Contract Works
Verify Upgradable Contract
Upgrading a smart contract
Things to know when working with Upgradable Contracts

Project Dependencies

npm init --y

Open the package.json file that was created when the above command was run and add the following dependencies code below to the package.json file

  "devDependencies": {
    "@nomiclabs/hardhat-ethers": "^2.0.3",
    "@nomiclabs/hardhat-etherscan": "^2.1.8",
    "@openzeppelin/hardhat-upgrades": "^1.12.0",
    "ethers": "^5.5.2",
    "hardhat": "^2.8.0"
  },
  "dependencies": {
    "dotenv": "^16.0.0"
  }

Install the above dependencies by running npm i. This installs the dependencies into the project. @openzeppelin/hardhat-upgrades provides functionality for creating and deploying upgradable contracts. @nomiclabs/hardhat-etherscan is used for verifying the contract using Etherscan. @nomiclabs/hardhat-ethers allows hardhat to work with ether.js.

Project

Create a new hardhat project by running in the terminal:

 npx hardhat

This presents us options to select a project template. Select the first option which is Create a sample project and this creates a sample project with boiler plate code.

Create a .env file in the project directory. This file will contain our environment variable. In this project, we will need values for the following environmental variables which are:
INFURA_API_KEY
PRI_KEY
ETHERSCAN_API_KEY
INFURA_API_KEY : our API key we get from Infura.We will need this to connect to infura
PRI_KEY: the primary key of your account in Meta mask. This is used for signing a transaction
ETHERSCAN_API_KEY : your API key from Etherscan. This will be used for verifying a contract.

Open the hardhat-config.js file and configure it by adding the code below.

require("@nomiclabs/hardhat-ethers");
require("@openzeppelin/hardhat-upgrades");
require("@nomiclabs/hardhat-etherscan");

require('dotenv').config();
module.exports = {
  solidity: "0.8.10",
  networks: {
    ropsten: {
      url: `https://ropsten.infura.io/v3/${process.env.INFURA_API_KEY}`,
      accounts: [process.env.PRI_KEY],
    },
    rinkeby: {
      url: `https://rinkeby.infura.io/v3/${process.env.INFURA_API_KEY}`,
      accounts: [process.env.PRI_KEY]
    }
  },
  etherscan: {
    apiKey: process.env.ETHERSCAN_API_KEY,
  },
};

Open the contract folder in the project and delete the Greeter.sol file. Create a new file called CalculatorV1.sol. This will contain the smart contract we will deploy to the rinkeby network.

Inside the file CalculatorV1.sol replace it with the following code below:

pragma solidity 0.8.10;

import "hardhat/console.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";

contract CalculatorV1 is Initializable {
   uint public val;
   function initialize(uint256 _val ) external initializer{
        val = _val;
    }
    function add(uint a, uint b) public pure returns (uint) {
        return a + b;
    }
   function getVal() public view returns (uint) {
        return val;
    }
}

This smart contract is a simple contract of a calculator. The contract inherits from the Initializable contract which is an Openzeppelin contract. It ensures that the initialize function is called only once. An upgradable contract does not have a constructor so the initialize function acts as a constructor and it must be called only once. The initializer modifier ensures the function is called once.

The contract has a public variable named val and three functions which are initialize, add and getVal. We want to deploy this contract to the Rinkeby network which we have set up in the hardhat-config.js file.

Create a new file inside the scripts folder and call it deploy_contract.js. This file will contain the code that will deploy our Calculator contract for us.

Inside the deploy_contract.js file add the following code:

//scripts/deploy_contract.js
const { ethers, upgrades } = require("hardhat");

async function main() {
   const CalculatorV1 = await ethers.getContractFactory("CalculatorV1");
    console.log("Deploying Calculator...");
    const calculator = await upgrades.deployProxy(CalculatorV1, [42], {
        initializer: "initialize",
    });
    await calculator.deployed();
    console.log("Calculator deployed to:", calculator.address);
}

main();

The code above requires ethers and upgrades from hardhat. An async function is created and inside the function, the contract factory is retrieved using ethers with the name of the contract ( CalculatorV1 ). The upgrades.deployProxy is used to deploy the contract passingin the contract factory and the initialization function with its parameter passed.

Remember in the contract, we have an initialize function that sets the value of the val variable. This function is called as the contract is being deployed passing in the value 42 as the parameter to the function.

Run on the terminal the following code to deploy the contract:

 npx hardhat run --network rinkeby scripts/deploy_contract.js

After some few second the contract is deployed with the
contract address logged to the console.

How Upgradable Contract Works

When we deployed the contract, three contracts were deployed in total. These are a Proxy contract, a Proxy Admin contract and the Implementation contract which is our CalculatorV1. When a user interacts with the contract, he is actually interacting with the Proxy contract. The Proxy contract makes a delegateCall to our CalculatorV1 contract. For example A contract named A makes a delegateCall to a contract B calling a function in contract B. The function in B is executed in the state of variable A.

For our upgradable contract, the Proxy contract calls the Implementation contract (CalculatorV1). The state change is made on the Proxy contract. The Proxy Admin contract is used for updating the address of the implementation contract
inside the Proxy contract.

Verify Upgradable Contract

When we deployed our contract, we got back the address of the Proxy contract. if we search for this address on Ether scan we are presented with a contract with name TransparentUpgradeableProxy. This contract is the Proxy contract and this will be responsible for calling the Implementation contract.

To verify the Implementation contract and publish the contract code we have to look into the project folder and you will see a folder named .openZeppelin. Open the folder and you will find a file named rinkeby.json. This file is so named because of the network we deployed the contract to. This file was auto generated by hardhat when we ran the deployed script. Inside this file the addressees of the Implementation contract, Proxy admin and the Proxy are kept. As the contract is updated the new addresses are added to the file. Copy the address of the
Implementation contract and proceed to the terminal for verification.
Run this code at the terminal:
npx hardhat verify --network rinkeby contractAddress

Replace contract address with the Implementation address that was copied and run the code. This verifies the contract source code. We also need to verify the Proxy admin contract. Go to Etherscan and search for the Proxy contract using its address. Click on the Contract tab then click on Code tab and click on the more options. Click on is this a proxy? and then click on verify. The Proxy contract will be verified.

Upgrading a Contract

Create a new file inside the contract folder and name it CalculatorV2.

pragma solidity 0.8.10;

import "hardhat/console.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";

contract CalculatorV2 is Initializable {
    uint public val;

    function add(uint a, uint b) public pure returns (uint) {
        return a + b;
    }

    function multiply(uint a, uint b) public pure returns (uint) {
        return a * b;
    }
  function getVal() public view returns (uint) {
        return val;
    }

}

We have added a new function to this version of the contract. The multiply function is added. To upgrade the deployed contract. Create a script inside the scripts folder and create a file upgrade_contract.js. Inside this file put the following code.

const { ethers, upgrades } = require("hardhat");
//the address of the deployed proxy
const PROXY = "0xaf03a6F46Eea7386F3E5481a4756efC678a624e6";

async function main() {
    const CalculatorV2 = await ethers.getContractFactory("CalculatorV2");
    console.log("Upgrading Calculator...");
    await upgrades.upgradeProxy(PROXY, CalculatorV2);
    console.log("Calculator upgraded");
}

main();

The address of the implementation Proxy and the contract factory of the new version of the contract is passed as parameters to upgrades.upgradeProxy. Run the code by typing on the terminal :

 npx hardhat run --network rinkeby scripts/upgrade_contract.js

This will update the address of the Implementation contract in the Proxy contract to make use of the new version deployed. Run the getVal contract to retrieve the value of the state variable val. You will notice that the value of val is still the value we initiated it to be when we deployed the first version of the contract. That is the beauty of upgradable contracts which is the preservation of variable state.

To verify the contract, we have to perform the same steps that was used to verify the first version of the contract.

Things to know when working with Upgradable Contracts

When working with Upgradable contracts the following points should be noted:

Constructor: An upgradable contract can not have a constructor. If you have code that must run when the contract is created. The code should be placed in an init function that will get called when the contract is deployed. Openaeppelin Initializable can be used to ensure a function is called once. (initializer)

function initialize(uint256 _val ) external initializer {
        val = _val;
}

The initialize function will be called only once because of the initializer modifier attached to it.

state variables : state variables in upgradable contracts once declared cannot be removed. Assuming we have a version one contract where we define the following state variables :

uint public val;
string public name;

When deploying version two of the contract, we must ensure that version two of the contract upgrade also contain the same variable as version one in the same order as was defined in version one. The order of the variable matters. if we want to use new state variables, they are added at the bottom.

uint public val;
string public name;
string public newVariableOne;
uint public newVariableTwo;

variable initialization : only state variable declared as const and immutable can be initialize. This is because initializing a state variable will attempt to create a storage for that variable. And as we know the Implementation contract don't use its state. The Proxy contract provides the storage used by the Implementation contract.

The value of variables declared as const are placed in the application code of the contract instead of in storage. That's why only const variable can be initialize.

Implementation contract can not contain code that will self destruct the contract. If a contract is self destruct and removed from the blockchain, the Proxy contract will no longer know where to look to execute functions.

function kill() external {
     selfdestruct(payable(address(0)));
}

Summary

Having a way to upgrade smart contracts could come in useful when you need to change and improve the contract code. Thanks for reading...

Solidity Data Storage Location

Jamiebones — Fri, 25 Mar 2022 23:46:57 +0000

When we declare dynamic data types we need to specify the location to store them. Dynamic data types in Solidity are arrays, strings, struct etc. One of three locations of storage, memory and calldata are usually specified.

Using storage as a location means the data is stored on the blockchain while memory means the data is saved in memory and will be erased after the function in which it was declared has finished executing. The other location of calldata is used to stored variable that is passed as an input parameter to a function.

 //SPDX-License-Identifier: Unlicense
pragma solidity >=0.7.0 <0.9.0;

contract StorageLocation {
    Person[] public persons;

    struct Person {
        string name;
        uint age;
        address personAddress;
    }

    constructor() {
       Person memory newperson = Person({
           name: "Jamie",
           age: 33,
           personAddress: msg.sender
       });

       Person memory personTwo = Person({
           name: "Bones Man",
           age: 33,
           personAddress: msg.sender
       });
       persons.push(newperson);
       persons.push(personTwo);
    }

    function loadPerson() public view returns ( Person[] memory ){
        return persons;
    }

    function changeDataone() public view {
        Person memory person = persons[0];
        person.age = 56;
    }

    function changeDataTwo() public {
        Person storage person = persons[0];
        person.age = 76;
    }

    function receiveAsCallData(uint256[] calldata a) public {
        //you can not modify a
    }
}

The smart contract above is a simple smart contract. At the top of the smart contract we defined an array of Person which is a user defined struct. The array of Person is stored in a variable called persons. The persons variable is stored on the blockchain because it is a state variable so therefore, it's location is storage.

Looking at the constructor function and you will see that there are two Person type created and pushed into the Person[] array called persons. The newperson variable inside the constructor is saved in memory and will be destroyed after the constructor function has finished running. After creating the newperson struct it was pushed into the persons array for permanent storage. The temporary newperson variable in memory will be discarded after the constructor function finish executing.

Take a close look at both the changeDataone function and the changeDataTwo.You will notice that changeDataone function creates a variable named person and saved it to memory.

Person memory person = persons[0];
Doing it this way reads the data of the persons array at index of 0 and stores it in a person variable in memory. Attempting to change person.age to 56 will not be successful because we are not referencing the storage location of persons. At the termination of the function the persons storage variable remains the same because the data in memory has be wiped off.

To persist the changes we make in a dynamic data type we must reference the storage location of that variable. The function changeDataTwo does that. Try it out on Remix

When the contract is deployed, two Person struct is added to the persons array via the constructor which you can view by running loadPerson. Run the function changeDataone and observe if the first Person struct changed as explained. Then run the function changeDataTwo and you will notice that the persons variable was updated.

The third location calldata is used to pass input parameters to functions. Storing a variable in calldata means that the variable cannot be modified. Using calldata has the potential of saving some gas as the EVM does not copy over the data stored on it as it does when you used memory as a location.

Summary

You make use of memory location when you want to read a dynamic data stored in state without modification or you need a temporary store for a dynamic data type.

You make use of storage when you want a reference to the dynamic data stored in state for the purpose of modification.

If you won't be changing the value of the dynamic data type passed as input to a function, you can make use of calldata. Usingcalldata helps to save gas because the EVM does not do a copy of the data.

How To Deploy And Verify A Smart Contract From Remix

Jamiebones — Wed, 23 Mar 2022 21:25:57 +0000

Remix IDE is a convenient tool for building and testing your solidity smart contracts online. This short tutorial will explain how we can build and deploy our smart contract from Remix.

// SPDX-License-Identifier: GPL-3.0

pragma solidity >=0.7.0 <0.9.0;
contract Destructor {
 uint256 public num;
    constructor(uint256 _num){
        num = _num;
    }
    function doWork() external
    {
        selfdestruct(payable(0));
    }
    function getNum() public view returns(uint){
        return num;
    }
}

Deploying a contract

Above we have a simple Destructor contract which was built and tested using the online Remix IDE. To deploy this contract select the Deploy & Run Transactions tab; selectinjected Web3` as your environment. This will connect to the network that your wallet is connected to.

Set the input value of the constructor function if your contract has one before deploying it. Clicking on deploy will open meta mask which will ask you to confirm the transaction. After confirming the transaction, the contract will be deployed to the network.

Verifying deployed contract

You can verify your contract via Remix by using a plugin called ETHERSCAN-CONTRACT VERIFICATION. Click on the plugin manager icon. Search for the plugin ETHERSCAN-CONTRACT VERIFICATION and activate the plugin. After activation your Etherscan API key will be requested.

You can obtain an API key on etherscan. Registering for a free account and create an API key.

After saving your key on the Etherscan-Contract Verification plugin, a screen will be presented where you enter the details of the just deployed smart contract.

You will have to present three (3) values to the Etherscan plugin which are the contract to verify, the constructor arguments and the address of the deployed smart contract.

If the contract has a constructor with values supplied you will need to go to etherscan and retrieve the constructor argument bytes. We do this by copying the transaction hash which can be found on the console of remix.

Take the transaction hash and go to etherscan.io and input the hash on the search bar to retrieve the transaction. Remember if you deployed to a testnet you will have to search for your transaction on the testnet and not on the mainnet.

The transaction will be displayed. Scroll down on the transaction page and click on the click to see more button.

The more tab opens and you will see an Input Data textarea which contains the contract bytecode. We want to copy only the input byte of the constructor from this bytecode. The input byte is appended to the end of the bytecode. Search for the number 70033 inside the textarea. The input byte starts after the last 3 in 70033. Copy the remaining number after the last 3 to the end. The copied number is the input byte.

Go back to Remix IDE and input the copied byte inside the Constructor Arguments input box and also select the contract that you are verifying and input the contract address. Click on verify contract and the deployed contract will become verified.

Go to etherscan and search using the deployed contract address and you will see that your contract is now verified.

How to Connect to Metamask Wallet in React

Jamiebones — Fri, 11 Feb 2022 12:20:50 +0000

To integrate a smart contract with a frontend, the first task is usually how to connect a wallet to your frontend application. This blog post will show you how to connect a wallet from a React application.

Packages to install

The following packages will be needed to connect the wallet:

WalletConnectProvider
WalletLink
Web3Modal
Ether (this is used to connect to the smart contract on the blockchain)

The following packages above can be installed in a React application by running the following commands on terminal:

  npm i --save walletlink @walletconnect/web3-provider ethers 
  web3modal

After installing the following packages, open your React App.js file or the top most component of your application. We will firstly import the packages we just installed.

  import { useEffect, useState, useCallback } from "react";
  import { ethers, providers } from "ethers";
  import Web3Modal from "web3modal";
  import WalletConnectProvider from '@walletconnect/web3-provider'
  import WalletLink from 'walletlink';

  const App = () => {
     return (
       <div>
         <h1>Hello</h1>
      </div>
     )
  }

This is the skeleton of a simple React component. We declared a web3Modal that will allow the select of the wallet we want to use. We need to create a provider option that will be passed to the web3Modal.

  const INFURA_ID = "your-infura-api-key";
  const providerOptions = {
  walletconnect: {
    package: WalletConnectProvider, // required
    options: {
      infuraId: INFURA_ID, // required
    },
  },
  'custom-walletlink': {
    display: {
      logo: 'https://play-lh.googleusercontent.com/PjoJoG27miSglVBXoXrxBSLveV6e3EeBPpNY55aiUUBM9Q1RCETKCOqdOkX2ZydqVf0',
      name: 'Coinbase',
      description: 'Connect to Coinbase Wallet',
    },
    options: {
      appName: 'Coinbase', // Your app name
      networkUrl: `https://mainnet.infura.io/v3/${INFURA_ID}`,
      chainId: 1,
    },
    package: WalletLink,
    connector: async (_, options) => {
      const { appName, networkUrl, chainId } = options
      const walletLink = new WalletLink({
        appName,
      })
      const provider = walletLink.makeWeb3Provider(networkUrl, chainId)
      await provider.enable()
      return provider
    },
  },
}

The WalletLink package allows users to use your application in any desktop browser without installing an extension, and it established a secure tunnel between your app and the mobile wallet with end-to-end encryption utilizing client-generated keys and keeps all user activity private.

WalletConnect package is an open protocol that helps to communicate securely between Wallets and Dapps (Web3 Apps). The protocol establishes a remote connection between two apps and/or devices using a Bridge server to relay payloads. We need to provide an api key to connect.

let web3Modal
if (typeof window !== 'undefined') {
  web3Modal = new Web3Modal({
    network: 'mainnet', // optional
    cacheProvider: true,
    providerOptions, // required
  })
}

We pass the providerOptions to the web3Modal instance. The App.jsx looks exactly like this now.


  import { useEffect, useState, useCallback } from "react";
  import { ethers, providers } from "ethers";
  import Web3Modal from "web3modal";
  import WalletConnectProvider from '@walletconnect/web3-provider'
  import WalletLink from 'walletlink';

const INFURA_ID = "your-infura-api-key";
  const providerOptions = {
  walletconnect: {
    package: WalletConnectProvider, // required
    options: {
      infuraId: INFURA_ID, // required
    },
  },
  'custom-walletlink': {
    display: {
      logo: 'https://play-lh.googleusercontent.com/PjoJoG27miSglVBXoXrxBSLveV6e3EeBPpNY55aiUUBM9Q1RCETKCOqdOkX2ZydqVf0',
      name: 'Coinbase',
      description: 'Connect to Coinbase Wallet',
    },
    options: {
      appName: 'Coinbase', // Your app name
      networkUrl: `https://mainnet.infura.io/v3/${INFURA_ID}`,
      chainId: 1,
    },
    package: WalletLink,
    connector: async (_, options) => {
      const { appName, networkUrl, chainId } = options
      const walletLink = new WalletLink({
        appName,
      })
      const provider = walletLink.makeWeb3Provider(networkUrl, chainId)
      await provider.enable()
      return provider
    },
  },
}

 let web3Modal
if (typeof window !== 'undefined') {
  web3Modal = new Web3Modal({
    network: 'mainnet', // optional
    cacheProvider: true,
    providerOptions, // required
  })
}


  const App = () => {
     return (
       <div>
         <h1>Hello</h1>
      </div>
     )
  }

The provider object needs to be persistent in our application and to prevent passing props down all the component of our application. We will create a context file which we will name walletContext.js.

This file will contain the following contents:

  import * as React from "react";

  const WalletContext = React.createContext();

  const accountDetails = {
     provider: null,
     address: null,
     signer: null,
     web3Provider: null,
     network: null
}

function WalletProvider({children}){
  const [account, setAccountDetails ] = 
   React.useState(accountDetails);
  const value = { account, setAccountDetails };
  return <WalletContext.Provider value={value}>{children} 
  </WalletContext.Provider>
}

function useWallet(){
    const context = React.useContext(WalletContext);
    if (!context){
        throw new Error("useWallet must be used within a WalletProvider")
    }
    return context;
}

export {WalletProvider, useWallet }

We created a React context and named it WalletContext. Then we created a WalletProvider function that returns the WalletContext.Provider component wrapped with any children that will be passed to it. Inside the WalletProvider function, we declared a React state that will be used to store the details of the connected account. The account state and the function to change the state setAccountDetails is passed to the value property of the WalletContext.Provider component. See application state management

We need to create a button that will be used to connect the wallet. We will define two functions which are connect and the disconnect functions. As their name suggest, they will be used to connect and disconnect and disconnect the wallet from the blockchain. Before then we need to create React state that will be used to store the value returned from the functions.

Next we created a function that will consume the created WalletContext. The useWallet hook consumes the WalletContext and returns the context for use.

  <-- previous code above -->

   const App = () => {
    const { account, setAccountDetails } = useWallet();
    const { provider,
     address,
     signer,
     web3Provider,
     network } = account;


const connect = useCallback(async function () {
  const provider = await web3Modal.connect();
  const web3Provider = new providers.Web3Provider(provider);
  const signer = web3Provider.getSigner()
  const address = await signer.getAddress()
  const network = await web3Provider.getNetwork();
  const accountDetails = {
       provider,
       web3Provider,
       signer,
       address,
       network
  }
  setAccountDetails(accountDetails);
}, []);

const disconnect = useCallback(
  async function () {
    await web3Modal.clearCachedProvider()
    if (provider?.disconnect && typeof provider.disconnect === 'function') {
      await provider.disconnect()
    }
    //reset the state here
   const accountDetails = {
      provider: null,
      web3Provider: null,
      signer: null,
      address: null,
      network: null
 }
 setAccountDetails(accountDetails);
  },
  [provider]
)

     return (
       <div>
         <h1>Hello</h1>
      </div>
     )
  }

The connect function creates a provider variable that is set to the default web3Modal connection. This provider is then plugged into the provider object of ether.js.

const web3Provider = new providers.Web3Provider(provider)
We are able to use the web3Providerobject created by ether.js to get the signer, network, address from ether.js. This values are saved in the context using the setAccountDetails function.

The disconnect function clears the web3Modal cache , the saved state and also disconnect the provider. We optimized both functions by wrapping them in a useCallback and passing dependencies.

Auto connecting

If we have already connected to our wallet before, we will want to automatically reconnect when visiting the page or component. This we can do by calling connect in a useEffect hook.

  // Auto connect to the cached provider
  useEffect(() => {
    if (web3Modal.cachedProvider) {
      connect()
    }
  }, [connect]);

We can also listen to events on the provider object to handle some scenarios. Like we may want to be still connected, if a user switch the connected account. The function handleAccountsChanged does that by listening for an account changed event and updates the address portion of the WalletContext.

     useEffect(() => {
    if (provider?.on) {
      const handleAccountsChanged = (accounts) => {
        console.log('accountsChanged', accounts);
        setAccountDetails({
            ...account,
            address: accounts[0],
        })
      }
      const handleChainChanged = (_hexChainId) => {
        window.location.reload()
      }

      const handleDisconnect = (error) => {
        console.log('disconnect', error)
        disconnect()
      }

      provider.on('accountsChanged', handleAccountsChanged)
      provider.on('chainChanged', handleChainChanged)
      provider.on('disconnect', handleDisconnect)

      // Subscription Cleanup
      return () => {
        if (provider.removeListener) {
          provider.removeListener('accountsChanged', handleAccountsChanged)
          provider.removeListener('chainChanged', handleChainChanged)
          provider.removeListener('disconnect', handleDisconnect)
        }
      }
    }
  }, [provider, disconnect])

Putting it all together

//APP>JX

  import { useEffect, useState, useCallback } from "react";
import { ethers, providers } from "ethers";
import Web3Modal from "web3modal";
import WalletConnectProvider from '@walletconnect/web3-provider'
import WalletLink from 'walletlink';
import { useWallet } from './walletContext';

import './App.css';

const trimAddress = ( address ) => {
  const firstpart = address.slice(0, 4);
  const midpart = "....";
  const endpart = address.slice(address.length - 4, address.length );
  return `${firstpart}${midpart}${endpart}`
}

const INFURA_ID = '460f40a260564ac4a4f4b3fffb032dad'


const providerOptions = {
  walletconnect: {
    package: WalletConnectProvider, // required
    options: {
      infuraId: INFURA_ID, // required
    },
  },
  'custom-walletlink': {
    display: {
      logo: 'https://play-lh.googleusercontent.com/PjoJoG27miSglVBXoXrxBSLveV6e3EeBPpNY55aiUUBM9Q1RCETKCOqdOkX2ZydqVf0',
      name: 'Coinbase',
      description: 'Connect to Coinbase Wallet (not Coinbase App)',
    },
    options: {
      appName: 'Coinbase', // Your app name
      networkUrl: `https://mainnet.infura.io/v3/${INFURA_ID}`,
      chainId: 1,
    },
    package: WalletLink,
    connector: async (_, options) => {
      const { appName, networkUrl, chainId } = options
      const walletLink = new WalletLink({
        appName,
      })
      const provider = walletLink.makeWeb3Provider(networkUrl, chainId)
      await provider.enable()
      return provider
    },
  },
}

let web3Modal
if (typeof window !== 'undefined') {
  web3Modal = new Web3Modal({
    network: 'mainnet', // optional
    cacheProvider: true,
    providerOptions, // required
  })
}


function App() {
  const { account, setAccountDetails } = useWallet();
  const { provider,
    address,
    signer,
    web3Provider,
    network } = account;


const connect = useCallback(async function () {
  const provider = await web3Modal.connect();
  const web3Provider = new providers.Web3Provider(provider);
  const signer = web3Provider.getSigner()
  const address = await signer.getAddress()
  const network = await web3Provider.getNetwork();
  const accountDetails = {
       provider,
       web3Provider,
       signer,
       address,
       network
  }
  setAccountDetails(accountDetails);
}, []);



const disconnect = useCallback(
  async function () {
    await web3Modal.clearCachedProvider()
    if (provider?.disconnect && typeof provider.disconnect === 'function') {
      await provider.disconnect()
    }
    //reset the state here
    const accountDetails = {
      provider: null,
      web3Provider: null,
      signer: null,
      address: null,
      network: null
 }
 setAccountDetails(accountDetails);

},
  [provider]
)

  // Auto connect to the cached provider
  useEffect(() => {
    if (web3Modal.cachedProvider) {
      connect()
    }
  }, [connect]);


  useEffect(() => {
    if (provider?.on) {
      const handleAccountsChanged = (accounts) => {
        // eslint-disable-next-line no-console
        console.log('accountsChanged', accounts);
        setAccountDetails({
            ...account,
            address: accounts[0],
        })
      }

      const handleChainChanged = (_hexChainId) => {
        window.location.reload()
      }

      const handleDisconnect = (error) => {
        console.log('disconnect', error)
        disconnect()
      }

      provider.on('accountsChanged', handleAccountsChanged)
      provider.on('chainChanged', handleChainChanged)
      provider.on('disconnect', handleDisconnect)

      // Subscription Cleanup
      return () => {
        if (provider.removeListener) {
          provider.removeListener('accountsChanged', handleAccountsChanged)
          provider.removeListener('chainChanged', handleChainChanged)
          provider.removeListener('disconnect', handleDisconnect)
        }
      }
    }
  }, [provider, disconnect])

  return (
    <div className="App">
         {web3Provider ? (
               <button className="btn btn-danger" type="button" onClick={disconnect}>
                 {trimAddress(address)}
          </button>
        ) : (
          <button className="btn btn-success" type="button" onClick={connect}>
            Connect
          </button>
        )}
    </div>
  );
}

export default App;

To make use of the WalletProvider we wrap our App component with it. This makes the WalletContext available in all the components that it will be needed.

import { WalletProvider } from "./walletContext";
ReactDOM.render(
  <React.StrictMode>
    <WalletProvider>
        <App />
    </WalletProvider>
  </React.StrictMode>,
  document.getElementById('root')

The code is available here

Thanks for reading.

Creating A Crowd Sourcing Solidity Contract

Jamiebones — Sun, 06 Feb 2022 11:28:54 +0000

Description

The code for this post is available here

This blog post will walk you through how to create a crowd sourcing smart contract. The implementation consist of two smart contracts which are the main smart contract implementation called CrowdSourcing.sol and the factory used to create other proxies from the main contract called CrowdSourcingFactory.sol. There is also an interface called ICrowdSourcing.sol that has some methods signature.

The project

The project was set up using hardhat and selecting the advanced project setup with Typescript.

Code

EIP-1167 minimal proxies of Ethereum proposed how to save gas when deploying the same contract on the blockchain. The contract crowdSourcing is the main contract which is deployed first and its deployed address is attached to the factory contract (crowdSourcingFactory) to use to create proxy contracts off the main contract. The code makes use of Openzepplein Clones library to create clones of the deployed crowd sourcing contract.

A schematic representation:

A user who wants to create a new crowd sourcing contract calls the contract factory which creates new proxy contracts with their own state. This is done by delegateCall. The crowd sourcing master contract is firstly deployed and its address is passed on to the factory contract that will create clone of the master contract.

crowdSourcing.sol

  //SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
import "@openzeppelin/contracts/utils/math/Math.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/proxy/utils/Initializable.sol";

contract CrowdSourcing is Ownable, Initializable {
    string public purpose;
    uint256 public targetAmount;
    uint256 public amountDonated;
    mapping(address => uint256) public donors;
    address[] public donorsAddress;
    address public deployer;
    bool public campaignRunning;

    //Events
    event DonationMade(address indexed donorAddress, uint256 amount, string indexed crowdsource );
    event DonationWithdrawn(address indexed receipient, uint256 amount, string indexed crowdsource);

    struct DonorsAmount {
        address donorsAddress;
        uint256 amount;
    }

    function initialize(string memory _purpose, uint256 _targetamount, address _deployer) public initializer {
        purpose = _purpose;
        targetAmount = _targetamount;
        campaignRunning = true;
        deployer = _deployer;

        //Ownable.initialize(msg.sender);
    }

    function donateToCause() public payable isCampaignOn   {
      require(msg.value > 0, "donation of 0 ether made");
      require(msg.sender != address(this), "contract cannot make donation");
      //add the amount to the amountDonated
      amountDonated += (msg.value);
      //check if we have a donation made before
      bool exists = donors[msg.sender] != 0;
       //include addres and amount in the mapping donors
      donors[msg.sender] += msg.value;
      if ( !exists ){
          //push address to the donors addresss
          donorsAddress.push(msg.sender);
      }

      //emit a Donation Made event
      emit DonationMade(msg.sender, msg.value, purpose);
    }

    function withdrwaDonation() public payable isCampaignOn isDeployer {
        require(amountDonated > 0, "Nothing to withdraw");
        campaignRunning = false;
        payable(address(msg.sender)).transfer(amountDonated);
        emit DonationWithdrawn(msg.sender, amountDonated, purpose);
    }

    function getDonorsList() public view returns (DonorsAmount[] memory){
        uint256 totalDonors = donorsAddress.length;
        DonorsAmount[] memory donorsArray = new DonorsAmount[](totalDonors);
        for (uint256 i=0; i < totalDonors; i++){
            address currentAddress = donorsAddress[i];
            uint256 amount = donors[currentAddress];
            donorsArray[i] = DonorsAmount(
                currentAddress,
                amount
            );
        }
        return donorsArray;
    }


    modifier isCampaignOn {
        require(campaignRunning == true, "Campaign is not running");
        _;
    }

    modifier isDeployer{
        require(deployer == msg.sender, "caller not deployer");
        _;
    }
}

The contract declares some state variable for storing data that is peculiar to each created proxy contract.

variables in contract

purpose : to store the purpose for the crowd funding
targetAmount : to store the amount hoped to raised
amountDonated : to store how much has being donated
donors : a mapping used to store the address of donors and amount donated
donorsAddress : to store the address of each donor. This is useful because we want the ability to be able to pull out all the donors and their donated amount. See Iterable map pattern
deployer : to store the person that deployed the contract
campaignRuning : a boolean to check if the campaign is running
DonationMade : event that is fired when a donation is made
DonationWithdrawn : event that is emitted when the donation is withdrawn

Contract function

initialize

The contract has an initialize function that is called when the contract is created by the factory. The initialize function acts like a constructor as it is called once. OpenZeppelin Initializable contract which is inherited ensures that the initialize function is only called once. The deployer variable is used to store the address of the person that deploys the contract.

donateToCause

This function is called when someone makes a donation to your cause. It stores the address of the donor and the amount in the donors variable. A DonationMade event is emitted on a successful donation.

withdrwaDonation

This function can only be called by the owner of the crowd sourcing contract to withdraw the donation made. The DonationWithdrawn event is emitted on a successful withdrawal.

getDonorsList

This function is used to get the list of donors.

crowdSourcingFactory.sol

  // SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/proxy/Clones.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import "./ICrowdSourcing.sol";


contract CrowdSourcingFactory is Ownable {
    address public implementation;
    address[] public allCrowdSource;
    mapping(bytes32 => address ) private idToAddress;


    constructor(address _implementation) {
        implementation = _implementation;
    }

    function createCrowdSourceContract(string memory _purpose, uint256 _targetamount, address _deployer) 
    external payable returns (address crowdContract){
        bytes32 id = _getOptionId(_purpose, _targetamount);
        require(idToAddress[id] == address(0), "Crowd sourcing type exist");
        bytes32 salt = keccak256(abi.encodePacked(_purpose, _targetamount));
        crowdContract = Clones.cloneDeterministic(implementation, salt);
        ICrowdSourcing(crowdContract).initialize(_purpose, _targetamount, _deployer);
        allCrowdSource.push(crowdContract);
        idToAddress[id] = crowdContract;
    }

    function getCrowdSource(string memory _purpose, uint256 _amount ) public view returns (address){
        bytes32 id = _getOptionId(_purpose, _amount);
        return idToAddress[id];
    }

    function _getOptionId(string memory _purpose, uint256 amount) internal pure returns (bytes32){
        return keccak256(
            abi.encodePacked(_purpose, amount)
        );
    }

    function getNumberofCloneMade() public view returns (uint256) {
        return allCrowdSource.length;
    }
}

variables in contract factory

implementation : this stores the address of the master contract (CrowdSourcing)
allCrowdSource : this stores the address of all the created proxy contract
idToAddress : this stores a mapping in bytes of the contract purpose and the targeted amount.

Contract functions

constructor

This sets the address of the master contract in the factory contract. The factory creates proxies from the master.

createCrowdSourceContract

This function accepts three arguments which are the purpose of the crowd sourcing, the targeted amount and the address of the deployer. This function is used to create a proxy contract. The function firstly checked if an exact contract with the same name and target sum already exist. It does this by an internal function called _getOptionId If a contract with such parameters does not exists, it encodes the purpose and target sum of the contract into bytes. The factory uses the Clones contract imported from Openzeppelin to create clones by passing address of the already deployed master contract and the encoded bytes to the Clones.cloneDeterministic function which returns the address of the proxy contract.

crowdContract = Clones.cloneDeterministic(implementation, salt);
crowdContract is the address of the created proxy.
ICrowdSourcing(crowdContract).initialize(_purpose, _targetamount, _deployer);
We imported the interface ICrowdSourcing and used it with the created proxy address by calling the function initialize with the three parameters which are : purpose, targetAmount and deployer.

I noticed that calling msg.sender in the initialize function equated to the zero address. That's why I explicitly passed the address of the deployer.

getCrowdsource

This is used to get the address of the deployed proxy contract by passing in the purpose of the contract and the target amount hoping to raise.

getNumberofCloneMade

This function returns the number of clones made. It reads and returns the length of the allCrowdSource array.

Summary

The EIP-1167 minimal proxy is the cheapest way to clone contract and this post has talked about how that can be done. Thanks for reading.

Abstract Contract and Interfaces in Solidity

Jamiebones — Tue, 01 Feb 2022 17:59:35 +0000

Abstract Contract

An abstract contract is one that cannot be deployed by itself. An abstract contract must be inherited by another contract. An abstract contract is somewhat similar to an interface but there exist some differences between them. An abstract contract can defined functions signature and can also have implementation for some of its functions.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
abstract contract SayHello {
    uint256 public age;
    constructor(uint256 _age ){
        age = _age;
    }

    function getAge() public virtual view returns (uint256){
        return age;
    }
    function setAge(uint256 _age) public virtual {}
    function makeMeSayHello() public  pure returns (string memory) 
    {
        return "Hello";
    }
}

The above contract SayHello has four functions of which one of them setAge is a function signature which an inheriting contract can choose to implement. The abstract contract above can not be deployed on its own like a normal contract. It has to be inherited. The contract has a constructor function and you can also defined state variables on an abstract contract like you will do for a normal contract.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
abstract contract SayHello {
    uint256 public age;
    constructor(uint256 _age ){
        age = _age;
    }

    function getAge() public virtual view returns (uint256){
        return age;
    }
    function setAge(uint256 _age) public virtual {}
    function makeMeSayHello() public  pure returns (string memory) 
    {
        return "Hello";
    }
}

contract Hello is SayHello {
    string public name;
    constructor(string memory _name  ,uint256  _age)  
     SayHello(_age) {
       name = _name;
    }

    function setName(string memory _name ) public {
        name = _name;
    }

    function getName() public view returns (string memory){
        return name;
    }

    function getAge() public override virtual view returns 
    (uint256){
        return 67;
    }

    function setAge(uint256 _age ) public override virtual {
        age = _age;
    }
}

In the solidity contract above, our contract Hello is inheriting the abstract contract SayHello. The abstract contract SayHello has a constructor function which the inheriting contract Hello calls in its own constructor. The Hello contract can choose to override all the functions of the abstract contract with its own implementation but an inheriting contract like the Hello contract must at least implement one function of the abstract contract or it will be marked as abstract.

Interfaces

An interface is similar to an abstract contract as it must be inherited by another contract like the abstract contract. An interface functions visibility must be marked as external. It cannot have a constructor neither can it declare state variables.

sample interface implementation

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

interface ISayHello {
    function getAge() external view returns (uint256);
    function setAge(uint256 _age) external view returns (uint256);
    function makeMeSayHello() external view returns (string memory); 
}

An interface must not inherit from another contract or interface and an inheriting contract must implement all the functions of that interface.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
interface ISayHello {
    function getAge() external view returns (uint256);
    function setAge(uint256 _age) external ;
    function makeMeSayHello() external view returns (string memory); 
}

contract HelloAgain is ISayHello {
   uint256 public age;
    function getAge() public pure override returns (uint256) {
      return 33;
   }
   function setAge(uint256 _age) public override {
      age = _age;
   }
   function makeMeSayHello() public pure override returns (string memory) {
      return "Hello again";
   }
 }

The function HelloAgain inherits the interface ISayHello which must override and implement all the functions of the interface. If any of the function is not overridden, the compiler complains and ask you to mark the inheriting contract as abstract.

Difference between abstract contract and an interface

An interface cannot have a constructor while an abstract contract can implement one.
An interface cannot define state variables but an abstract contract can.
An inheriting contract must implement all the functions defined in an interface while in an abstract contract the inheriting contract must implement at least one function of the abstract contract.
An abstract contract can inherit from another contract or abstract contract while an interface cannot inherit from a contract or another interface.

Interfaces and abstract contracts are arsenals in our toolkit that we could use for the development of smart contracts.

Thanks for reading...

ERC 721 The NFT Standard

Jamiebones — Fri, 21 Jan 2022 15:38:49 +0000

ERC 721 represent the standard for the minting and transfer of Non Fungible Token otherwise known as NFT. A non fungible token is a token that is unique and different from another. It cannot be broken down into smaller pieces unlike the ERC 20 tokens that are divisible to smaller pieces.

NFT are revolutionary right now and they represent the future. An NFT could represent anything from a media file, to a digital art, certificate, title deeds or a lease agreement. The use of NFT is enormous and knowing how they work is the goal of this blog post.

ERC 721 Standard

The ERC 721 is the standard that defines the methods, events and state variables that a non fungible token (NFT) should posses to be compliant.

Interface of ERC 721

The ERC 721 standard for NFT is more complicated than the one of ERC 20. It spans several interface and contracts with some marked as core while others are optional. Below is the OpenZepplin implementation of the contract interface.

 // SPDX-License-Identifier: MIT
// OpenZeppelin Contracts v4.4.1 (token/ERC721/IERC721.sol)

pragma solidity ^0.8.0;

interface IERC721 is IERC165 {

    event Transfer(address indexed from, address indexed to, uint256 indexed tokenId);
    event Approval(address indexed owner, address indexed approved, uint256 indexed tokenId);
    event ApprovalForAll(address indexed owner, address indexed operator, bool approved);
    function balanceOf(address owner) external view returns (uint256 balance);
    function ownerOf(uint256 tokenId) external view returns (address owner);
    function safeTransferFrom(
        address from,
        address to,
        uint256 tokenId
    ) external;
    function transferFrom(
        address from,
        address to,
        uint256 tokenId
    ) external;
    function approve(address to, uint256 tokenId) external;
    function getApproved(uint256 tokenId) external view returns (address operator);
    function setApprovalForAll(address operator, bool _approved) external;
    function isApprovedForAll(address owner, address operator) external view returns (bool);
    function safeTransferFrom(
        address from,
        address to,
        uint256 tokenId,
        bytes calldata data
    ) external;
}

Interface of ERC 165

The ERC 721 interface inherits from ERC 165. The ERC 165 is a contract that is used for standard interface detection. It allows the client/caller to check if a function is available for call in the target contract.

The interface IERC 165 which ERC 165 inherits from defines the following function:

function supportsInterface(bytes4 interfaceId) external view returns (bool)

Variables and state in ERC 721 standard

The following are the state variables defined in the standards implementation by OpenZepplin.

Token owner mapping

This is a mapping of uint256 to an address. It is used to find the owner of a given NFT ID

  mapping(uint256 => address) private _tokenOwner;
  function ownerOf(uint256 tokenId) public view returns (address){
    address owner = _tokenOwner[tokenId];
    require(owner != address(0);
    return owner;
}

The _tokenOwner mapping is private preventing direct access. To get value from the _tokenOwner mapping, the function ownerOf which accepts a uint256 as a tokenId is used to find the address associated with an NFT.

Approved address mapping

The owner of a NFT can give approval to another address. Once the approval is given, that address will be able to transfer the NFT from the owner to themselves or another address. This approvals is managed by a mapping called _tokenApprovals.

 mapping(uint256 => address) private _tokenApprovals;
 function getApproved(uint256 tokenId) public view returns (address) {
   require(_exists(tokenId));
   return _tokenApprovals[tokenId];
}

The mappings _tokenApprovals is used to store the approval given by a token owner to an address. This approval allows that address to transfer the token on behalf of the owner. This mapping is private and the function getApproved is used to pull out the address that is allowed to transfer a particular NFT on behalf of an owner. The getApproved function uses an internal function _exists to check if the provided tokenid is a valid NFT ID on the smart contract.

Number of token owned per owner

This state variable is used to track and store the number of token owned by an address in a contract. It consist of a mapping with an address as the key and uint256 as the number of tokens owned.

  mapping(address => uint256) private _ownedTokensCount;
  function balanceOf(address _owner) public view returns (uint){
     require(_owner != address(0));
     return _ownedTokensCount[_owner];
  }

Operator approval

An operator is a third party that is trusted and can be approved by an owner to have access to all the NFTs owned by them. If an owner gives permission to an operator, that operator is allowed to withdraw any NFT from that owner's address and they are allowed to transfer it to themselves or others.

The operator approval is stored in a nested mapping data structure.

The operator approval is different from the tokenApproval. The operator approval grants the right to an operator to be able to withdrawal potentially all the NFTs from an owner's address while in the tokenApproval, the owner gives an address permission to be able to withdraw just a particular NFT.

  mapping(address => mapping(address => bool)) private _operatorApproval;
function setApprovalForAll(address to, bool approved) public {
   require(to != msg.sender);
   _operatorApproval[msg.sender][to] = approved;
   emit ApprovalForAll(msg.sender, to, approved);
}

function isApprovedForAll(address owner, address operator) public view returns (bool) {
  return _operatorApproval[owner][operator];
}

The function setApprovalForAll is used to grant approval to an address (operator like Open Sea) access to manage your NFTs. The function checks and ensure that the to address is not the same as msg.sender. Then it proceeds to save the approval on the state variable _operatorApproval. The owner of the NFTs is the caller of this function.

The next function isApprovedForAll checks if an operator has approval to an owner's NFTs. It returns the value stored in the state variable _operatorApproval.

ERC 721 standard functions

The standard contains some useful functions for the management and transfers of NFTs. Below is the implementation of some of this functions by OpenZepplin

Constructor

  constructor(string memory name_, string memory symbol_) {
        _name = name_;
        _symbol = symbol_;
    }

OpenZepplin implementation of ERC 721 standard also inherits from IERC721Metadata interface that stipulates that an NFT contract should have a name and a symbol. The constructor accepts two string parameters that are used to set the name and symbol of the NFTs contarct.

balanceOf

This is used to check how many NFTs does someone own.

ownerOf

This is used to check the owner of a particular NFT.

  function ownerOf(uint256 tokenId) public view returns (address) {
     address owner = _owners[tokenId];
     require(owner != address(0), "ERC721: owner query for nonexistent token");
        return owner;
    }

approve

The approve function is used to grant approval by the NFT owner of a particular NFT token to an address for the purpose of helping to administer that NFT. The function checks firstly, if the msg.sender is the token owner or has approval to the token. if all checks clears, the _tokenApprovals state variable is updated with the tokenId pointing to the to address. ( this means the to address can manage that token )

   function approve(address to, uint256 tokenId) public virtual override {
        address owner = ownerOf(tokenId);
        require(to != owner, "ERC721: approval to current owner");
        require(msg.sender == owner || isApprovedForAll(owner, 
        msg.sender),
            "ERC721: approve caller is not owner nor approved for 
        all");
        _tokenApprovals[tokenId] = to;
        emit Approval (owner, to, tokenId);
    }

getApproved function

This function implementation is defined above. It is used to return the address that is approved to manage an NFT.

setApproval for all

This function is used to grant an operator full access to all the NFTs available in an owner's address.

isApprovedForAll

This function returns a boolean showing if an operator has access or not to an owner NFts.

transferFrom

This is a public function used to transfer the NFT from the owner's account to the receiver's account. For this function to work, approval must have been given prior by the owner of the NFT to an address for the purpose of managing the NFT.

The function accepts three parameters which are :

from : address of the NFT owner
to: the address of the receiver
tokenId: the ID of the NFT to transfer.

Before the transferFrom function is called, the NFT owner must first approve that msg.sender calling the function has the approval to transfer that NFT. This is done by the owner by calling the approve function.

Implementation of transferFrom function

  function transferFrom(address from, address to, uint256 tokenId) public {
  require(_isApprovedOrOwner(msg.sender, tokenId);
  _transfer(from, to, tokenId);
}

function _isApprovedOrOwner(address spender, uint256 tokenId) internal view virtual returns (bool) {
        require(_exists(tokenId), "ERC721: operator query for nonexistent token");
        address owner = ownerOf(tokenId);
        return (spender == owner || getApproved(tokenId) == spender || isApprovedForAll(owner, spender));
    }

The function checks if the msg.sender is the owner of the NFT, or has approval to manage the NFT. If it does the transfer is executed by the internal function _transfer.

safeTransferFrom

This is a public function that is used to safely transfer the NFT from the owner's account to the recipient account. Safely means that, if the recipient is a contract, you will need to ensure, that the contract has callbacks registered to let it know when a NFT was successfully transferred to it.

The function takes the following parameters :

from: the address of the current owner of the NFT
to: the recipient of the NFT
tokenId: the ID of the NFT to be transferred
_data : the bytes data that is forwarded if to is a contract.

Implementation of safeTransferFrom

function safeTransferFrom(address from, address to, uint256 tokenId, bytes memory _data) public {
   _transfer(from, to, tokenId);
   require(_checkOnERC721Received(from, to, tokenId, _data), "ERC721: transfer to non ERC721Receiver implementer");
}

The safeTransferFrom function has two overloads. One overload function is used to transfer NFT to an EOA address (externally owned account ), that is an account address in our wallet. This overload for transferring to an EOA receives only three (3) parameters. The last _byte parameter is missing.

The other overloaded of the safeTransferFrom function is used to transfer NFT to a contract address. For a contract to be able to receive NFT, it must implement the IERC721Receiver interface. This interface specifies that a contract that wants to accept NFTs must implement the function named onERC721Received.

   function onERC721Received(
        address operator,
        address from,
        uint256 tokenId,
        bytes calldata data
    ) external returns (bytes4);

_mint internal function

The _mint internal function is used to mint a new NFT at the given address. The function takes two arguments which are:

to: the address of the owner for which the NFT is minted
tokenId: the new unique tokenId for the token to be minted

When the _mint function is called a Transfer event is emitted.

_burn internal function

This internal function is used to destroy or burn a given NFT from the owner's address. It accepts two parameters which are:

owner : the address of the owner whose token is to be burned
tokenId : the tokenId of the NFT to be burned

Summary

The ERC 721 standard has a lot of functions, events that is necessary for the transfer of NFTs. I just covered a bit of them here to prevent this blog post for becoming too long. In my next blog post, I will show how to create a contract to mint NFTs.

Until then, thanks for reading.

Happy coding!

DEV Community: Jamiebones

Indexing Smart Contract Data Using The Graph Protocol

Introduction

Developer

Indexer

Delegator

Curator

Creating a subgraph

Creating a Schema

Updating the Manifest file.

Creating mapping handler

Deploying the subgraph to the studio

Writing queries to query our subgraph

Gas Saving Techniques in Solidity

Use constant and immutable variables for variable that don't change

Cache read variables in memory

Incrementing and Decrementing by 1

calldata and memory

Calling a view function

Integer overflow/underflow

Use revert instead of require

Avoid loading too many data in memory

Other tips

Getting Started With GraphQL and Apollo-Server

Schema

Query and Mutation types

Resolvers

Apollo Server

Create a new NodeJS project

Creating the Schema

Mutation

How to Create and Deploy an NFT Smart Contract

Uploading NFT Media File

Uploading NFT Metadata

Create the Smart Contract

How To Call Other Contracts In Solidity

Passing value to an external contract call

Creating Upgradable Solidity Contract With Hardhat

Project Dependencies

Project

How Upgradable Contract Works

Verify Upgradable Contract

Things to know when working with Upgradable Contracts

Summary

Solidity Data Storage Location

Summary

How To Deploy And Verify A Smart Contract From Remix

Deploying a contract

Verifying deployed contract

How to Connect to Metamask Wallet in React

Packages to install

Auto connecting

Creating A Crowd Sourcing Solidity Contract

Description

The project

Code

crowdSourcing.sol

variables in contract

Contract function

initialize

donateToCause

withdrwaDonation

getDonorsList

crowdSourcingFactory.sol

variables in contract factory

Contract functions

constructor

createCrowdSourceContract

getCrowdsource

getNumberofCloneMade

Summary

Abstract Contract and Interfaces in Solidity

Abstract Contract

Interfaces

Difference between abstract contract and an interface

ERC 721 The NFT Standard

ERC 721 Standard

Interface of ERC 721

Interface of ERC 165

Variables and state in ERC 721 standard

Calling a `view` function