Fork testing (mainnet fork) in Blockchain / Solidity - Time & Space Complexity

Time Complexity: Fork testing (mainnet fork)

O(n)

Understanding Time Complexity

When testing a mainnet fork, we want to know how the time to run tests changes as the number of transactions or blocks increases.

We ask: How does the testing time grow when we add more data from the mainnet?

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

const fork = await network.provider.request({
  method: 'hardhat_reset',
  params: [{
    forking: { jsonRpcUrl: MAINNET_URL, blockNumber: 15000000 }
  }]
});

for (const tx of transactions) {
  await network.provider.send('eth_sendRawTransaction', [tx]);
}
    

This code resets the blockchain state to a mainnet fork at a specific block, then replays a list of transactions on it.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Sending each transaction one by one to the forked network.
• How many times: Once for every transaction in the list.

How Execution Grows With Input

As the number of transactions increases, the time to replay them grows proportionally.

Input Size (n)	Approx. Operations
10	10 transaction sends
100	100 transaction sends
1000	1000 transaction sends

Pattern observation: Doubling the number of transactions roughly doubles the time needed.

Final Time Complexity

Time Complexity: O(n)

This means the testing time grows directly in proportion to the number of transactions replayed.

Common Mistake

[X] Wrong: "Replaying transactions on a fork is instant regardless of how many there are."

[OK] Correct: Each transaction must be processed one after another, so more transactions take more time.

Interview Connect

Understanding how replaying transactions scales helps you reason about testing and simulation speed in blockchain development.

Self-Check

What if we batch multiple transactions together instead of sending them one by one? How would the time complexity change?

Practice

1. What is the main purpose of creating a mainnet fork in blockchain development?

easy

A. To safely test code using real blockchain data without affecting the live network

B. To permanently change the main blockchain rules

C. To mine new blocks faster than the main network

D. To create a new cryptocurrency from scratch

Solution

1. Step 1: Understand what a mainnet fork is

   A mainnet fork is a copy of the live blockchain used for testing.

2. Step 2: Identify the purpose of testing on a fork

   It allows developers to try code changes safely without risking the real network.

3. Final Answer:

   To safely test code using real blockchain data without affecting the live network -> Option A

4. Quick Check:

   Fork testing = safe real-data testing [OK]

Hint: Mainnet fork = safe playground for real blockchain data [OK]

Common Mistakes:

• Thinking a fork changes the live blockchain
• Confusing fork with creating a new coin
• Assuming fork speeds up mining

2. Which of the following commands is commonly used to create a mainnet fork with Hardhat?

easy

A. npx hardhat node --fork https://mainnet.infura.io/v3/YOUR_API_KEY

B. npx hardhat compile --fork mainnet

C. npx hardhat deploy --network mainnet

D. npx hardhat test --fork mainnet

Solution

1. Step 1: Recall Hardhat command for forking

   The command to start a local node forked from mainnet includes node --fork with a mainnet RPC URL.

2. Step 2: Match the correct syntax

   npx hardhat node --fork https://mainnet.infura.io/v3/YOUR_API_KEY uses npx hardhat node --fork with a mainnet URL, which is correct.

3. Final Answer:

   npx hardhat node --fork https://mainnet.infura.io/v3/YOUR_API_KEY -> Option A

4. Quick Check:

   Fork command = hardhat node --fork [OK]

Hint: Fork with 'hardhat node --fork' plus mainnet URL [OK]

Common Mistakes:

• Using compile or deploy commands to fork
• Missing the --fork flag
• Not providing a mainnet RPC URL

3. Given this Hardhat script snippet for mainnet fork testing:

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

async function main() {
  const balance = await ethers.provider.getBalance("0x742d35Cc6634C0532925a3b844Bc454e4438f44e");
  console.log(ethers.utils.formatEther(balance));
}

main();

What will this script output when run on a mainnet fork?

medium

A. The balance of the address on a testnet like Ropsten

B. The Ether balance of the address on the live mainnet

C. An error because the address is invalid

D. Zero, because the fork has no data

Solution

1. Step 1: Understand mainnet fork data availability

   A mainnet fork copies the live blockchain state, including balances.

2. Step 2: Analyze the script's balance query

   The script queries the balance of a known mainnet address, so it returns the real Ether amount.

3. Final Answer:

   The Ether balance of the address on the live mainnet -> Option B

4. Quick Check:

   Fork has live data = real balance [OK]

Hint: Fork shows real mainnet balances, not zero or errors [OK]

Common Mistakes:

• Assuming fork has empty state
• Confusing mainnet fork with testnet
• Thinking address format is invalid

4. You tried to fork mainnet using Hardhat but got the error: Invalid JSON RPC response. What is the most likely cause?

medium

A. You ran the fork command without internet connection

B. Your Hardhat version does not support forking

C. The address you queried does not exist

D. You forgot to provide a valid mainnet RPC URL with an API key

Solution

1. Step 1: Understand the error context

   "Invalid JSON RPC response" usually means the node cannot connect to the RPC endpoint.

2. Step 2: Identify common causes

   Not providing a valid mainnet RPC URL or missing API key causes this error.

3. Final Answer:

   You forgot to provide a valid mainnet RPC URL with an API key -> Option D

4. Quick Check:

   Missing RPC URL/API key = JSON RPC error [OK]

Hint: Check RPC URL and API key first for JSON RPC errors [OK]

Common Mistakes:

• Blaming Hardhat version without checking URL
• Assuming address errors cause RPC failure
• Ignoring internet connectivity issues

5. You want to test a smart contract upgrade on a mainnet fork. Which sequence correctly describes the steps to do this safely?

hard

A. Fork mainnet, deploy new contract only, ignore old contract state

B. Deploy new contract on mainnet directly, then fork mainnet to test

C. Fork mainnet locally, deploy old contract, run upgrade scripts, test new contract behavior

D. Test upgrade only on testnet, no need to fork mainnet

Solution

1. Step 1: Fork mainnet and deploy old contract

   Start by creating a mainnet fork and deploying the current contract version to replicate live state.

2. Step 2: Run upgrade scripts and test new behavior

   Apply upgrade scripts on the fork and test the new contract to ensure correctness without risk.

3. Final Answer:

   Fork mainnet locally, deploy old contract, run upgrade scripts, test new contract behavior -> Option C

4. Quick Check:

   Fork + old contract + upgrade + test = safe upgrade [OK]

Hint: Fork, deploy old, upgrade, then test for safe contract upgrades [OK]

Common Mistakes:

• Deploying new contract directly on mainnet
• Ignoring old contract state in tests
• Skipping mainnet fork and testing only on testnet