Forem: MihaiHng

Ethereum-Solidity Quiz Q32: What transaction types are used in Ethereum?

MihaiHng — Sat, 21 Feb 2026 12:57:19 +0000

────────────────────────────────────────────────────────────────────
                         TRANSACTION TYPES                                    
────────────────────────────────────────────────────────────────────

1. CREATE     - Deploy contract (address depends on deployer + nonce)
2. CREATE2    - Deploy contract (address is deterministic/predictable)
3. CALL       - Call a function on existing contract
4. DELEGATECALL - Call using caller's storage (used by proxies internally)

Transaction Types Explained

1. CREATE

// Regular contract deployment
new MyContract(arg1, arg2);
json{
  "transactionType": "CREATE",
  "to": null,  // ◄── null means contract creation
  "contractAddress": "0x..."
}

2. CREATE2

// Deterministic deployment via factory
// Foundry does this automatically for libraries
json{
  "transactionType": "CREATE2",
  "to": "0x4e59b448...",  // ◄── Factory address
  "contractAddress": "0x..."
}

3. CALL

// Function call on existing contract
provider.setStablecoin(usdcAddress);
json{
  "transactionType": "CALL",
  "to": "0xa729b836...",  // ◄── Contract being called
  "function": "setStablecoin(address)",
  "arguments": ["0x1c7D4B19..."]
}

4. DELEGATECALL (Internal, not in broadcast)

// Used by proxies - executes code in caller's context
// You won't see this in transactions, it's internal
proxy.delegatecall(implementation, data);

Ethereum-Solidity Quiz Q31: What is the difference between CREATE and CREATE2 transaction types?

MihaiHng — Thu, 19 Feb 2026 16:12:34 +0000

CREATE (Regular Deployment)

// Address = keccak256(deployer, nonce)
new CreateContract(owner);

──────────────────────────────────────────────────────────────────
                             CREATE                                         
──────────────────────────────────────────────────────────────────

Example:
  Deployer: 0x4f98e7507c578e2341B5b874E9a7C910aA8Db3e1
  Nonce: 234
  ──────────────────────────────────────────────────────
  Result: 0xa729B8363b472E8A3f20eF4E6210Cdd70C0cF5aB

Characteristics:
  ✅ Simple, default behavior
  ❌ Address changes if nonce changes
  ❌ Can't predict address before deployment
  ❌ Different address on each chain (different nonces)

CREATE2 (Deterministic Deployment)

// Address = keccak256(0xff, factory, salt, initCodeHash)
// Used automatically by Foundry for libraries

─────────────────────────────────────────────────────────────────
                              CREATE2                                         
─────────────────────────────────────────────────────────────────

Example:
  Factory: 0x4f98e7507c578e2341B5b874E9a7C910aA8Db3e1 (Deterministic Deployer)
  Salt: 0x0000...0000
  InitCode: <bytecode of Library>
  ──────────────────────────────────────────────────────
  Result: 0xEdA41181EAB196E739140876C5fF35e2DFde188a

Characteristics:
  ✅ Same address on ALL chains (if same salt + bytecode)
  ✅ Predictable before deployment
  ✅ Great for libraries, factories, cross-chain deploys
  ❌ Slightly more complex
  ❌ Requires a factory contract

Visual Comparison

CREATE:
─────────────────────────────────────────────────────────────────

Deployer (0x4f98...) ──► Deploy Contract
         │
         │  address = hash(deployer, nonce)
         │
         ▼
    Ethereum: 0xAAA...  (nonce = 100)
    Base:     0xBBB...  (nonce = 50)   ◄── Different addresses!
    Polygon:  0xCCC...  (nonce = 75)


CREATE2:
─────────────────────────────────────────────────────────────────

Deployer ──► Factory (0x4e59b448...) ──► Deploy Contract
                    │
                    │  address = hash(0xff, factory, salt, bytecodeHash)
                    │
                    ▼
    Ethereum: 0xEdA411...
    Base:     0xEdA411...  ◄── SAME address everywhere!
    Polygon:  0xEdA411...

