Why Ethereum networks (mainnet, testnet) in Blockchain / Solidity? - Purpose & Use Cases

The Big Idea

What if you could test your Ethereum app without risking a single cent?

The Scenario

Imagine you want to build a new app that uses Ethereum, but every time you test your code, you risk losing real money or breaking something important on the live network.

The Problem

Testing directly on the live Ethereum network (mainnet) is risky and expensive. Mistakes can cost real money, and debugging is slow because transactions take time and fees. Without a safe place to try things out, development becomes stressful and error-prone.

The Solution

Ethereum test networks (testnets) provide a safe playground that mimics the main network but uses fake money. This lets developers test and fix their apps without any real cost or risk, speeding up development and making it safer.

Before vs After

✗ Before

// Send real ETH on mainnet to test a contract
// Risk losing money if contract has bugs

✓ After

// Deploy and test contract on testnet
// Use free test ETH, no real money lost

What It Enables

It enables safe, cost-free experimentation and debugging before launching on the real Ethereum network.

Real Life Example

A developer builds a new decentralized game and tests all features on a testnet to avoid losing players' real funds or causing errors on the main Ethereum network.

Key Takeaways

Mainnet is the real Ethereum network with real value.

Testnets are safe, fake-value networks for testing.

Using testnets prevents costly mistakes and speeds up development.

Practice

1. Which Ethereum network should you use to test your smart contracts without risking real money?

easy

A. Private network

B. Mainnet

C. Testnet

D. Production network

Solution

1. Step 1: Understand the purpose of testnets

   Testnets are designed for testing and development without real value at risk.

2. Step 2: Compare with mainnet

   Mainnet is the live network where real transactions and value exist, so testing there risks real money.

3. Final Answer:

   Testnet -> Option C

4. Quick Check:

   Testnet = Safe testing network [OK]

Hint: Testnets are for safe practice, mainnet is for real use [OK]

Common Mistakes:

• Confusing mainnet with testnet
• Thinking private network is the default test environment
• Assuming production network is safe for testing

2. Which of the following is the correct way to specify the Ethereum mainnet network ID in your configuration?

easy

A. "networkId": 1

B. "networkId": 3

C. "networkId": 42

D. "networkId": 4

Solution

1. Step 1: Recall Ethereum network IDs

   Mainnet uses network ID 1, testnets have other IDs like 3 (Ropsten), 4 (Rinkeby), 42 (Kovan).

2. Step 2: Match the ID to mainnet

   Network ID 1 corresponds to the Ethereum mainnet.

3. Final Answer:

   "networkId": 1 -> Option A

4. Quick Check:

   Mainnet networkId = 1 [OK]

Hint: Mainnet always uses network ID 1 [OK]

Common Mistakes:

• Using testnet IDs for mainnet
• Confusing networkId with chainId
• Assuming networkId 0 is valid

3. Given the following code snippet to connect to an Ethereum network, what network will it connect to?

const provider = new ethers.providers.JsonRpcProvider("https://rinkeby.infura.io/v3/YOUR_PROJECT_ID");
const network = await provider.getNetwork();
console.log(network.name);

medium

A. "mainnet"

B. "rinkeby"

C. "ropsten"

D. "kovan"

Solution

1. Step 1: Identify the RPC URL

   The URL contains "rinkeby.infura.io", indicating the Rinkeby testnet.

2. Step 2: Understand provider.getNetwork()

   This method returns the network info based on the RPC URL, so it will return "rinkeby".

3. Final Answer:

   "rinkeby" -> Option B

4. Quick Check:

   RPC URL domain = rinkeby [OK]

Hint: Check the RPC URL domain for network name [OK]

Common Mistakes:

• Assuming default is mainnet
• Confusing testnet names
• Ignoring the URL and guessing

4. You wrote this code to deploy a contract on Ropsten testnet but get an error:

const provider = new ethers.providers.JsonRpcProvider("https://mainnet.infura.io/v3/YOUR_PROJECT_ID");
const signer = provider.getSigner();
// deploy contract code here

What is the main issue?

medium

A. Incorrect contract deployment syntax

B. Provider does not support getSigner()

C. Using mainnet RPC URL instead of Ropsten testnet URL

D. Missing private key for signer

Solution

1. Step 1: Examine the signer line

   JsonRpcProvider.getSigner() fails because public RPC providers like Infura do not expose signing accounts or private keys.

2. Step 2: Correct approach for deployment

   Create a wallet signer: const wallet = new ethers.Wallet('0x-your-private-key', provider); const signer = wallet.connect(provider);

3. Final Answer:

   Missing private key for signer -> Option D

4. Quick Check:

   Use Wallet(privateKey, provider) for signing [OK]

Hint: Use ethers.Wallet(privateKey, provider) for signing deployments [OK]

Common Mistakes:

• Using provider.getSigner() without wallet
• Assuming getSigner() works without wallet
• Overlooking private key requirement

5. You want to write a script that deploys a smart contract first on the Goerli testnet and then on the mainnet only if tests pass. Which approach correctly handles this?

hard

A. Deploy on Goerli testnet, run tests, then deploy on mainnet if tests pass

B. Deploy on mainnet first, then test on Goerli

C. Deploy simultaneously on both networks

D. Deploy only on mainnet and skip testnet

Solution

1. Step 1: Understand deployment best practices

   Testnets like Goerli are used to test contracts safely before mainnet deployment.

2. Step 2: Apply conditional deployment logic

   Deploy on Goerli, run tests, and only deploy on mainnet if tests succeed to avoid costly errors.

3. Final Answer:

   Deploy on Goerli testnet, run tests, then deploy on mainnet if tests pass -> Option A

4. Quick Check:

   Test on testnet before mainnet deployment [OK]

Hint: Test on Goerli first, then deploy mainnet if tests pass [OK]

Common Mistakes:

• Deploying on mainnet before testing
• Skipping testnets entirely
• Deploying on both networks at once