DEV Community: Abdul Azeez V

How to setup domains and subdomains in localhost

Abdul Azeez V — Tue, 15 Oct 2024 09:56:58 +0000

I was developing a web app having multiple independent apps that meant to be run at different subdomains. So i wanted to mock this domain system in localhost.

Setup

For demo let assume, we have two apps running on ports 3000 (a NextJs Frontend) and 5000 (a ChatApp).

We need to add the all dns mapping to /etc/hosts file.

sudo nano /etc/hosts # linux, macos
notepad C:\\Windows\\System32\\drivers\\etc\\hosts # windows (Run cmd as Administrator)

Add the domains we need to the end of file. for example:

127.0.0.1 example.local
127.0.0.1 chat.example.local

Install and import required packages

yarn init
yarn add express vhost http-proxy-middleware

const express = require('express');
const vhost = require('vhost');
const { createProxyMiddleware } = require('http-proxy-middleware');

const app = express();

Create proxies for apps running on a NextApp running on port 3000

const nextAppProxy = createProxyMiddleware({
  target: 'http://localhost:3000',
  changeOrigin: true,
  ws: true,          // Add ws support
  logLevel: 'debug', // Add logging for debugging
});

Create proxy for app running on port 5000

const chatAppProxy = createProxyMiddleware({
  target: 'http://localhost:5000',
  changeOrigin: true,
  ws: true,         // Add ws support
  logLevel: 'debug' // Add logging for debugging
});

// Set up virtual hosts
app.use(vhost('example.local', nextAppProxy));
app.use(vhost('chat.example.local', chatAppProxy));

app.listen(80, () => {
  console.log('Vhost proxy server running on port 80');
});

Now the NextJs frontend will be accessible on address example.local and chat app will be at chat.example.local

Huraay 😍😍

Complete Code

Demystifying Account Abstraction

Abdul Azeez V — Sun, 14 Jul 2024 15:10:37 +0000

What if your crypto wallet got hacked or you forgot the seed phrase? You lost complete access to your funds, right?

Not anymore.

Nowadays account abstraction is a word we always hear in the web3 circles. It is considered a significant step towards the mass adoption of web3 technology.

So by definition, account abstraction is:

A concept in blockchain technology that separates the control logic of an account from the account itself, allowing for more flexible and programmable account behaviors

What does that mean? What benefits does it bring? Let's go deep by understanding how accounts and transactions work in Ethereum.

Accounts in Ethereum

There are two types of accounts in Ethereum:

Both EOA and smart contracts can store assets like NFTs and tokens. But, only EOA can initiate a transaction. Smart contracts can store code run on EVMs, while EOA can't. There are no private key associated with smart contracts.

In Ethereum Externally owned accounts (EOAs) initiate a transaction, sign it with private key and send it to mempool which is validated by validators. The private key kept by the user is the only barrier to accessing the crypto assets. Account abstraction intends to abstract away this dependancy.

Block theory has a good explanation on this here

Demerits of EOA accounts:

Loss of Private key results in total loss of funds
Recovery of wallets not possible
The transaction requires paying gas directly from the EOA
Bad User Experience
Limited Functionality

Smart Contract Wallets (SWC)

We can overcome the private key issue by using smart contracts as our wallets, or Smart contract wallets (SCW).

Using SCWs we can abstract the signature from asset ownership. Multi-signature wallets can be implemented using smart contracts which increases security. But still, an EOA is needed to initiate the transaction.

Account Abstracted Wallets

Account abstraction aims to detach the validity conditions of a transaction like signature verification, gas payment, nonce increase, and chain compatibility to an EVM smart contract level.
How to do it?

History of Account Abstraction

Achieving account abstraction has been a long-time dream of many Ethereum developers. It was initially proposed as EIP-86 by Vitalik Buterin 2016. However, it needed significant changes to the protocol. EIP 1014, EIP 2938 and EIP 3074 are some of the proposals that helped in the development of account abstraction architecture.

EIP 4337

EIP 4337 was the last proposal for Account Abstraction in Ethereum. It introduced a concept of pseudo transactions called UserOperations (UserOps). UserOps decouples the transaction validation from the consensus layer through an alternative mempool (altmempool)

In EIP 4337, UserOps are sent to an altmempool by the user which is picked by a bundler. Bundler act as proxy EOAs, bundling the UserOperations and sending them to a global singleton EntryPoint contract. The entry point calls the smart contract accounts deployed, which have the code to validate transactions. After successful validation, the transaction is executed.

Paymaster is a smart contract that sponsors the gas fees for UserOps, enabling gasless transactions for end users. It abstracts the gas payment from the user and allows user-friendly transaction models like ERC20 tokens, etc. Users don't need ETH anymore to pay for gas.

