DEV Community: Murat Can Yüksel

I've made Huff docs Simple Storage page simpler for newcomers

Murat Can Yüksel — Sat, 28 Sep 2024 16:02:00 +0000

To all web3 devs & security researchers and auditoooors who are interested in learning the hashtag#huff language, I've made some changes on the Simple Storage example on the official docs. Because I found that part quite difficult to understand, and had to use chatgpt extensively to understand those low level operations like getting the first 4 bytes for calldata, or shifting the 32 bytes arguments to the right by 28 bytes (224 bits). Even when writing, bytes, bits, words, confuses me bro.

Huff helps me understand the EVM better, I suppose. Also it is a fun thing to interact with the machine directly. It makes me feel like I'm a cool hacker 😋

Since the original repo is archived and not actively maintained, I couldn't create a pull request so I just forked the repo and redeployed (hey, I was a web developer. I'm happy those skills are still handy).

You can access the modified docs page here => https://huff-docs.vercel.app/tutorial/simple-storage/#simple-storage-implementation

So, if you're a newbie and want to learn more about Huff and the EVM, heck it out.

If you're a seasoned web3 dev, auditooor or optimizoooor, please check it out and correct any mistakes I might have made. I don't want to spread false info.

x0x0 gossip dev

On fuzzing, fuzz testing, stateless and stateful fuzzing, and then invariant testing and all those scary stuff

Murat Can Yüksel — Tue, 02 Jul 2024 07:23:42 +0000

For blockchain developers only

You might've heard the scary terms fuzzing, fuzz tests, invariant testing, stateless fuzzing etc. They're not as scary as they sound. But, what are they?

If you're a developer, you know about unit tests. What do they do? They isolate and test. What will happen if I call this function with this value, will it pass or fail? They're super important and handy in all parts of development. But, when you're building, say, a big DeFi app you really might want to add fuzz tests alongside with your unit tests. Why, and again man, what are they? Fuzzing, invariant testing and all?

People are mad. They do all sorts of crazy stuff. They're highly unpredictable. Especially when there's money, a substantial amount of money involved. So, it would be beneficial to assume that there will be people who'll try to break your application. Even if they don't try, your application might just crash in certain edge cases. You can't just try to think of every single situation that might occur in your colossal dApp, right? Now fuzzing comes to rescue.

Fuzz tests rush to your function(s) with hundreds, if not thousands of times with random data. Say that you have a function that takes a parameter and does an operation with it. In unit testing you'd give that parameter a value, you'd choose it. Fuzz tests give all sorts of random values to that parameter to try to break it. And if you're using Foundry, it is super easy to write them. You just write them like unit tests (with a couple of gotchas that I won't be talking about in this not-so-technical post) and instead of giving your parameter a value, you just leave it untouched. Foundry then knows that it should do fuzzing.

Okay, so fuzzing is when you basically attack your dApp with so many random cases to see if it'll break. Now, let's talk about invariant (stateful) and stateless fuzzing. They sound even scarier, but again, they are not.

Stateless fuzzing is easier to grasp. You have a function or functions, and you want to call them with random data, many times. All good.

But, what if you needed to call a function after a function precisely? Like, let's say you want to call a redeem function that your users can call when they want to take their money out, but if they don't yet have put any money (say, via a deposit function), how can they possibly call the redeem function? You most probably already wrote modifiers and checks for that situation. But, if you run stateless fuzz tests, Foundry does not know in what order it has to call what. At this point comes the stateful, or invariant testing method.

In order to understand this, we need to understand what do we meen by invariant. Invariant, is the thing that cannot change, a constant. In the case of a DeFi protocol, you know that the protocol always has to be over-collateralized, that is to say, it always needs to have more money than it lends. This is your invariant. We can never be under-collateralized, we always need more money than we gave in our system.

Now, in invariant testing, since we've decided what our constant is (that the protocol always needs to be over-collateralized), we want to make sure that the user cannot withdraw any money before depositing them. We use a handler to define in what order we want to run our fuzz tests. In the example we've given, we want the script to first send money via deposit function and only afterwards call the redeem or withdraw function.

