DEV Community: yo yo ben zhou

Optimizing Solidity Smart Contracts & Hardhat Testing – MultiUserBank Edition

yo yo ben zhou — Wed, 19 Feb 2025 06:10:13 +0000

🚀 Introduction

For today, I transformed my smart contract from a single-user bank to a multi-user bank, optimized gas costs, secured ETH transfers, and gained a deep understanding of reentrancy protection.

Today's Highlights

✅ Implemented user-specific balances with mapping(address => uint)

✅ Optimized storage access to reduce SLOAD gas costs

✅ Replaced .transfer() with .call{value: amount}("") for secure ETH transfers

✅ Enhanced Hardhat test coverage with balance tracking

✅ Deployed contracts dynamically with deploy.js

✅ Understood and mitigated Reentrancy Attacks!

1️⃣ Upgrading to Multi-User Bank

🔴 Problem: Single-User Balance Tracking

Initially, my contract tracked one balance for the entire contract, meaning all users shared the same balance.

uint public balance; // Tracks one balance for all users

🔴 Issue: All users shared a single balance, making it unrealistic for a real banking system.

💡 Solution: Use a `mapping` to Track Balances Per User

mapping(address => uint) balance;

✅ Each user now has their own balance

✅ Deposits and withdrawals are specific to each address

Updated deposit function:

function deposit() public payable {
    require(msg.value > 0, "Deposit money must be higher than zero");
    balance[msg.sender] += msg.value;
    emit Deposit(msg.sender, msg.value, balance[msg.sender]);
}

✅ Each user’s balance is updated independently!

2️⃣ Gas Optimization: Reduce Storage Reads (`SLOAD`)

Storage reads (SLOAD) in Solidity are expensive, so minimizing them reduces gas costs.

🔴 Original code with redundant SLOAD:

uint current_balance = balance[msg.sender];  
require(amount <= current_balance, "Insufficient balance");  
balance[msg.sender] = current_balance - amount;

🔴 Problem:** Reads storage twice (extra gas usage).

💡 Solution: Read from storage once, then modify in memory**

uint userBalance = balance[msg.sender];  
require(amount <= userBalance, "Insufficient balance");  
balance[msg.sender] = userBalance - amount;

✅ Storage access reduced from two to one (saving gas)!

3️⃣ Safer ETH Transfers: Using `.call{value: amount}("")` Instead of `.transfer()`

Initially, I used:

payable(msg.sender).transfer(amount);

🔴 Problem:

.transfer() has a gas limit of 2300, which **may fail if the receiving address is a contract.
It does not return a success/failure flag, making debugging harder.

💡 Solution: Use .call{value: amount}("")

(bool sent, ) = payable(msg.sender).call{value: amount}("");
require(sent, "Transfer failed");

✅ Handles ETH transfers more safely!
✅ Prevents unexpected failures due to gas limits!

4️⃣ Reentrancy Protection: Why This Version is Safe

I deepened my understanding of reentrancy vulnerabilities today!

🔴 What is a Reentrancy Attack?

A malicious contract can repeatedly call the withdrawal function before the balance updates, draining the contract’s funds, we may extend this topic in the future posts with more detailed examples.

🚨 Vulnerable Code Pattern:

(bool sent, ) = msg.sender.call{value: amount}("");
require(sent, "Transfer failed");
balance[msg.sender] -= amount;

🔴 Problem: The contract sends ETH before updating the balance, allowing reentrancy!

💡 Solution: Update the Balance Before Sending ETH

uint userBalance = balance[msg.sender];
require(amount <= userBalance, "Insufficient balance");

// ✅ Update balance FIRST before sending ETH
balance[msg.sender] = userBalance - amount;

(bool sent, ) = payable(msg.sender).call{value: amount}("");
require(sent, "Transfer failed");

emit Withdrawal(msg.sender, amount, balance[msg.sender]);

✅ Reentrancy attack is impossible because the balance updates before ETH is sent!

5️⃣ Writing and Running Hardhat Tests

After improving the contract, I wrote comprehensive Hardhat tests.

Key Test Cases:

✅ Deposits update the correct user’s balance

✅ Withdrawals succeed and update the user’s balance correctly

✅ Withdrawals fail when balance is insufficient
✅ Gas fees are deducted correctly

Hardhat Test File (multiUserBank.test.js):

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

