Forem: Loading Blocks

Build Own Blockchain - 2 episode

Loading Blocks — Mon, 03 Nov 2025 14:23:42 +0000

We usually think of a crypto wallet as just a digital account, like a fancy version of online banking. But when you actually build one from scratch, you discover that the system under the hood is way more elegant — and way more mathematical — than it looks on the surface. The process really opened my eyes to how cryptography, math, and trust all fit together in the blockchain world.

Here are five things that really surprised me when I was developing my own wallet.

1. Your Public “Key” Isn’t Really a Key — It’s a Point on a Curve

When you first see a public key, it looks like a random string of text. But that string actually represents a point on something called an elliptic curve. In most cases, that’s the P-256 curve (some blockchains use slightly different ones).

The public key has two parts — X and Y coordinates — and the long hex string we see is basically just those two numbers stuck together. I remember seeing in the code something like:

“take hex of x, hex of y, and concatenate the two strings.”

It blew my mind that a crypto “key” isn’t just a password—it’s geometry! It’s a literal point on a mathematical curve that can be verified with pure math. That’s the backbone of ownership and verification in blockchain.

2. Your Wallet Address Is Just a Fingerprint of Your Public Key

People often mix up wallet addresses and public keys, but they’re not the same. The wallet address is actually a hash of your public key — basically a short, one-way fingerprint. In my project, we used SHA-256 to do this.

Hashing is a one-way process. You can get from a public key to an address easily, but you can’t go backward. That adds a nice privacy layer — your public key isn’t exposed until you spend funds.

And every blockchain has its own little twist. As one dev in the project said:

“address is just some hash of public key... different blockchain has different way of creating the address.”

Some chains even add custom prefixes (like “evo” for Evo chain). But in the end, the address is just a friendly alias. The real secret sauce lives one step before that…

3. The Private Key Is the Only Thing That Really Matters

If you remember one thing from this article, make it this:
The private key is everything.

Your public key and address can both be regenerated from it. But not the other way around. We built a feature in the wallet that could take a single hex string — the private key — and rebuild the entire wallet:

the D value (the integer form of the private key)
the X/Y coordinates of the public key
the wallet address

All perfectly derived from one piece of data. That’s why security warnings are so strict:

“Do not share your private key or recovery phrase with anyone.”

If someone gets your private key, it’s game over. They basically are you, financially speaking.

4. You Don’t Sign a Transaction — You Sign Its Hash

This part really surprised me. When you “sign” a transaction, you’re not encrypting all the transaction data. You’re just signing its hash.

Here’s roughly how it works:

Bundle the transaction data (sender, receiver, amount, etc.)
Hash that data with SHA-256
Use your private key to sign the hash, not the data itself

This is brilliant for two reasons: it’s super fast, and it’s tamper-proof. If even one comma changes in the transaction, the hash will be totally different — and the signature won’t verify anymore. It’s like a cryptographic checksum that can’t be faked.

5. Verifying a Signature Means Pretending It Isn’t There

This part feels like a magic trick. To verify a transaction, a blockchain node doesn’t just check the signature directly. It recreates the signing process — but without the signature itself.

Here’s the simplified logic:

The node receives the transaction (with signature + public key).
It sets those two fields aside.
It re-hashes the transaction from scratch (without the signature).
Then it uses the public key to check if the signature matches that freshly computed hash.

I saw this in the source:

“we are first storing the signature and public key... then we make them empty, marshal the transaction, hash it again, and finally verify the signature.”

That means every node independently proves — mathematically — that the sender had the private key and didn’t tamper with the data. No trust, no middleman, just math.

code：

package main

import (
    "crypto/ecdsa"
    "crypto/elliptic"
    "crypto/rand"
    "crypto/sha256"
    "encoding/hex"
    "fmt"
    "math/big"
)

// Transaction structure / 交易结构体（核心字段）
type Transaction struct {
    From      string // sender address / 发送方地址
    To        string // receiver address / 接收方地址
    Amount    int    // transfer amount / 转账金额
    Signature []byte // signature (r|s) / 签名
}

// Hash the transaction data to get a unique fingerprint
// 对交易数据进行哈希，得到唯一指纹
func hashTransaction(tx *Transaction) []byte {
    data := fmt.Sprintf("%s:%s:%d", tx.From, tx.To, tx.Amount)
    hash := sha256.Sum256([]byte(data))
    return hash[:]
}