Ethereum-Solidity Quiz Q30: What does keccak256() do?

MihaiHng — Sun, 08 Feb 2026 19:09:55 +0000

keccak256() is a cryptographic hash function, used for everything from generating addresses to verifying transaction integrity.

In short, you feed it any amount of data, and it generates a unique, fixed-size 32-byte "fingerprint" that can never be reversed.

1. Characteristics

Deterministic: The same input will always produce the exact same hash.

Fixed Output: No matter if you hash a single number or a 1GB file, the output is always 32 bytes (bytes32).

One-Way: It is computationally impossible to reconstruct the original data from the hash.

Collision Resistant: It is practically impossible to find two different inputs that produce the same hash.

2. Practical Use Cases in Your Smart Contracts

A. Comparing Strings

Solidity cannot compare strings directly using ==. Instead, we hash them and compare the results:

function compare(string memory _a, string memory _b) public pure returns (bool) {
    return keccak256(abi.encodePacked(_a)) == keccak256(abi.encodePacked(_b));
}

B. Creating Unique Identifiers

You can combine multiple variables (like an address and a timestamp) to create a unique ID for a transaction or a user:

bytes32 uniqueId = keccak256(abi.encodePacked(msg.sender, block.timestamp));

C. Computing Function Selectors

Ethereum uses keccak256 to identify which function to call. It takes the first 4 bytes of the hash of the function signature (e.g., transfer(address,uint256)).

3. Important: abi.encodePacked vs abi.encode

The keccak256 function only accepts a single bytes argument. To hash multiple values, you must "wrap" them first.

abi.encodePacked(...): Most common. It’s cheaper on gas because it doesn't add padding.

abi.encode(...): Safer for dynamic types (like two strings).

Ethereum-Solidity Quiz Q29: What is an Overflow/Underflow?

MihaiHng — Sat, 07 Feb 2026 17:41:48 +0000

Overflow and Underflow are arithmetic errors that occur when a calculation results in a number that is outside the fixed range of the variable's data type.

1. Explanation

Term	What happens	Example (uint8: range 0–255)
Overflow	You exceed the maximum value and the number "wraps" to the bottom.	255 + 1 --> 0
Underflow	You go below the minimum value and the number "jumps" to the top.	0 - 1 --> 255

2. Solidity 0.8.0

Before version 0.8.0, Solidity did not check for these errors. You had to use a library called SafeMath to prevent them.

Since 0.8.0: The compiler includes built-in checks. If an overflow or underflow occurs, the transaction reverts (fails) automatically with a "Panic" error.

The unchecked Block: Sometimes, you know a calculation is safe and you want to save gas by skipping the check. You can wrap that code in an unchecked block:

// This will NOT revert; it will wrap around to 0
unchecked {
    uint8 x = 255;
    x++; 
}

3. Prevention

Use Solidity >= 0.8.0: This is the easiest and most important step.
Typecasting Caution: Even in 0.8.0, casting a large type to a small type (e.g., uint256 to uint8) can still cause "silent" wrapping without a revert. Always check the range before casting.
Use uint256: Unless you have a specific reason (like fitting data into a single storage slot/32 bytes), stick to uint256. It has such a massive range (2^256 - 1) that it is practically impossible to overflow in most financial applications.

Ethereum-Solidity Quiz Q28: What is the difference between libraries, interfaces and abstracts?

MihaiHng — Wed, 04 Feb 2026 15:54:21 +0000

1. Interfaces

An interface defines what a contract must do, but provides zero implementation. It’s a architectural blueprint.

Properties: no state variables, no constructor, and all functions must be external.

Use Case: Interaction. You use interfaces to talk to other contracts (like calling balanceOf on a USDC contract).

2. Abstract Contracts

An abstract contract contains some logic but leaves other parts for the "child" contract to implement.

Properties: Can have state variables, internal functions with logic, and constructors. If at least one function is missing its body or marked virtual, the contract must be declared abstract and can not be deployed.