describe("MultiUserBank", function () {
  let bank, owner, addr1, addr2;

  beforeEach(async function () {
    [owner, addr1, addr2] = await ethers.getSigners();
    const Bank = await ethers.getContractFactory("MultiUserBank");
    bank = await Bank.deploy();
    await bank.waitForDeployment();
  });

  it("should allow user-specific deposits", async function () {
    await bank.connect(addr1).deposit({ value: ethers.parseEther("1") });
    expect(await bank.getUserBankBalance(addr1.address)).to.equal(ethers.parseEther("1"));
  });

  it("should allow withdrawals and update balances correctly", async function () {
    await bank.connect(addr1).deposit({ value: ethers.parseEther("1") });

    const beforeBankBalance = await bank.getUserBankBalance(addr1.address);
    const beforeEthBalance = await ethers.provider.getBalance(addr1.address);

    const tx = await bank.connect(addr1).withdrawal(ethers.parseEther("0.5"));
    const receipt = await tx.wait();
    const gasUsed = BigInt(receipt.gasUsed) * BigInt(receipt.gasPrice);

    const afterBankBalance = await bank.getUserBankBalance(addr1.address);
    expect(afterBankBalance).to.equal(beforeBankBalance - ethers.parseEther("0.5"));

    const afterEthBalance = await ethers.provider.getBalance(addr1.address);
    expect(afterEthBalance).to.equal(beforeEthBalance + ethers.parseEther("0.5") - gasUsed);
  });

  it("should prevent overdrafts", async function () {
    await expect(bank.connect(addr1).withdrawal(ethers.parseEther("2"))).to.be.revertedWith(
      "Insufficient balance"
    );
  });
});

✅ Thorough tests ensure contract safety!
✅ Validates ETH balance changes post-withdrawal!

📌 Final Thoughts:

Today’s Solidity deep dive helped me:

✅ Upgrade to a Multi-User Banking System using mapping
✅ Prevent Reentrancy Attacks by updating balances before sending ETH

✅ Reduce gas costs by optimizing storage access

✅ Deploy contracts dynamically instead of hardcoding deployments

Follow my Solidity progress on GitHub, Dev.to, and Medium! 🚀

🌍 Join Me on This Journey!
If you're also learning Solidity, Smart Contracts, or blockchain development, let's connect!
📌GitHub: https://github.com/benzdriver
📌LinkedIn: https://www.linkedin.com/in/ziyan-zhou/
💡 Let’s build the future of blockchain together! 🚀

Solidity Learning Journey: Deploying and Testing a Smart Contract

yo yo ben zhou — Wed, 12 Feb 2025 19:36:59 +0000

🚀Previously in My Journey…

In my previous post, I shared why I'm transitioning from SDET to Smart Contract Engineer. I talked about my fascination with Bitcoin's whitepaper, Ethereum's smart contracts, and the revolutionary potential of Web3.
But motivation alone isn't enough - you have to put in the work.
Today, I'm diving into Solidity for the first time, writing, deploying, and testing my first smart contract.

🎯The Plan: A Simple Ethereum Bank

For my first Solidity project, I decided to build a basic Ethereum bank - a contract where users can:

🏦 Deposit ETH into the contract.
💸 Withdraw ETH from the contract.
📊 Keep track of balances (but let Solidity handle the math). Sounds simple, right? Well, things got complicated fast.

🛑 Solidity's First Surprise: Depositing ETH Works Differently Than I Thought

Coming from traditional programming, I assumed I needed a function like this:

function deposit(uint amount) public payable {
    require(amount > 0, "Deposit must be greater than zero");
}

❌ WRONG Solidity doesn't work like that.The ETH amount is automatically included in msg.value, so no need to pass amount explicitly. A function just needs the payable modifier to receive ETH.

💡 LESSON:Solidity handles ETH transfers at the transaction level, not as function parameters.

💰 Withdrawals and Solidity's Automatic Balance Tracking

Next, I worked on withdrawals, assuming I needed a balance variable. But Solidity already tracks contract balances internally using address(this).balance.
So, instead of:

uint public balance;
balance -= amount;

I could just let Solidity handle the math and use

payable(msg.sender).transfer(amount);

💡 LESSON: Solidity is smarter than I thought. You don't need to track balances manually - the blockchain does it for you.

🛠️ Deploying and Testing in Hardhat: "Why Isn't My Contract Deploying?"

I decided to deploy my contract using Hardhat. I wrote a deploy.js script, but then realized:
❌ WRONG. Hardhat tests don't actually use deploy.js.
✅ RIGHT Each test runs on a fresh blockchain state, deploying dynamically.
Still, I ran into errors like:
❌ HH606: Solidity version mismatch → Fixed by updating hardhat.config.js to include solidity version inside.
❌ "Cannot find module 'dotenv'" → Installed missing package (dotenv).
❌ Hardhat compilation issues → Fixed by running:

npx hardhat clean npx hardhat compile

💡 LESSON: Hardhat automates a lot, but you have to configure Solidity versions correctly to avoid mismatches.

🔥 The Magic of Indexed Events in Solidity

Solidity lets you log transactions with events, which I thought were just for debugging. ❌ WRONG.
✅ Events actually live on the blockchain and make transaction searches super efficient.
For example:
event Deposit(address indexed sender, uint amount);
Indexed parameters make searching logs faster.
Why not use msg.sender directly? Solidity doesn't allow direct global variables in event definitions.

So instead of:

event Deposit(msg.sender, msg.value);

You write:

event Deposit(address indexed sender, uint amount);
emit Deposit(msg.sender, msg.value);

💡 LESSON: Events aren't just console logs - they are part of the Ethereum blockchain history.

🔑 Key Takeaways from Day 1

✅ Solidity has built-in ETH balance tracking - no need for manual balance variables.
✅ payable functions automatically receive ETH without an explicit amount parameter.
✅ Hardhat automates testing but requires careful Solidity version configuration.
✅ Events are stored on-chain and indexed makes them searchable.

** 🚀 Next Steps & Future Improvements**

🔹 Add multi-user banking using mapping(address => uint) balances.
🔹 Implement admin-only withdrawals for full contract balance management.
🔹 Deploy SingleUserBank on a public Ethereum testnet.
🔹 Explore gas optimizations and smart contract security best practices.

Solidity, Smart Contracts, and My Leap from SDET to Web3 Developer

yo yo ben zhou — Tue, 11 Feb 2025 08:05:48 +0000

Why Am I Making the Switch?

For years, I worked as a Software Development Engineer in Test (SDET)—a field deeply rooted in traditional software development. It was a stable career, but something was missing. That missing piece? A sense of true innovation and revolution.

Looking back, I think my journey toward becoming a Smart Contract Engineer can be traced to one of my biggest passions: investing in cryptocurrency.

The Moment That Changed Everything

Like many others, my crypto journey started with Bitcoin, the first truly decentralized digital currency. At its core, Bitcoin wasn’t just another asset—it was a fundamental shift in the way we think about money, trust, and decentralization.

The Bitcoin whitepaper, written by Satoshi Nakamoto, is often referred to as the Bible of Cryptocurrency. Despite being only a few pages long, it proposed a groundbreaking solution to a centuries-old problem: how to create a trustless, decentralized system of value exchange.

"The root problem with conventional currency is all the trust that’s required to make it work. The central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust. Banks must be trusted to hold our money and transfer it electronically, but they lend it out in waves of credit bubbles with barely a fraction in reserve."

— Satoshi Nakamoto, Bitcoin Whitepaper (2008)

This completely changed my perspective. Bitcoin wasn’t just a digital coin—it was a revolution against traditional financial systems.

Ethereum & The Rise of Smart Contracts

Then came Ethereum. While Bitcoin solved the problem of decentralized money, Ethereum took it a step further: it created a programmable blockchain, enabling Smart Contracts that could automate trust and transactions.

At first, I didn’t grasp the full implications. But when I encountered NFTs (Non-Fungible Tokens), everything clicked.

NFTs weren’t just about digital art. They represented ownership, proof of authenticity, and verifiable scarcity on the blockchain. I realized that anything that required proof—certificates, real estate, supply chain tracking—could one day exist as an NFT, secured by Smart Contracts.

"Code is Law"—and for the first time, I saw a world where contracts, agreements, and transactions could be trustless, transparent, and immutable.

That’s when I knew:

This was more than just an investment opportunity—it was a technological revolution.

The world was moving fast, and if I didn’t jump in now, I’d be left behind.

I didn’t just want to be a passive observer—I wanted to be a builder.

Why This Matters to Me

Technology is most powerful when it empowers people. With Smart Contracts, I see a future where:

Artists no longer need intermediaries to sell their work.
Supply chains are transparent, ensuring ethical sourcing.
Real estate transactions happen without unnecessary bureaucracy.
Financial systems are truly accessible to everyone—not just the privileged few.

I asked myself:

"If I could contribute to making this future a reality—even in the smallest way—wouldn’t that be worth the switch?"

The answer was obvious.

Join Me on This Journey

This is just the beginning of my Web3 developer journey. If you’re also learning Solidity, Smart Contracts, or blockchain development, let’s connect!

GitHub: https://github.com/benzdriver

LinkedIn: https://www.linkedin.com/in/ziyan-zhou/

Let’s build the future of blockchain together.