func main() {
    // 1️⃣ Generate elliptic curve key pair (P-256)
    // 生成椭圆曲线密钥对（P-256）
    privKey, _ := ecdsa.GenerateKey(elliptic.P256(), rand.Reader)
    pubKey := append(privKey.PublicKey.X.Bytes(), privKey.PublicKey.Y.Bytes()...)

    // 2️⃣ Generate wallet address by hashing public key
    // 通过公钥哈希生成钱包地址
    addrHash := sha256.Sum256(pubKey)
    address := hex.EncodeToString(addrHash[:])
    fmt.Println("Wallet Address / 钱包地址:", address)

    // 3️⃣ Create a simple transaction
    // 构造简单交易
    tx := &Transaction{From: address, To: "receiver_wallet_123", Amount: 100}

    // 4️⃣ Hash the transaction (for signing)
    // 对交易进行哈希（签名目标）
    hash := hashTransaction(tx)

    // 5️⃣ Sign the transaction hash with private key
    // 使用私钥对交易哈希签名（得到 r 和 s）
    r, s, _ := ecdsa.Sign(rand.Reader, privKey, hash)
    tx.Signature = append(r.Bytes(), s.Bytes()...)
    fmt.Println("Signature (r|s hex) / 签名:", hex.EncodeToString(tx.Signature))

    // 6️⃣ Verify the signature using public key
    // 使用公钥验证签名
    sigLen := len(tx.Signature)
    rCheck := new(big.Int).SetBytes(tx.Signature[:sigLen/2])
    sCheck := new(big.Int).SetBytes(tx.Signature[sigLen/2:])
    valid := ecdsa.Verify(&privKey.PublicKey, hash, rCheck, sCheck)

    fmt.Println("Signature Verified / 签名验证结果:", valid)
}

Conclusion

Building a crypto wallet from the ground up taught me that blockchain security isn’t built on complexity — it’s built on clarity. A handful of elegant cryptographic rules form the foundation of everything:

the public key is a point on a curve
the address is its fingerprint
and the private key is the single root of trust

Transactions aren’t trusted — they’re verified. Every step is grounded in reproducible math.

Build Own Blockchain - 1 episode

Loading Blocks — Sun, 02 Nov 2025 11:38:45 +0000

Introduction: From Buzzword to Building Blocks

The word blockchain gets thrown around everywhere — usually surrounded by hype, buzzwords, and way too much mystery. I used to think it was some alien-level technology. But I found the best way to really understand it wasn’t by reading definitions — it was by building one myself.

So I decided to make a simple blockchain from scratch in Go. The process completely changed how I saw it. Under all the complexity, blockchain is built on a few clean, almost obvious ideas. Here are the five biggest “aha!” moments I had — the ones that turned the concept from something abstract into something I could actually reason about and code.

1. A Blockchain Is Just a Linked List with Rules

The first big surprise: a blockchain’s core structure isn’t exotic at all. It’s basically a glorified linked list with some cryptographic glue holding it together.

The basic components:

Transaction — holds from_address, to_address, and value
Block — contains a list of transactions, a timestamp, and a field called PreviousHash
Blockchain — just a slice (blocks []*Block) that stores all the blocks

Each block saves the hash of the previous one. That single rule — every block pointing back via hash — is what makes it tamper-evident. The magic isn’t in some fancy data structure, it’s in applying simple cryptography to something familiar.

2. “Mining” Is Literally Just Guessing Until You Get Lucky

I always imagined mining as some super-complicated math problem. Turns out, it’s just brute-force guessing. Proof of Work is basically a loop that keeps changing a number (called nonce) until the resulting hash starts with enough zeros.

In my code, it goes like this:

Set nonce = 0

Combine transactions, previous hash, and nonce into a block

Hash the whole thing

Check if the hash starts with the required number of leading zeros (mining_difficulty)

If not, increment nonce and repeat

That’s it. Pure trial and error. When I increased difficulty from 4 to 5, and then to 6, the mining time shot up — instantly showing how difficulty scales with computation. Mining isn’t complex, it’s just hard on purpose.

3. New Coins Come Out of Thin Air (a “Digital Faucet”)

One thing that confused me early: if every transaction just moves coins around, where do new coins come from? The answer is surprisingly simple — they’re created from nothing as a mining reward.

When a miner finds a valid block, the program creates a reward transaction. Its from_address is something like "Evo chain faucet". That faucet isn’t a real wallet, so it doesn’t have a private key. Because it can’t sign anything, the transaction has to be added manually to the block — it’s not verified like normal ones.

That’s literally how new currency enters the system: the code itself mints it as a reward for doing the computational work. In my setup, it was 1200 EVO per block. Kind of wild to see “money” just appear because a loop found a hash with enough zeros.

4. The Whole Chain Gets Saved Every Time Something Changes

Persistence was another thing that surprised me. Without a database, the blockchain only lives in memory and disappears when the app stops.