Use Case: Templates. You use this when you have a "base" design that can be specialized later.

3. Libraries

Libraries are stateless and intended to be reused.

Properties: no state variables, cannot receive Ether, and cannot be destroyed. They are meant to perform operations on the data you pass to them.

Use Case: Utility functions. Think of the SafeERC20 or SafeMath libraries. They provide "helper" logic that many contracts can use.

Comparison Table:

Feature	Library	Abstract	Interface
Can have state	❌	✅	❌
Can have implementation	✅	✅	❌
Can be instantiated	❌	❌	❌
Can be inherited	❌	✅	✅
Must implement all functions	N/A	❌ (only abstract ones)	✅
Function visibility	internal/external	Any	external only
Used for	Utility functions	Shared implementation	Defining standards

Ethereum-Solidity Quiz Q27: How are Layer 2 networks making transactions fees cheaper?

MihaiHng — Mon, 02 Feb 2026 14:26:57 +0000

Layer 2 networks make transactions cheaper by changing the location and density of where computation happens.

If we think of Ethereum (Layer 1) as a busy highway where every car pays a high tax, a Layer 2 is like a giant bus. It collects hundreds of passengers (transactions), drives them down the highway, and splits the single high tax among everyone on board.

1. The Rollup Mechanism

L2s use a technology called Rollups. They "roll up" hundreds of transactions into a single batch.

Execution (Off-chain): The actual computation (e.g., token swap) happens on the L2's own servers. This is very cheap because it doesn't require thousands of global nodes to agree simultaneously.
Settlement (On-chain): Instead of sending every detail to Ethereum, the L2 sends only a highly compressed summary of all those transactions.

2. How the Fee is Calculated on L2

On a Layer 2, the fee consists of two parts:

A. The L2 Execution Fee

This is the cost of running the transaction on the L2's own network.

Cost: Extremely low (fractions of a cent).
Why: L2s are designed for high throughput and don't have the massive decentralization overhead of Ethereum.

B. The L1 Security Fee

This is the most expensive part. To stay secure, the L2 must post its transaction data back to Ethereum Layer 1 so that anyone can verify the state.

Cost: This depends on the current gas price of Ethereum.
Efficiency: Because the data for 500 transactions is compressed into one "blob" or batch, you only pay for 1/500th of the Ethereum block space.

3. The "Blob" Revolution (EIP-4844)

In 2024, Ethereum introduced "Blobs" (Binary Large Objects). Before this, L2s had to store their data in a part of the Ethereum block called calldata, which was very expensive.

Blobs are like "sidecars" attached to a block. They are temporary and deleted after about 18 days.
Because they don't stay on the blockchain forever, Ethereum charges a significantly lower fee for Blobs.
This update dropped L2 fees by 90% or more, making transactions cost as little as $0.01.

4. Security

The risk with L2s is Centralization. Most L2s currently use a "Sequencer" (a single server) to order transactions. If that server goes down, the network pauses.

5. Summary

From a systems perspective, L2s move the State Transition logic off-chain and only use Layer 1 as a Data Availability layer. By treating the most expensive resource (Ethereum block space) as a shared cost through compression and blobs, they achieve a 10x–100x reduction in fees without sacrificing the underlying security of the Ethereum mainnet.

Ethereum-Solidity Quiz Q26: How is the base fee(used in calculating the total gas fee) calculated by Ethereum?

MihaiHng — Tue, 27 Jan 2026 19:37:11 +0000

In the current Ethereum system (introduced by EIP-1559), the Base Fee is not set by users or miners/validators, it is automatically calculated by the network’s protocol itself based on block space demand. It's like a dynamic congestion tax that updates every block (~ 12 seconds).

1. The Target Capacity (50% Rule)

Ethereum has a Target size for each block, currently set at 15 million gas, with the Hard Limit at 30 million gas.

The protocol calculates the next Base Fee based on how full the current block is compared to that 15 million target:

If the block is > 50% full: The Base Fee increases for the next block (the network is busy).
If the block is < 50% full: The Base Fee decreases for the next block (the network has idle capacity).
If the block is exactly 50% full: The Base Fee remains the same.

2. The Mathematical Formula

The maximum the Base Fee can change between two consecutive blocks is 12.5%.

The simplified logic for the next block's Base Fee is:

New Base Fee = Current Base Fee + [Current Base Fee × (Actual Gas Used - Target Gas) / Target Gas × 0.125]

Example Scenarios:

Maximum Congestion: If a block is 100% full (30M gas), the Base Fee increases by exactly 12.5% for the next block.

Empty Network: If a block is 0% full (0 gas), the Base Fee decreases by exactly 12.5% for the next block.

3. What happens to the Base Fee? (The Burn)

One of the most important aspects of the Base Fee is that it is burned. Before this update, all fees went to the miners/validators.

Now, the Base Fee is removed from the total supply of ETH. Only the Priority Fee (Tip) goes to the validator. This creates deflationary pressure — when the network is extremely busy, Ethereum actually destroys more ETH than it creates.

4. Why this change?

Before this calculation method was introduced, users had to "guess" the right price in a blind auction. If you guessed too low, the transaction sat pending for hours.

With the algorithmic Base Fee:

Predictability: You know exactly what the minimum price is to get into the next block.

Efficiency: Wallets (like MetaMask) can automatically calculate the "correct" fee without you having to look at gas trackers constantly.

Ethereum-Solidity Quiz Q25: What is gas in Ethereum?

MihaiHng — Sun, 25 Jan 2026 18:44:24 +0000

Gas is the unit used to measure the amount of computational effort required to execute operations on the network.

1. Why does Gas exist?

Because every transaction must be processed by thousands of nodes globally, Gas serves two vital purposes:

Preventing Spam: It ensures that users can't clog the network with infinite loops or millions of useless transactions for free.

Resource Allocation: It compensates miners/validators for the electricity and hardware power they use to secure the network.

2. How the Price is Calculated

Calculation formula:

Total Fee = Gas Units * Gas Price Gas Price = (Base Fee + Priority Fee)

https://etherscan.io/gastracker

Gas Units: The "amount of work." A simple transfer usually costs 21,000 units, while complex smart contracts (like swapping on Uniswap) cost much more.
Base Fee: The minimum price per unit to get into a block (this is set by the network and is burned).
Priority Fee (Tip): An optional extra payment to validators to "skip the line" and get your transaction processed faster.

3. Gwei:

Gas prices are denoted in Gwei, which is a tiny fraction of 1 Ether.

1 Gwei = 0.000000001 ETH(10^-9ETH).

Ethereum-Solidity Quiz Q24: What is the role of "0x" prefix in data representations?

MihaiHng — Tue, 20 Jan 2026 12:36:33 +0000

In computer science and implicitly in Ethereum and Solidity, the 0x prefix serves the fundamental purpose of signifying that the following data is in hexadecimal (base-16).

Why is it used?

Without a prefix, many hexadecimal numbers would be
indistinguishable from decimal numbers.

Scenario: You see the number 80.
Problem: Is this "eighty" (decimal) or is it 8 * 16^1 + 0 = 128 (hexadecimal)?
Solution: By writing 0x80, the ambiguity is removed. The compiler immediately knows the base is 16.

In Ethereum and Solidity 0x is used for different types of data like addresses, opcodes, encoded data and hashes.

The Exception is hex Strings, where hex is a special keyword in Solidity for long strings of raw data. In this format, you do not use the 0x prefix inside the quotes.

Syntax: hex"..." or hex'...'

Ethereum-Solidity Quiz Q23: What is C3 Linearization in smart contract inheritance?

MihaiHng — Mon, 19 Jan 2026 11:19:42 +0000

C3 linearization is an algorithm that determines the order in which parent contracts are searched when a derived contract inherits from multiple parents. It's also called the Method Resolution Order (MRO).