The Transaction validation through smart contracts allows the possibility of signing transactions using social logins, biometrics, etc.

Benefits of AA:

Enhanced Security: Multi-sig, social recovery, and other security mechanisms.
Recovery Options: Built-in recovery mechanisms to regain access.
Sponsored Transactions: Can pay gas using alternative methods or tokens.
Improved UX: Abstracts away private key management for users.
Batch Transactions: Multiple operations can be bundled and executed atomically
Custom Authentication: Authentication methods like biometrics, social recovery, or hardware wallets.
Account Segmentation
No need for EOA to initiate a transaction

LinkedIn | Github

How to disable cache in Xampp and NodeJs Server

Abdul Azeez V — Fri, 07 Jun 2024 17:13:17 +0000

When developing frontend sometimes i use NodeJs and Xampp as servers. Sometimes Caching of static files becomes a problem such as styles dont update even though the css files are modified. So i needed to disable the caching.

XAMPP Server

Edit httpd.conf ([xampp folder]/apache/conf/http.conf) file and add following at the end:

# Don't cache html, htm, js, css

<filesMatch "\.(html|htm|js|css)$">
  FileETag None
  <ifModule mod_headers.c>
     Header unset ETag
     Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
     Header set Pragma "no-cache"
     Header set Expires "Wed, 11 Jan 1984 05:00:00 GMT"
  </ifModule>
</filesMatch>

NodeJS Server

Use nocache module.

pnpm i nocache

const nocache = require('nocache');
app.use(nocache());

Use set etag to false

app.set('etag', false);

Make NFT using ERC721

Abdul Azeez V — Wed, 22 May 2024 03:55:56 +0000

What is ERC721 ?

ERC721 is a standard that describes how to build NFTs on EVM compatible blockchains. We use the OppenZeppelin implementaion of ERC721

Let's make the NFT

First we need to setup the images and the metadata describing each image. We are creating 6 NFTs. So we have 6 images and metadata files in a directory.

The Metadata JSON Schema is given Metadata Schema

{
    "name": "MyNFT Collection #1",
    "description": "My First NFT.",
    "image": "ipfs://imageBaseURI/1.png"
}

Metadata needs the image path. So upload images folder to IPFS first. I used pinata here.

Now use the image directory CID to correct metadata files.

{
    "name": "MyNFT Collection #1",
    "description": "My First NFT.",
    "image": "https://gateway.pinata.cloud/ipfs/<PASTE_CID_HERE>/1.png"
}

Upload the metadata files to the IPFS. Now we have both NFT images and metadata in IPFS.

Now we can deploy the contract and mint the NFT.

Smart Contract

Lets import packages needed.

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

Now the contract extends ERC721:

contract MyNFT is ERC721, ERC721URIStorage, Ownable {
    uint256 private _nextTokenId;

    constructor(address initialOwner)
        ERC721("MyNFT", "MNT")
        Ownable(initialOwner)
    {}

    // functions goes here ...
}

Additional functions needed:

    function safeMint(address to, string memory uri) public onlyOwner {
        uint256 tokenId = _nextTokenId++;
        _safeMint(to, tokenId);
        _setTokenURI(tokenId, uri);
    }

    function tokenURI(uint256 tokenId)
        public
        view
        override(ERC721, ERC721URIStorage)
        returns (string memory)
    {
        return super.tokenURI(tokenId);
    }

    function supportsInterface(bytes4 interfaceId)
        public
        view
        override(ERC721, ERC721URIStorage)
        returns (bool)
    {
        return super.supportsInterface(interfaceId);
    }

Complete code

Deploy contract using hardhat

Install hardhat

npx hardhat init

Get a JSON RPC url from Infura/Alchemy. Setup the hardhat.config.json.

Use the script to deploy and mint the NFT:

const hre = require("hardhat");

async function main() {
     // Deploy contract with initial owner address
     const contract = await hre.ethers.deployContract("MyNFT", ["0xcF469d3BEB3Fc24cEe979eFf83BE33ed50988502"], {});

    await contract.waitForDeployment();

    console.log("Contract deployed to:", contract.target);

    const uris = [
      "https://gateway.pinata.cloud/ipfs/<PASTE_CID_HERE>/1.json",
      "https://gateway.pinata.cloud/ipfs/<PASTE_CID_HERE>/2.json",
      "https://gateway.pinata.cloud/ipfs/<PASTE_CID_HERE>/3.json",
        // Add more URIs as needed
    ];

    for (let i = 0; i < uris.length; i++) {
        const recipientAddress = "0xYourRecipientAddressHere"; // Replace with the actual recipient address
        await myNFT.safeMint(recipientAddress, uris[i]);

        console.log(`Minted NFT with URI ${uris[i]} to address ${recipientAddress}`);
  }
}