I used LevelDB as a simple key-value store. The persistence logic was super direct:

Serialize the whole blockchain struct as a JSON string

Save it in the DB under one key, "blockchain_key"

And every time anything changes — new transaction, new block — the entire chain gets serialized and written again. It’s definitely not efficient for a big system, but it’s dead simple and reliable for a prototype. No state gets lost.

5. Wallet Balances Aren’t Stored — They’re Rebuilt from History

This one blew my mind: there’s no “balance” field stored anywhere. To get your wallet balance, the program recalculates it every time by replaying every transaction in history.

My first version only added incoming funds, which gave wrong results. The correct approach:

Start from zero

Loop through every block

Loop through every transaction inside it

If to_address == target, add value

If from_address == target, subtract value

At the end, the sum is your balance. Nothing is stored — the balance emerges from the chain’s full transaction history. In this world, history is the state.

Conclusion

Building a blockchain by hand stripped away the hype. What’s left is something surprisingly elegant:

A linked list with cryptographic links

A brute-force guessing loop for consensus

A code-driven faucet that mints new coins

A state that’s just the sum of its entire past

Once you see it that way, blockchain stops feeling like black magic — and starts looking like one of the simplest, smartest systems you could ever build.

video explain

Web3 Development Toolchain

Loading Blocks — Thu, 02 Oct 2025 08:58:14 +0000

These artical serve as a practical, step-by-step guide to the essential tools in the modern Web3 development stack. It provides a structured overview of setting up a local development environment with VS Code, managing professional projects with Hard Hat, and establishing scalable blockchain connectivity with Alchemy. Together, these components form a complete workflow for building, testing, and deploying decentralized applications.

1. VS Code + Remix Extension

Purpose: Use VS Code as a professional IDE with Remix features integrated (compile, deploy, debug smart contracts).

Essential Extensions:

Ethereum Remix → Compile/deploy/debug from VS Code

Prettier → Code formatting for consistency

Solidity → Syntax highlighting and snippets

Workflow:

Start remixd client in VS Code

Open Remix IDE in browser → connect to localhost

VS Code acts as a proxy, allowing compilation/deployment directly

Debugger:

Step Into / Step Over / Step Back / Step Over Back

Breakpoints for transaction trace navigation

Limitation: Great for single contracts, but lacks dependency management, automation, and test frameworks → solved by Hard Hat.

2. Hard Hat — Professional Development Framework

Purpose: Manage the entire contract lifecycle with testing, local blockchain, deployment automation.

Project Structure:

contracts/ → Solidity contracts

scripts/ → Deployment scripts

test/ → Automated tests (Mocha + Chai)

hardhat.config.js → Compiler & network config

Core Commands:

npx hardhat compile → Compile contracts

npx hardhat test → Run tests

npx hardhat node → Launch local in-memory blockchain (20 accounts, each with 10k ETH)

npx hardhat run script.js --network rinkeby → Execute scripts on chosen network

Local Network:

Fast, zero gas cost, pre-funded accounts

Non-persistent (resets after restart) → perfect for clean test runs

Key Value: Moves from single-contract debugging to project-level management.

3. Alchemy — Scalable Node Infrastructure

Purpose: Provide reliable, scalable blockchain node services for production dApps.

Usage with ethers.js:

const provider = new ethers.providers.AlchemyProvider("homestead", process.env.ALCHEMY_API_KEY);
const blockNumber = await provider.getBlockNumber();
console.log("Block:", blockNumber);

⚠️ Always load API keys from .env, never hardcode.

Features:

Global distributed nodes → handle high traffic with low latency
Analytics dashboard → track requests, response times, most-called RPC methods

Use Cases:

Large platforms (e.g., OpenSea, Shopify) use Alchemy for scalable, stable blockchain queries

Truffle Suite

Introduction

Truffle Suite: One of the earliest and Web3 toolchains.

Positioning: Comparable to Hardhat. Both solve:

Smart contract compilation, testing, deployment

Local blockchain simulation

Key Value: Integrated, end-to-end workflow covering the entire lifecycle.

Core Components

Truffle (Core Framework)

Provides project structure & CLI.

Features:

Automated contract testing (built-in framework)

Deployment scripting across networks

Integration with local blockchain (via Ganache)

Ganache (Personal Blockchain)

Local Ethereum simulator with instant mining & zero gas costs.

Advantages:

GUI for accounts, balances, transactions, contract states

Same purpose as Hardhat Node, but with visualization

Easily connects with wallets like MetaMask

Drizzle (Front-End Integration Layer)

Simplifies DApp UI ↔ blockchain state sync.