Also we want to keep the state updated right? Because if we didn't update the state of the Dapp updated, i.e. if we didn't save the money deposited by the test user, when our script tries to call the withdraw or redeem function it would fail. So, we're trying to replicate the exact steps we want to test, with many many random values. That's invariant testing for you in simple terms.

Differences in traditional and web3/blockchain front end development

Murat Can Yüksel — Sun, 16 Jun 2024 05:47:24 +0000

Web3/Blockchain front end development differs from traditional/web2 front end development in certain ways. Here we will look at how they differ in interacting with the back end, and how they handle authentication.

In the traditional system, the front end interacts with a server. That server might have been written with NodeJS, Python, Go, PHP or any other suitable language. The back end would give some API endpoints to front end to call. In the front end, the developer could send CRUD requests, that are:

Create: POST requests to send new data to the server.
Read: GET requests to retrieve data from the server.
Update: PUT or PATCH requests to modify existing data on the server.
Delete: DELETE requests to remove data from the server.

In web3/blockchain development, there is no centralized server, there's the blockchain... We can think of blockchain as a huuuuge server plus database. I'm sure there are many people who'd grill me for this oversimplicated definition of what a blockchain is, but whatever. In order to 'serve' your own code, called smart contracts in Ethereum, in the blockchain, you have to deploy it, and deployment costs real money (gas in Ethereum). Once the smart contracts are deployed, in order to interact with it, the front end can make read and write calls. No, no CRUD in here. No API endpoints, no axios. The idea is the same, but the method is just a bit different, that's all.

Read: Calls to the blockchain to retrieve data, typically using "call" methods which do not require a transaction or gas fees (free to call). For example, querying a smart contract to get data without altering the blockchain state.

Write: Transactions that modify the blockchain state, which involve sending data to the blockchain and usually require gas fees (costs real money). This can be adding new data, updating existing data, or executing functions that change the state of a smart contract.

In short, if you just want to peek, it's all okay. But if you want to change something in the blockchain, or send a POST or DELETE request in the traditional sense, you have to pay.

DIFFERENCES IN AUTHENTICATION

We all know how authentication works pretty much everywhere. You either give the system your email address, create a password, or you can create an account using your existing Google, Facebook, GitHub account etc. In any case, you need to create a new account for each and every different app.

In development, authentication for some reason is one of my least favorite things to work on. You can use session tokens, JWT, OAuth, use Firebase, just save the email and password in the database...

Web3 differs heavily in authentication. I personally love it. You have a wallet like Metamask, Coinbase Wallet etc., that is generally a browser extension. When you want to use a dApp (decentralized application), you just sign in with your wallet. No registration, no email, no passwords, nothing. Just your wallet. Say you want to leave the dApp, you didn't like it? You own your data, you can just leave. Imagine owning all of your Facebook photos, comments, posts, everything and when you leave Facebook, you can take all of them into Twitter, or LinkedIn. How convenient is this!

Web3 authentication is super smooth in development too, again in my opinion. There's little to do other then integrating the necessary providers.

###############
If you're looking for full stack blockchain development services, check out my business page => https://www.muratcanyuksel.xyz/

I offer:

Token smart contract creation
Token sale dApp
NFT platforms
DeFi applications
DAO development
Marketing referral system

Smart contracts and Front end development + smart contract integration included.
###############

Looking for Partners to Bring in Web3 Clients and Grow Together!

Murat Can Yüksel — Thu, 13 Jun 2024 08:18:53 +0000

Hello everyone!

I’m on the lookout for some awesome people to help me bring in clients for my blockchain development business. If you’re great at networking and want to earn some serious commission, this is your chance!

I'm a full stack blockchain developer focusing on EVM based chains with a couple of years experience under my belt so engaging with serious clients should be a breeze for great communicators. You can check my business page here => https://www.muratcanyuksel.xyz/

What’s the Deal?

I’m offering a sweet commission on every client you bring in. Here’s what’s in it for you:

• Earn a generous cut of the profits.

• Get involved with cutting-edge blockchain projects.

• Build your reputation in the web3 space.

What I Need from You:

• Find and join groups and forums where potential clients hang out.

• Hunt down businesses and individuals who need blockchain development.

• Network, build relationships, and set up initial meetings.

• Pitch my services and help onboard new clients.

Why This Is a No-Brainer:

You’ll earn more than just commissions. By teaming up with me, you’ll:

• Dive into the booming web3 market.

• Build a killer network in the blockchain community.

• Gain experience and recognition by working on exciting projects.

This isn’t just a gig; it’s a chance to be part of the future and get paid while doing it. If you’re motivated and ready to explore the world of blockchain, let’s chat!

Drop a comment, shoot me a DM or directly visit my business page (https://www.muratcanyuksel.xyz/) to see my offers and all the information you and the clients you'll bring will need if you’re interested. Let’s make some magic happen together!

Cheers! 😅

Checking Whitelisted Addresses on a Solidity Smart Contract Using Merkle Tree Proofs

Murat Can Yüksel — Wed, 12 Jun 2024 13:03:30 +0000

Intro

Hello everyone! In this article, we will first talk about Merkle Trees, and then replicate a whitelisting scenario by encrypting some "whitelisted" addresses, writing a smart contract in Solidity that can decode the encrption and only allow whitelisted addresses to perform some action, and finally testing the contract to see whether our method works or not.

IF you already know about merkle trees and directly start with the hands-on experience, you can skip the Theory part and start reading from the Practice section.

Theory

In the evolving world of blockchain and decentralized applications (dApps), efficient and secure management of user access is paramount. One popular method for controlling access is through whitelisting, where only approved addresses can interact with specific functionalities of a smart contract. However, as the list of approved addresses grows, maintaining and verifying this list in an efficient and scalable manner becomes a challenge.

This is where Merkle trees come into play. Merkle trees provide a cryptographic way to handle large sets of data with minimal storage and computational overhead. By leveraging Merkle trees, we can efficiently verify whether an address is whitelisted without needing to store or process the entire list of addresses within the smart contract.

In this tutorial, we'll dive deep into how to implement a whitelisting mechanism using Merkle trees in Solidity. We'll cover the following key aspects:

Understanding Merkle Trees: A brief overview of what Merkle trees are and why they are useful in blockchain applications.
Setting Up the Development Environment: Tools and libraries you need to start coding.
Creating the Merkle Tree: How to generate a Merkle tree from a list of whitelisted addresses.
Solidity Implementation: Writing the smart contract to verify Merkle proofs.
Verifying Addresses: Demonstrating how to use Merkle proofs to check if an address is whitelisted.
Testing the Contract: Ensuring our contract works correctly with various test cases.

By the end of this tutorial, you'll have a robust understanding of how to leverage Merkle trees for efficient and secure whitelisting in Solidity smart contracts, providing you with a powerful tool for your future dApp development endeavors.

Understanding Merkle Trees

Merkle trees, named after computer scientist Ralph Merkle, are a type of data structure used in computer science and cryptography to efficiently and securely verify the integrity of large sets of data. In the context of blockchain and decentralized applications, Merkle trees offer significant advantages for managing and verifying data with minimal overhead.
What is a Merkle Tree?

A Merkle tree is a binary tree in which each leaf node represents a hash of a block of data, and each non-leaf node is a hash of its two child nodes. This hierarchical structure ensures that any change in the input data results in a change in the root hash, also known as the Merkle root.

Here’s a simple breakdown of how a Merkle tree is constructed:

Leaf Nodes: Start with hashing each piece of data (e.g., a list of whitelisted addresses).
Intermediate Nodes: Pair the hashes and hash them together to form the next level of nodes.
Root Node: Repeat the process until a single hash remains, known as the Merkle root.

This structure allows for efficient and secure verification of data.
Why Merkle Trees are Useful in Blockchain Applications

Merkle trees are particularly useful in blockchain applications for several reasons:

Efficient Verification: Merkle trees enable the verification of a data element's inclusion in a set without needing to download the entire dataset. This is achieved through a Merkle proof, which is a small subset of hashes from the tree that can be used to verify a particular element against the Merkle root.

Data Integrity: Any alteration in the underlying data will change the hash of the leaf node and, consequently, all the way up to the Merkle root. This makes it easy to detect and prevent tampering with the data.

Scalability: As the size of the dataset grows, Merkle trees allow for efficient handling and verification. This is particularly important in blockchain networks where nodes need to validate transactions and states without extensive computational or storage requirements.

Security: Merkle trees provide cryptographic security by using hash functions that are computationally infeasible to reverse, ensuring that the data structure is tamper-proof and reliable.

Practical Use Cases in Blockchain

Bitcoin and Ethereum: Both Bitcoin and Ethereum use Merkle trees to organize and verify transactions within blocks. In Bitcoin, the Merkle root of all transactions in a block is stored in the block header, enabling efficient transaction verification.

Whitelisting: In smart contracts, Merkle trees can be used to manage whitelisted addresses efficiently. Instead of storing a large list of addresses directly on-chain, a Merkle root can be stored, and users can prove their inclusion in the whitelist with a Merkle proof.

Practice

Enough theory, now it is time to get our hands dirty. We are going to create an empty folder, and run the following command on the terminal to install Hardhat => npm install --save-dev hardhat

Then, with npx hardhat init command, we will start a Hardhat project. For this project, we will use Javascript.

After the project has ben initiated, we will install these following packages also => npm install @openzeppelin/contracts keccak256 merkletreejs fs

Constructing the Merkle Root

In this step, we have a bunch of whitelisted addresses, we will write the script that will construct the merkle tree using those addresses. We will get a JSON file, and a single Merkle Root. We will use that merkle root later on to identify who's whitelisted and who's not.

In the main directory of the project, create utils/merkleTree.js

const keccak256 = require("keccak256");
const { default: MerkleTree } = require("merkletreejs");
const fs = require("fs");

//hardhat local node addresses from 0 to 3
const address = [
  "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266",
  "0x70997970C51812dc3A010C7d01b50e0d17dc79C8",
  //"0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC",
  "0x90F79bf6EB2c4f870365E785982E1f101E93b906",
];

Note that we commented the address number 2.

You see we do not need to manually write the logic for the merkle tree, we're using a library for ease of development. The addresses are the first 4 addresses in Hardhat node. Do not send any money to them, their private keys are publicly known and anything sent to them will be lost.

Now, we will do the following:

Hash all individual items in the address array (creating leaves)
construct a new merkle tree

//  Hashing All Leaf Individual
//leaves is an array of hashed addresses (leaves of the Merkle Tree).
const leaves = address.map((leaf) => keccak256(leaf));

// Constructing Merkle Tree
const tree = new MerkleTree(leaves, keccak256, {
  sortPairs: true,
});

//  Utility Function to Convert From Buffer to Hex
const bufferToHex = (x) => "0x" + x.toString("hex");

// Get Root of Merkle Tree
console.log(`Here is Root Hash: ${bufferToHex(tree.getRoot())}`);

let data = [];

You see that we're logging the root hash. We will copy it when we run the script.

And now we'll do the following:

Push all the proofs and leaves in the data array we've just created
Create a whitelist object so that we can write into a JSON file
Finally write the JSON file

// Pushing all the proof and leaf in data array
address.forEach((address) => {
  const leaf = keccak256(address);

  const proof = tree.getProof(leaf);

  let tempData = [];

  proof.map((x) => tempData.push(bufferToHex(x.data)));

  data.push({
    address: address,
    leaf: bufferToHex(leaf),
    proof: tempData,
  });
});

// Create WhiteList Object to write JSON file

let whiteList = {
  whiteList: data,
};

//  Stringify whiteList object and formating
const metadata = JSON.stringify(whiteList, null, 2);

// Write whiteList.json file in root dir
fs.writeFile(`whiteList.json`, metadata, (err) => {
  if (err) {
    throw err;
  }
});

Now, if we run node utils/merkleTree.js in the terminal, we will get something like this: Here is Root Hash: 0x12014c768bd10562acd224ac6fb749402c37722fab384a6aecc8f91aa7dc51cf

We'll need this hash later.

We also have a whiteList.json file that should have the following contents:

{
  "whiteList": [
    {
      "address": "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266",
      "leaf": "0xe9707d0e6171f728f7473c24cc0432a9b07eaaf1efed6a137a4a8c12c79552d9",
      "proof": [
        "0x00314e565e0574cb412563df634608d76f5c59d9f817e85966100ec1d48005c0",
        "0x1ebaa930b8e9130423c183bf38b0564b0103180b7dad301013b18e59880541ae"
      ]
    },
    {
      "address": "0x70997970C51812dc3A010C7d01b50e0d17dc79C8",
      "leaf": "0x00314e565e0574cb412563df634608d76f5c59d9f817e85966100ec1d48005c0",
      "proof": [
        "0xe9707d0e6171f728f7473c24cc0432a9b07eaaf1efed6a137a4a8c12c79552d9",
        "0x1ebaa930b8e9130423c183bf38b0564b0103180b7dad301013b18e59880541ae"
      ]
    },
    {
      "address": "0x90F79bf6EB2c4f870365E785982E1f101E93b906",
      "leaf": "0x1ebaa930b8e9130423c183bf38b0564b0103180b7dad301013b18e59880541ae",
      "proof": [
        "0x070e8db97b197cc0e4a1790c5e6c3667bab32d733db7f815fbe84f5824c7168d"
      ]
    }
  ]
}

Verifying the proof in the smart contract

Now, check this Solidity contract out:

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.24;
import "@openzeppelin/contracts/utils/cryptography/MerkleProof.sol";

// Uncomment this line to use console.log
// import "hardhat/console.sol";

contract MerkleProofContract {
    bytes32 public rootHash;

    constructor(bytes32 _rootHash) {
        rootHash = _rootHash;
    }

    function verifyProof(
        bytes32[] calldata proof,
        bytes32 leaf
    ) private view returns (bool) {
        return MerkleProof.verify(proof, rootHash, leaf);
    }

    modifier isWhitelistedAddress(bytes32[] calldata proof) {
        require(
            verifyProof(proof, keccak256(abi.encodePacked(msg.sender))),
            "Not WhiteListed Address"
        );
        _;
    }

    function onlyWhitelisted(
        bytes32[] calldata proof
    ) public view isWhitelistedAddress(proof) returns (uint8) {
        return 5;
    }
}

What it does is the following:

Imports Openzeppelin's merkle proof contract
Enters the root hash we've just saved in the constructor. This means that there will be no more whitelisted accounts added, and it is final
a private verifyProof function invokes Openzeppelin and requires the proof from the user
a isWhitelistedAddress modifier makes sure that msg.sender is the whitelisted address. Without this modifier, anyone with the public whitelisted address could call the contract, now, only the owner of the whitelisted address can call
a basic onlyWhitelisted function requires the user proof and returns 5. That's is, we just want to see if we can call this function as a non-whitelisted user or not

Testing the contract

Now in the test folder create a MerkleProof.js file and add the following there:

const { expect } = require("chai");
const { formatEther } = require("ethers");
const { ethers } = require("hardhat");

describe("MerkleProof", function () {
  it("only whitelisted address can call function", async function () {
    let owner, addr1, addr2;
    let merkleTreeContract;
    let rootHash =
      "0x12014c768bd10562acd224ac6fb749402c37722fab384a6aecc8f91aa7dc51cf";

    // async function setup() {
    [owner, addr1, addr2] = await ethers.getSigners();

    const MerkleTree = await ethers.getContractFactory("MerkleProofContract");
    merkleTreeContract = await MerkleTree.deploy(rootHash);
    console.log(merkleTreeContract.address);
    // }

    // beforeEach(async function () {
    //   await setup();
    // });

    const user = addr1;

    const proof = [
      "0xe9707d0e6171f728f7473c24cc0432a9b07eaaf1efed6a137a4a8c12c79552d9",
      "0x1ebaa930b8e9130423c183bf38b0564b0103180b7dad301013b18e59880541ae",
    ];

    console.log(
      `user address: ${user.address} and proof: ${proof} and rootHash: ${rootHash}`
    );

    expect(
      await merkleTreeContract.connect(user).onlyWhitelisted(proof)
    ).to.equal(5);

    await expect(
      merkleTreeContract.connect(addr2).onlyWhitelisted(proof)
    ).to.be.revertedWith("Not WhiteListed Address");
  });
});

This test file works as such:

owner, addre1 and addr2 are the first 3 addresses in Hardhat node
deploys the merkle tree contract with the saved root hash
user is addr1, that is the 2nd addess in whiteList.json file. We get the proof from there -connects to a whitelisted user and calls the function, gets the correct value of 5 -connects with a non-whitelisted user (we did comment out the address number 2 at the very beginning ) and calls the function, is reverted.

Hope you enjoyed it! If you have any corrections or suggestions, please let me know in the comments.

Cheers!

Basic explanation of how whitelisting works in Solidity

Murat Can Yüksel — Tue, 28 May 2024 08:52:14 +0000

You know what whitelisting is, but you also want to understand how it works under the hood. Now imagine you have an NFT collection, and you tell the community that people who buy your NFTs right now will have priority access to the upcoming online game you and your team have been developing.

How does that whitelisting actually occurs? How is it structured in solidity?

Almost always, the addressess that purchase the NFT will be added into a mapping. According to alchemy a mapping is a hash table in Solidity that stores data as key-value pairs. They are defined like:

mapping(address => bool) public whitelistedAddresses;

You see, the idea here is simple: When someone purchases one of your NFTs, you take their address, and put a truthy statement to it. That's what a bool is, it's a boolean. True, or false. If they have not purchased your NFT, their addresses will not be in the mapping anyway, so it will not be a truthy statement. When they do purchase, on inquiry their addresses will return a truthy statement and you'll know that they are whitelisted.

Then, you can basically do whatever you want with this whitelistedAddresses mapping. You can use it as a guard to certain functions and only whitelisted people can do such and such.

Finding the right blockchain developer for non technical entrepreneurs

Murat Can Yüksel — Thu, 02 May 2024 08:20:51 +0000

Blockchain entrepreneurs with limited or no technical knowledge, are you struggling to find the right frontend developer for your project?

As a blockchain entrepreneur, you have your idea and your smart contracts ready, but now you need to hire a frontend developer to create your UI. The challenge is, you're unsure what qualities to look for in a developer. Fortunately, I've personally developed several successful frontend dApps, resulting in satisfied clients, and I can share my insights to help you identify the ideal candidate.

To find the right developer, you must first ensure they possess the necessary technical skills. But what exactly should you be looking for?

First and foremost, you need a frontend developer who is proficient in the HTML/CSS/JavaScript trio. Within the blockchain space, ReactJS is a commonly used JavaScript library, so it's advantageous to find someone experienced with ReactJS.

The specific CSS library they prefer is less important. They may mention Tailwind CSS, MUI, Bootstrap, and others, but you don't need to understand the intricacies of these design libraries. As long as their previous work looks professional, they likely know what they're doing.

Now, onto a critical aspect: the developer's understanding of interacting with smart contracts. Unlike traditional web development, where logic interacts with a server, web3/blockchain development involves interaction with a blockchain. Developers use different techniques, tools, and libraries for this purpose. During the interview process, inquire about their preferred library — Web3.js, Ethers.js, wagmi.sh,Thirdweb etc. Ideally, the developer should have expertise in at least one library and knowledge of others.

Beyond technical skills, hiring a frontend developer is similar to hiring any other developer. Trust your instincts, evaluate their previous work, and consider feedback from others to ensure you're hiring a professional developer.

If you have any questions, feel free to ask in the comments. Cheers!

Write and view functions in Solidity

Murat Can Yüksel — Tue, 30 Apr 2024 15:23:14 +0000

As a frontend developer building dApps on Ethereum, you need to know the difference between "view" and "write" functions.

When you write a function in Solidity to do something, to change something in the state of the blockchain, that function will cost gas. It will require a fee, real money to be executed.

View functions are the opposite. When a Solidity function has the "view" keyword on it, and does not do any operation that changes the state of the blockchain, it will not cost gas.

Say that you just want to see how much of some token an account has, since that knowledge is public, and you accessing it does not change the state of the blockchain, the function in Solidity would be a view function.

When interacting with Solidity functions using wagmi React hooks, you use "useWriteContract" hook to interact with functions that change the state, like sending a token from one contract to another.

While interacting with view functions, you'd use the "useReadContract" hook. When you compare the two hooks, you'll see that the useWriteContract takes arguments while the useReadContract does not.

How to handle Solidity errors with React and Wagmi hooks

Murat Can Yüksel — Fri, 26 Apr 2024 08:33:18 +0000

If you're building a frontend for a blockchain protocol, you'll need to handle errors coming from the smart contracts. In Solidity, we will now learn about require statements.

Solidity require are statements that are added in the functions to stop them if a certain condition is not met. Think of the following scenario: Users can only call a function if a certain statement is true. In this case, the _amount must be higher than zero.

function myFunc(uint256 _amount){

require(\_amount > 0, "Amount must be greater than 0");

}

Now, in the frontend, let's write the corresponding function using wagmi hooks with react

First we need to import the useWriteContract hook from wagmi like so :

import { useWriteContract } from "wagmi";

Then, initiate it in our component as follows:

const { writeContract, failureReason} = useWriteContract();

You see we also destructure failureReason from useWriteContract hook. We will use this failureReason to see why the function reverted.

Now let's call the Solidity function


const callMyFunc = async () => {

    try {

      writeContract({

        abi,

        address,

        functionName: "myFunc",

        args: [0],

      });

    } catch (error) {

      console.log(error);

    }

  };

This is just basic function call. The thing is, since we're passing zero as an argument, the function call will fail/revert. If we logged the failureReason, we'd get something like this:

"ContractFunctionExecutionError: The contract function "myFunc" reverted with the following reason:
Amount must be greater than 0.
Contract Call:
address: 0xD...dc5b6
function: myFunc()
sender: 0x1A...667D"

Of course, in a real world scenario, we'd not just log the error message but maybe display it with a pop-up. Totally up to you.

Deploying smart contracts with the new Hardhat update

Murat Can Yüksel — Fri, 30 Jun 2023 11:35:06 +0000

To all #blockchain #web3 #devs out there who are trying to deploy via #hardhat and encountering errors: With the recent update, the deployment script changed slightly. Now, I will show you how we used to write our scripts/deploy.js file and then I will show the updated version. The first one will be for a referral contract (old) and the new, updated one will be for an NFT contract:

Old version =>

const { ethers } = require("hardhat");

async function main() {
const referralContract = await ethers.getContractFactory("Referral");
const referral = await referralContract.deploy();
await referral.deployed();

console.log("referral deployed to:", referral.address);
}

main()
.then(() => process.exit(0))
.catch((error) => {
console.error(error);
process.exit(1);
});

With the update, instead of importing ethers, we're importing hre. Instead of getContractFactory, we have deployContract, and if we want to see the deployment address, instead of looking for the address keyword, we need to check the target keyword.

Now the new version =>

const hre = require("hardhat");

async function main() {
const nftContract = await hre.ethers.deployContract("NFT", [], {});

await nftContract.waitForDeployment();

console.log("NFT contract deployed to:", nftContract.target);
}

// We recommend this pattern to be able to use async/await everywhere
// and properly handle errors.
main().catch((error) => {
console.error(error);
process.exitCode = 1;
});

Do not get frustrated, stay safe and read the official docs.

Beware of scammers/hackers targeting blockchain developers

Murat Can Yüksel — Mon, 26 Jun 2023 17:33:11 +0000

Hello everyone, recently they tried to hack me, and I hope they were unsuccessful at doing so, but I'd like to share the scheme so that if you encounter a similar thing, you'll know what's going on. Follow me step by step and you'll see how some bad actors on a famous freelancing platform are trying to #hack #web3 #blockchain developers.

First things, they'll send an invite, looking for a blockchain developer. Everything seems quite normal and professional.

Then they'll send a github repo, or a project via google drive or whatsoever. The project seems legit at first glance.

They then ask you to open the project via npm start. But in order to do so, you'll have to solve a bug. One time it was a collision between package-lock.json and yarn.lock files and I was able to open the app by deleting the yarn.lock file. Still, do this point, I think everything seems to be kinda okay.

Then, they want you to send them a screenshot showing that you've opened the app. Now this is fishy, but still, I have to admit that I've done this 3 times lol.

Then they stop responding.

At the first 2 times, I just moved on thinking they've found another developer. But then, the 3rd one made a weird comment. They said, "just keep the app open and we'll discuss". Now, it was already the third time I was seeing a similar behavior so I thought okay this is weird, closed the app, and started doing the thing I should've done in the first place: Checking every single file in the project's repository.

After a brief investigation, I've found a weirdly looking file. That had a harmless name like utils.js or error.js or setup.js that had a quite unreadable code in it.

I will even go ahead and share the latest one I've been sent, just to name and shame, ATTENTION, DO NOT CLONE OR RUN THIS REPOSITORY, this is the malicious code => https://github.com/liamprodev/Hiring-Assessment/blob/main/helpers/error.js

As you can see, it is in helpers directory and is named error.js, but has nothing to do with error handling. It's quite difficult to read too. If you use https://beautifier.io/ or some other code formatter, you'll see something like this

It is ugly isn't it? Do you see how they even use base64 decoding to obfuscate the code. so instead of writing r=c(child_processes) they encode it and write r = c("Y2hpbGRfcHJvY2Vzcw"), making it harder to read. I've analyzed some other parts of it too, it's like, instead of returning x, they turn x into y+z*uu-15t or some other weird equation like that. It's quite difficult to follow what's going on there, but with the help of gpt4, I've managed to understand that it's an #expressjs #server that runs through file directory, creates files, and somehow looks for chrome wallet extensions. One of them was trying to get solana wallet, others, I'm still not sure. I think they're trying to drain the funds in the wallet.

Well, jokes on them because I only keep test coin in my #metamask wallet lol.

Now, when you read this article, maybe the github repo will be already deleted, because they do so. Even this one I've shared was in a different repo from the same account.

Now, what I think now, is that these are sold somewhere, possibly on the deep web (because why not?), and many scammers are trying to use the almost-alike hacking scripts to drain funds.

I was not careful, but lucky I guess. So, please be careful and do not trust anyone, gosh, #web3 is wilder than the old west.

Something to consider when sharing state with Zustand

Murat Can Yüksel — Thu, 15 Jun 2023 12:09:31 +0000

I've been using #zustand as store for my latest #react #typescript project and I want to share with you something that cost me some serious time and headache so that you won't fall into the same pith.

Say that you have the following store saved in zustand:



interface TransactionHashState {

  transactionHash: string;

  getTransactionHash: (transactionHash: string) => void;

}


export const useTransactionHashStore = create<TransactionHashState>()(

  (set) => ({

    transactionHash: "",

    getTransactionHash: (transactionHash) =>

      set(() => ({ transactionHash: transactionHash })),

  })

);

In your components, there are two ways of calling its value:

The first way, that is const { getTransactionHash } = useTransactionHashStore.getState(); will work fine in most cases, but it will only take a snapshot of the state so when you make a change, it won't update in real time. I repeat, it won't update in real time.

If you want it to update immediately, you should call it like const { getTransactionHash } = useTransactionHashStore() (without the getState method), and all will be fine.

reactdeveloper #reactdevelopment #webdeveloper #webdevelopers #webdevelopment