main().catch((error) => {
    console.error(error);
    process.exitCode = 1;
});

Now we created and deployed an NFT using ERC721

Github | LinkedIn

How to Implement a Whitelist in NFT contracts using Merkle Tree

Abdul Azeez V — Sun, 19 May 2024 10:31:23 +0000

Story

I was recently trying to make a fan club nft for a web3 community. The project required that only members could mint a limited NFT collection, so I needed to implement a whitelist for the minting function. Here are some solutions I found online:

Store the whitelist onchain in nft contract
Store whitelist in serverside and call nft minting from there only by a preselected wallet.
Using merkle tree implementation

I chose the third one cause it has more advantages over others.

Undrestanding merkle tree

Merkle tree is a tree data structure where each non-leaf node is a hash of it's child nodes

How it is solving our problem ?

If we generate a merkle tree using our whitelist we only need to store the single merkle root hash onchain, not the entire list. By just using the merkle root hash and the merkle proof created on server side, we can verify wether the address is in whitelist or not.

This method reduces the amount of data stored onchain and gas fee needed for the operation.

Read to undrestand more: link

Merkle tree white list implemetation

First, create the whitelist database in the server and compute merkle root hash of the whitelist.

import { ethers } from 'ethers'
import { MerkleTree } from 'merkletreejs'

// Your whitelist from database
const whitelist = [
  '0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC',
  '0x90F79bf6EB2c4f870365E785982E1f101E93b906',
  '0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65',
  '0x9965507D1a55bcC2695C58ba16FB37d819B0A4dc',
  '0x976EA74026E726554dB657fA54763abd0C3a0aa9',
]

const { keccak256 } = ethers.utils
let leaves = whitelist.map((addr) => keccak256(addr))
const merkleTree = new MerkleTree(leaves, keccak256, { sortPairs: true })

// We need to store this hash in NFT contract
const merkleRootHash = merkleTree.getHexRoot()

// 0x09485889b804a49c9e383c7966a2c480ab28a13a8345c4ebe0886a7478c0b73d

Create a NFT contract using any of the NFT standards (ERC721, ERC1155 etc). Add functions that can verify the merkle proof.


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

import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/utils/cryptography/MerkleProof.sol";

contract MerkleTreeWhitelistContract is Ownable {

    // merkle root hash computed before
    bytes32 public merkleRoot = 0x09485889b804a49c9e383c7966a2c480ab28a13a8345c4ebe0886a7478c0b73d;

    // function to change metkle root after deployment
    function setMerkleRoot(bytes32 merkleRootHash) external onlyOwner
    {
        merkleRoot = merkleRootHash;
    }

    // function to verify merkle proof
    function verifyAddress(bytes32[] calldata _merkleProof) private 
    view returns (bool) {
        bytes32 leaf = keccak256(abi.encodePacked(msg.sender));
        return MerkleProof.verify(_merkleProof, merkleRoot, leaf);
    }

    // White list checker function
    function whitelistFunc(bytes32[] calldata _merkleProof) external
    {
        require(verifyAddress(_merkleProof), "INVALID_PROOF");

        // Do some useful stuff
    }
}

When the user clicks a button on your website, you send the request to your server with the user's address. If the user is in the whitelist, create the Merkle proof on your server:

import { ethers } from 'ethers'
import { MerkleTree } from 'merkletreejs'

export default async function handler() {

  // whitelist stored in database
  const whitelist = [
    '0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC',
    '0x90F79bf6EB2c4f870365E785982E1f101E93b906',
    '0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65',
    '0x9965507D1a55bcC2695C58ba16FB37d819B0A4dc',
    '0x976EA74026E726554dB657fA54763abd0C3a0aa9',
  ]

  // Variable to store merkle proof
  let proof = []

  const userWalletAddress = 'PASTE_USER_WALLET_ADDRESS_HERE'

  if (whitelist.includes(userWalletAddress)) {
    const { keccak256 } = ethers.utils
    let leaves = whitelist.map((addr) => keccak256(addr))
    const merkleTree = new MerkleTree(leaves, keccak256, { sortPairs: true })
    let hashedAddress = keccak256(userWalletAddress)
    proof = merkleTree.getHexProof(hashedAddress)
  }

  // Send this proof to NFT contract along with other data
}

Using this merkle proof and merkle root already stored onchain, the contract can verify whether the address allowed to mint the nft operation or not.

Problem solved 😻