Features:

Redux-based core for predictable state management

Prebuilt React UI components (forms, buttons)

Automates event listening, transaction tracking

Trade-off: More dependencies; better for complex DApps, overhead for small projects.

Waffle (Testing Framework)

Adds blockchain-aware assertions to tests.

Benefits:

expect(...).to.be.reverted → clean revert check

expect(...).to.emit(...) → declarative event check

More expressive than vanilla Mocha/Chai.

Integrated Workflow

Truffle → Structure, compile, deploy contracts

Ganache → Local blockchain simulation

Waffle → Enhanced testing with blockchain matchers

Drizzle → Keep front-end in sync with contract state

Result: Full-stack, closed-loop DApp development workflow.

Truffle vs. Hardhat – Which One to Choose?

Scenario	Truffle	Hardhat
Learning Curve	Beginner-friendly (Ganache GUI, Drizzle support)	Developer-focused, requires more coding/config comfort
Ecosystem	Integrated end-to-end suite (compile → test → UI)	Modular, plugin-rich (Ethers.js, TypeChain, Foundry, etc.)
Testing	Works with built-in tests + Waffle	Flexible, Chai + custom matchers, strong debugging utilities
Frontend Integration	Drizzle (Redux-based sync between UI & blockchain)	No native frontend layer, rely on ethers.js/web3.js
Community & Adoption	Earlier tool, smaller community today	Actively maintained, widely adopted in 2024–2025
Use Case Fit	Prototypes, educational projects, full-stack DApps needing built-in frontend sync	Production-grade apps, teams needing scalability, debugging, plugins

👉 Rule of thumb:

Truffle = good for learning, prototypes, integrated frontend.

Hardhat = better for modern production workflows, plugins, debugging.

Ethers.js Developer Guide – Practical

Loading Blocks — Sat, 27 Sep 2025 15:50:53 +0000

1. Introduction

Ethers.js is a lightweight JavaScript library for interacting with the Ethereum blockchain. It provides:

A unified way to connect to Ethereum nodes.
Tools for creating and managing wallets.
A simple API for calling smart contracts.
Built-in utilities for handling blockchain-specific data formats (e.g., BigNumber, hex strings, hashes).

Compared to alternatives like web3.js, Ethers.js is designed to be:

Smaller (tree-shakeable, modular).
Safer (immutability, strict typing).
Developer-friendly (clean API surface).

2. Setup

Install via npm (or yarn/pnpm):

npm install ethers

import { ethers } from "ethers";

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

async function main() {
  const provider = ethers.getDefaultProvider();
  const blockNumber = await provider.getBlockNumber();
  console.log("Latest block:", blockNumber);
}

main();

Providers – Connecting to Ethereum

A Provider is your connection to the Ethereum network. Think of it as a “read-only API”.

JSON-RPC Provider

const provider = new ethers.JsonRpcProvider("http://localhost:8545");

Infura

const provider = new ethers.InfuraProvider("mainnet", process.env.INFURA_API_KEY);

Alchemy

const provider = new ethers.AlchemyProvider("sepolia", process.env.ALCHEMY_API_KEY);

Etherscan (read-only)

const provider = new ethers.EtherscanProvider("mainnet", process.env.ETHERSCAN_API_KEY);

Browser Provider (MetaMask)

const provider = new ethers.BrowserProvider(window.ethereum);
await provider.send("eth_requestAccounts", []);

Recap:

Provider = blockchain connection.

Use RPC for local, Infura/Alchemy for production, MetaMask for browser.

Wallets – Managing Keys

A Wallet represents an Ethereum account (private key + address).

Create a Random Wallet

const wallet = ethers.Wallet.createRandom();
console.log("Address:", wallet.address);
console.log("Mnemonic:", wallet.mnemonic.phrase);

Import from Private Key

const wallet = new ethers.Wallet(process.env.PRIVATE_KEY);

Import from Mnemonic

const wallet = ethers.Wallet.fromPhrase("test test test ...");

Connect Wallet to Provider

const provider = new ethers.JsonRpcProvider("https://rpc.sepolia.org");
const wallet = new ethers.Wallet(process.env.PRIVATE_KEY, provider);

Sign a Message

const signature = await wallet.signMessage("Hello Ethereum");
console.log("Signature:", signature);

Send a Transaction

const tx = await wallet.sendTransaction({
  to: "0xabc123...def",
  value: ethers.parseEther("0.01")
});
console.log("Transaction hash:", tx.hash);

⚡ Recap:

Wallet = identity + signer.

Always connect wallet → provider before sending transactions.

Contracts – Interacting with Smart Contracts