It solves the Diamond Problem, where a contract inherits from two parents that both inherit from the same grandparent. Without C3, the compiler wouldn't know which version of a shared function to execute.

1. Fundamental Rule

The most important thing to remember for Solidity is the direction of inheritance - from "most base-like" to "most derived."

In the declaration contract Child is A, B, B is considered "more derived" than A. If both have the same function, the version in B will be checked first.

2. How the Search Order Works

When you call a function or use the super keyword, Solidity follows a flattened list generated by the C3 algorithm. The search follows these steps:

Start at the Child: Check if the function is defined in the current contract.

Move Right-to-Left: Check the parent contracts in the order they were listed, starting from the right-most one.

Go Up the Hierarchy: Move up to the grandparents only after all immediate parents have been checked.

Example: The "Diamond" Chain

contract A {
    function foo() public virtual { /* Logic A */ }
}

contract B is A {
    function foo() public virtual override { super.foo(); }
}

contract C is A {
    function foo() public virtual override { super.foo(); }
}

// Order: A (base) -> B -> C (most derived)
contract D is B, C {
    function foo() public override(B, C) {
        super.foo(); 
    }
}

The Linearization of D is: [D, C, B, A]

super.foo() in D calls C.
super.foo() in C calls B.
super.foo() in B calls A.

C3 linearization prevents contract A function being called twice.

Ethereum-Solidity Quiz Q22: How are functions overridden using the "super" keyword?

MihaiHng — Sat, 17 Jan 2026 16:13:38 +0000

In Solidity, the super keyword is used to access the immediate parent’s implementation of a function that has been overridden. Instead of completely replacing the parent's logic, super allows to extend it by adding to it.

Extending Logic Example:

When you override a function, the original version in the parent contract is hidden. Using super.functionName() brings that logic back into your execution flow.

contract Parent {
    uint public count;
    function increment() public virtual {
        count += 1;
    }
}

contract Child is Parent {
    function increment() public override {
        super.increment(); // Calls Parent.increment() first
        count *= 2;        // Then add custom logic (multiply by 2)
    }
}

Super vs. Direct Contract Calls

You can also call a parent directly by name (e.g., A.foo()), but there is a major difference:

super.foo()

Follows the entire inheritance chain.
Standard way to ensure all parent logic is executed only once.

A.foo()

Calls only the specific contract A.
Used when you want to bypass the inheritance order and trigger a specific parent.

Ethereum-Solidity Quiz Q21: How does function overriding work in Solidity?

MihaiHng — Fri, 16 Jan 2026 07:27:50 +0000

Function overriding in Solidity is the process by which a child contract provides a new implementation for a function already defined in its parent contract.

Since Solidity 0.6.0, this process is explicit and requires the use of two specific keywords(virtual & override) to prevent accidental overrides and improve code readability.

The Process

In the Parent Contract: Use the virtual keyword. This signals that the function is "open" for modification.
In the Child Contract: Use the override keyword. This signals that you are "intentionally" replacing the parent's logic.
Both virtual & override can be used in the same function in a multi level inheritance

Example:

contract Parent {
    // Marked virtual to allow overriding
    function message() public virtual pure returns (string memory) {
        return "Hello from Parent";
    }
}

contract Child is Parent {
    // Marked override to redefine logic
    // Marked virtual to allow overriding
    function message() public virtual override pure returns (string memory) {
        return "Hello from Child";
    }
}

contract Grandchild is Child {
    // Marked override to redefine logic
    function message() public override pure returns (string memory) {
        return "Hello from Grandchild";
    }
}

Constraints:

Visibility - Function visibility must be the same or more restrictive when overriding
State - State mutability can change to be more restrictive (but not less)
Interfaces - Functions in an interface are implicitly virtual. You only need the override keyword in the implementation.
Private - private functions cannot be virtual, so they can never be overridden.

Note:

Modifiers can also be overridden like functions, but starting with Solidity 0.9.0 release this will be deprecated.