A Contract object allows you to call functions defined in a smart contract.

Define a Contract

const abi = [
  "function balanceOf(address) view returns (uint)",
  "function transfer(address, uint) returns (bool)"
];
const tokenAddress = "0xYourTokenAddress";
const contract = new ethers.Contract(tokenAddress, abi, provider);

Read Data

const balance = await contract.balanceOf("0xabc123...");
console.log("Balance:", ethers.formatUnits(balance, 18));

Write Data (with Signer)

const signer = new ethers.Wallet(process.env.PRIVATE_KEY, provider);
const contractWithSigner = contract.connect(signer);

const tx = await contractWithSigner.transfer("0xdef456...", ethers.parseUnits("1", 18));
await tx.wait();
console.log("Transfer confirmed:", tx.hash);

Listen to Events

contract.on("Transfer", (from, to, value) => {
  console.log(`Transfer: ${value} tokens from ${from} to ${to}`);
});

Recap:

Contract = interface + ABI + address.

Use provider for read calls, wallet signer for transactions.

Utilities – Everyday Helpers

Unit Conversion

const value = ethers.parseEther("1.0");
console.log(value.toString());
console.log(ethers.formatEther(value));

BigNumber Math

const a = ethers.parseUnits("1000", 18);
const b = ethers.parseUnits("250", 18);
console.log(a.add(b).toString());

Hashing

const hash = ethers.keccak256(ethers.toUtf8Bytes("hello"));
console.log("Hash:", hash);

Address Helpers

console.log(ethers.isAddress("0xabc123...")); 
console.log(ethers.getAddress("0xabc123..."));

⚡ Recap: Utilities handle ETH units, big numbers, hashes, addresses.

Advanced Topics

Gas Estimation & Overrides

const gas = await contract.estimateGas.transfer("0xdef...", ethers.parseUnits("1", 18));
const tx = await contractWithSigner.transfer("0xdef...", ethers.parseUnits("1", 18), {
  gasLimit: gas * 2n
});

Event Filters

const filter = contract.filters.Transfer(null, "0xdef...");
const events = await contract.queryFilter(filter, -1000, "latest");
console.log(events);

Security Tips

Never hardcode private keys.

Use BrowserProvider for frontend dApps.

Validate user inputs.

Quick Recap (Cheat Sheet)

Provider = connect (JsonRpcProvider, InfuraProvider, BrowserProvider).

Wallet = manage keys + sign transactions.

Contract = interact with ABI.

Utilities = conversions, hashes, addresses.

Advanced = gas, filters, security.

Connecting to the Ethereum Blockchain

Loading Blocks — Sat, 27 Sep 2025 14:55:54 +0000

Ethers.js: MetaMask Client-Side Connection Guide

Ethers.js is a foundational JavaScript library for interacting with the Ethereum blockchain and its ecosystem. It provides a concise yet powerful interface for connecting to Ethereum nodes through providers like JSON-RPC, Infura, Etherscan, Alchemy, Cloudflare, or MetaMask.

This guide focuses on client-side dApp integration with MetaMask, targeting experienced front-end developers who want to wire up wallet connectivity and blockchain queries without unnecessary boilerplate.

MetaMask Connection Flow

MetaMask injects the window.ethereum object into the browser context. Your dApp interacts with this object through Ethers.js by wrapping it in a Web3Provider.

Minimal HTML Setup

MetaMask requires a browser context; direct file execution (file:///...) won’t work. You’ll need to serve your page (e.g., with VS Code Live Server).

ether.html

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Ethers.js + MetaMask</title>
</head>
<body>
  <script src="https://cdn.jsdelivr.net/npm/ethers@5.7.2/dist/ethers.min.js"></script>
  <script>
    (async () => {
      if (!window.ethereum) {
        console.error("MetaMask not detected");
        return;
      }

      // 1. Provider from injected Ethereum object
      const provider = new ethers.providers.Web3Provider(window.ethereum);

      // 2. Request account access (triggers MetaMask prompt)
      await provider.send("eth_requestAccounts", []);

      // 3. Differentiate: provider vs signer
      const signer = provider.getSigner();

      // 4. Example: fetch data
      const blockNumber = await provider.getBlockNumber();
      console.log("Current block:", blockNumber);

      // 5. Example: active account
      const address = await signer.getAddress();
      console.log("Connected account:", address);
    })();
  </script>
</body>
</html>

Key Concepts

Provider → read-only blockchain access (e.g., block number, balance, contract state).

Signer → account-specific, signs transactions/messages, required for state-changing ops.

Testing

Serve with Live Server (VS Code) or any HTTP server.

Load the page in a MetaMask-enabled browser.

Approve the connection prompt.

Inspect the console for current block number and connected address.

Saving Real Money: Rethinking Solidity Gas Optimization

Loading Blocks — Mon, 22 Sep 2025 15:39:50 +0000

Introduction: Saving Gas from Unexpected Places

In Ethereum development, Gas fees are a very real financial burden. Every deployment, transaction, and state change costs actual money. While most developers look for ways to cut Gas usage, many of the most effective optimization tricks are actually counterintuitive.

The key to real Gas savings lies in understanding two fundamental principles of the EVM (Ethereum Virtual Machine):

Storage operations are extremely expensive.

The EVM is built around a 256-bit (32-byte) word size.

With these principles in mind, let’s dive into five surprising optimization techniques.

1. Variable Order Determines Cost — The Magic of Variable Packing

Solidity stores state variables in 32-byte storage slots.

Multiple smaller variables can be packed into a single slot, but only if declared consecutively.

Each new slot written requires an expensive STORE operation.

By rearranging variable declarations, you can reduce the number of slots used.

Example:

Unoptimized: variables consume 3 slots.

Optimized: variables consume 2 slots by grouping uint8, uint8, and uint128 together.

👉 Key insight: Put small variables next to each other to maximize packing and minimize storage costs.

2. Smaller Variables Are Always Cheaper? Not Really.

A common misconception: using uint8 instead of uint256 always saves Gas.

In reality, the EVM natively operates on 256-bit words.

If a small type is not packed, the EVM has to extend it to 256 bits before performing arithmetic, costing extra Gas.

Rule: Use smaller types only if they can be packed. Otherwise, stick with uint256.

3. Delete Variables for a Gas Refund

The delete keyword resets a variable to its default value and signals the EVM that storage is being freed.

As a result, the transaction receives a Gas refund.

In contrast, x = 0 just performs an STORE with no refund.

Refunds are capped at about 50% of the transaction Gas used to prevent abuse.

👉 Key insight: Always use delete instead of manual reset when clearing storage.

4. Loop Trap: Cache Storage Variables

Reading (SLOAD) or writing (STORE) inside a loop is extremely costly.

Naïve approach: Every iteration accesses storage directly → 100 costly reads/writes.

Optimized approach: Cache the value into a local memory variable before the loop, then write back only once.

This transforms 100 storage operations into just 1, saving massive Gas.

👉 Key insight: Always cache storage variables in memory when used repeatedly inside loops.

5. calldata vs memory — No Free Lunch? Actually, Yes.

calldata: Acts like a read-only “window” into the transaction input. No copying, extremely cheap.

memory: Requires copying data from calldata into a new memory allocation. More expensive, but allows modifications.

For external functions where parameters don’t need modification, calldata is always the cheaper and safer choice.

👉 Key insight: Use calldata for read-only parameters (arrays, strings, structs) in external functions.

Conclusion:

True optimization is not about memorizing rules, but about understanding the EVM’s cost model:

Storage is expensive.

Memory is cheap.

calldata is almost free.

Computation is cheap, but state changes are not

Solidity Libraries

Loading Blocks — Mon, 22 Sep 2025 14:59:54 +0000

1. Five Core Restrictions

Libraries are powerful because of strict rules:

Stateless: no state variables allowed.

No inheritance: cannot inherit or be inherited.

Indestructible: no selfdestruct.

No payable/fallback: can’t hold ETH.

No abstract functions: all must be fully implemented.

These restrictions ensure predictability, safety, and trustworthiness.

2. The Magic of using for — Extending Data Types

Normal call: Math.max(numbers)

With using for:

using Math for int[];
numbers.max();

Compiler automatically passes the variable (numbers) as the first argument.

Convention: call this parameter self (like this in OOP).

This makes Solidity code feel more object-oriented.

Conclusion

Solidity libraries are much more than a toolbox:

Strict safety rules keep them pure and reliable.

using for adds elegance and OOP-like syntax.

Off-chain calls may be free, but on-chain execution still costs Gas.

Deployable as shared infrastructure → true on-chain microservices.

They’re not just helpers — they’re a core design pattern for secure, efficient, and modular smart contracts.

Abstract Contracts in Solidity

Loading Blocks — Mon, 22 Sep 2025 14:13:52 +0000

In Solidity development, when we talk about contract inheritance or reusable templates, we often think of abstract contracts.

Many developers see them simply as an interface or an unfinished blueprint. In reality, abstract contracts are much more subtle and powerful. This article reveals four surprising truths about abstract contracts in Solidity that might change the way you design your contracts.

1. Not Just Empty Shells

Abstract contracts are not just collections of unimplemented functions. They are a hybrid construct—capable of holding both implemented (concrete) functions and unimplemented (abstract) functions.

Take the following abstractMath example:

abstract contract abstractMath {
    // A concrete, implemented function
    function addFive() public view returns (uint) {
        return getValue() + 5; // depends on an unimplemented function
    }

    // An abstract, unimplemented function
    function getValue() public virtual view returns (uint);
}

addFive is fully implemented.
But it relies on getValue, which is not defined here.

The Solidity compiler enforces a key rule: any unimplemented function in an abstract contract must be marked as virtual, making it clear that the function is intended to be overridden.

This pattern is powerful because:

The base contract (abstractMath) defines core reusable behavior (addFive).

All child contracts must implement the missing parts (getValue).

Thus, abstract contracts combine reusability with enforced design constraints.

2. “Deployment Failure” Is the Point: Abstract Contracts Cannot Be Instantiated

One fundamental rule: you cannot deploy an abstract contract directly.

If you try to deploy abstractMath, the compiler will throw an error. This isn’t a bug — it’s by design.

Why?

Abstract contracts exist solely to act as parent contracts.

They define structure and (optionally) partial logic, but they cannot function alone.

Blocking deployment prevents incomplete or non-functional contracts from being published on-chain. It ensures only fully implemented child contracts reach deployment, avoiding dangerous “half-built” states.

Conclusion: Beyond Interfaces, Toward Enforceable Design

Abstract contracts in Solidity are far more than unfinished templates. They:

Can mix reusable logic with abstract requirements.

Cannot be deployed directly, by design.

Are strictly enforced by the compiler to guarantee completeness.

Can be abstract without abstract functions, thanks to internal constructors.

Together, these rules turn abstract contracts into a powerful design pattern—not just defining structure, but enforcing architecture, ensuring correctness, and making your smart contracts safer and more maintainable.

Enums in Solidity

Loading Blocks — Sun, 21 Sep 2025 15:21:36 +0000

The most intuitive solutions—like using strings or plain numbers—may seem simple at first, but in the world of smart contracts, they hide huge pitfalls. These approaches can either waste gas or hurt code readability and maintainability.

Fortunately, Solidity provides an elegant and efficient solution: enums. This article uncovers three key insights about enums that will help you write clearer and more efficient smart contracts.

1. The Simple Trap

When choosing how to represent states, developers often fall into two common traps: using strings or “magic numbers.” Let’s see why both are bad choices in Solidity.

The String Problem

Using strings like "pending" feels natural, but it has major downsides:

String operations are expensive in Solidity.
Comparisons are inefficient.
Storing and managing them burns gas unnecessarily.

The Magic Number Problem

Another approach is to use integers to represent states:

1 → pending
2 → shipped
3 → delivered

While this is more gas-efficient, it destroys readability:

In short:

Strings → costly for users (gas).
Numbers → costly for developers (maintainability). Both are unacceptable in smart contract design.

2. The Best of Both Worlds: Enum’s Readability and Efficiency

Enums solve both of these problems at once, providing clarity for developers and efficiency for the EVM.

Core Concept

An enum lets you define a custom type with a fixed set of named values. For example:

enum Status {
    Pending,
    Shipped,
    Delivered
}

Dual Advantages

For developers: Enums make code self-explanatory.
if (status == Status.Delivered) { ... }
is infinitely clearer than status == 2.
For the EVM: Under the hood, enums are just unsigned integers.

Pending = 0

Shipped = 1

Delivered = 2

Enums combine human readability with machine efficiency, making them the go-to tool for state management.

Conclusion

Enums are far more than syntactic sugar—they’re a fundamental building block for writing clear, safe, and efficient Solidity code.

If you’re writing smart contracts, mastering enums is not optional—it’s essential.

5 Advanced Solidity Modifier Tricks

Loading Blocks — Sun, 21 Sep 2025 14:42:42 +0000

1. Modifiers Can Change State

Usual role: run require checks before function execution.
Hidden power: modifiers can update state variables.

address public owner;
uint public modifierCount;

modifier onlyOwner {
    require(msg.sender == owner);
    modifierCount++;  // state change inside modifier
    _;
}

Result: modifierCount increases every time onlyOwner is triggered.

Takeaway: modifiers can serve as pre-processors (logging, state prep, counters).

2. Evolution: Dynamic Modifiers With Parameters

(a) Literal Parameters

Instead of writing many modifiers, pass values directly:

modifier cost(uint value) {
    require(msg.value >= value, "Insufficient fee");
    _;
}

function setX() public payable cost(1 ether) { ... }
function setY() public payable cost(2 ether) { ... }

Flexible: one generic modifier → multiple use cases.

(b) Function Parameters

Modifiers can also take function arguments:

modifier greaterThan(uint val, uint min) {
    require(val > min, "Input value is too low");
    _;
}

function setX(uint num) public greaterThan(num, 10) {
    // executes only if num > 10
}

3. Execution Order of Multiple Modifiers

Multiple modifiers run in the listed order.

function setX(uint num) 
    public 
    payable 
    cost(1 ether) 
    greaterThan(num, 10) 
{
    // ...
}

Flow:

cost runs first.
Then greaterThan.
Only then the function body.

Mechanism: each _ means “execute the next step in the chain”.

Function body is just the last step in the chain.

4. Multiple _ → Multiple Executions

You can place multiple _ in one modifier.

uint public count;

modifier tripleExecute(uint val) {
    require(val > 10, "Too low");
    _;
    _;
    _;
}

function setX(uint num) public tripleExecute(num) {
    count++;
}

setX increments count three times per call.

Rarely practical, but illustrates that _ = “insert function body here.

Conclusion

Modifiers can:

Update state directly.

Accept dynamic parameters (literals + function inputs).

Chain together in controlled execution order.

Execute functions multiple times with multiple _.

Solidity Structs

Loading Blocks — Sun, 21 Sep 2025 14:12:10 +0000

1. Beyond Simple Data Organization

Challenge: managing related but different types of data (e.g., string name, address wallet, uint balance).
Naive approach: multiple mappings or arrays → messy and hard to maintain.

Solution: structs = custom types that combine multiple fields into one logical unit.
Structs are not just containers, but powerful data modeling tools.

2. Trick 1

When accessing a mapping with struct values, if the key was never set:
- Solidity does not throw an error.
- Instead, it returns a default-initialized struct.
Default values:
- string → empty string ""
- address → 0x0...0
- uint → 0
This allows an upsert pattern:
- No need for if (exists) checks.
- Directly assign values whether it’s the first time or an update.
Benefit: simplifies logic, merges create + update into one unified operation.

3. Trick 2

Structs can include:
- basic types (string, uint),
- other structs,
- dynamic arrays
Example:

struct Person {
    string name;
    address addr;
    uint balance;
    Person[] friends;
}

you can push another Person into the friends array.

Enables building on-chain relationship graphs, e.g., social networks.

Core insight: struct composition makes advanced modeling possible (nested structs, graphs, linked data).

4. Trick 3

In functions, struct variables must specify data location (memory or storage).

Omit it → compilation error.

Two initialization methods:

Positional Initialization (compact but order-dependent):
Person memory p = Person("Tim", msg.sender, msg.value);
Key-Value Initialization (verbose but flexible):

Person memory p = Person({
    name: _name,
    addr: msg.sender,
    balance: msg.value
});

Rules:

All fields must be provided.

Both methods enforce complete initialization → prevents partially defined structs.

5. Conclusion

Structs in Solidity go far beyond simple aggregation

Key powers:

Default struct behavior enables elegant upsert patterns.

Self-referencing arrays allow building complex graph structures.

Strict but flexible initialization rules balance readability and safety.

Together, these form the foundation of clear, rigorous, and powerful on-chain data architectures.

Time Handling

Loading Blocks — Sun, 21 Sep 2025 13:32:29 +0000

1. Block Time, Not Real Time

In Solidity, block.timestamp gives the timestamp of the block that included your transaction, ** not the exact submission time**
All transactions in the same block share the same block.timestamp
This means "first come, first served" logic cannot rely on precise timestamps.
The old keyword now was just an alias for block.timestamp, but it's deprecated now.

Get Seconds Since 1970

block.timestamp returns a Unix timestamp, i.e., the number of seconds since January 1, 1970(Uinx epoch)
It's a standard across computer science, not unique to Solidity.

Solidity Makes Time Arithmetic Simple

Solidity provides time units: seconds,minutes, hours, days, weeks.
These can be used directly in expressions:
- block.timestamp + 1 days
- block.timestamp - 7 days
This improves readablity and prevents errors from using "magic numbers".

Building Contracts With Lifecycles

You can implement expiry logic by setting a deadline in the constructor:


uint public expiry;

constructor() {
    expiry = block.timestamp + 1 minutes;
}

function addOne() public {
    require(block.timestamp < expiry, "Contract has expired");
    count++;
}

This pattern enables time-based features like token vesting, limited auctions, or timed voting.

Conclusion

Correct time handling = safer and more predictable smart contracts.
Four pillars:
Block time consensus model.
Unix timestamp standard.
Readable time units in Solidity
Lifecycle enforcement via expiry checks.