Questions

Chapter 55: Common Interview Questions

Overview

This chapter covers the most common interview questions related to blockchain nodes. These questions are based on real interview experiences and will help you prepare for node operator, blockchain engineer, and DevOps positions.

55.1 Basic Blockchain Questions

Q1: What is a blockchain node?

Answer: A blockchain node is a computer or server that runs blockchain software, connects to other nodes in a peer-to-peer network, stores a copy of the blockchain, validates transactions and blocks, and participates in the consensus mechanism.

Q2: What is the difference between a full node and a light node?

Answer:

Feature	Full Node	Light Node
Data Storage	Complete blockchain (~1.2TB for Ethereum)	Only block headers (~1GB)
Initial Sync	Days to weeks	Minutes
Security	Full verification	Limited verification
Functionality	Complete (query any data)	Limited (needs proofs)
Use Case	Validators, RPC services	Mobile wallets

Q3: What are the main components of a blockchain node?

Answer:

P2P Network Layer - Handles communication with other nodes
Transaction Pool (Mempool) - Holds pending transactions
Block Validator - Validates incoming blocks
State Database - Stores account balances and contract state
Virtual Machine (EVM) - Executes smart contracts
RPC API - Exposes interfaces for external applications

Q4: What is consensus in blockchain?

Answer: Consensus is the process by which network nodes agree on the current state of the blockchain. It ensures all honest nodes have the same copy of the distributed ledger. Common mechanisms include:

Proof of Work (PoW) - Miners solve puzzles
Proof of Stake (PoS) - Validators stake tokens
Delegated PoS (DPoS) - Elected validators
PBFT/Tendermint - Byzantine fault tolerance

Q5: What is the difference between PoW and PoS?

Answer:

Aspect	Proof of Work	Proof of Stake
Mechanism	Solve mathematical puzzles	Stake cryptocurrency
Energy	Very high	Low (99% less)
Hardware	Specialized ASICs	Standard servers
Block Proposers	Miners	Validators (randomly selected)
Security	51% attack expensive	51% attack requires 51% staked tokens
Example	Bitcoin	Ethereum

55.2 Ethereum-Specific Questions

Q6: What is The Merge in Ethereum?

Answer: The Merge (September 2022) was Ethereum’s transition from Proof of Work to Proof of Stake. It merged the original execution layer with the new Beacon Chain (consensus layer). After The Merge:

Energy consumption reduced by ~99%
No more mining
Validators now produce blocks
Changed from 12-14s to consistent 12s block time

Q7: What are execution clients and consensus clients in Ethereum?

Answer: After The Merge, Ethereum uses dual-client architecture:

Execution Client (EL): Handles transactions, EVM execution, state management
- Examples: Geth, Erigon, Nethermind, Besu
Consensus Client (CL): Handles Proof of Stake, Beacon Chain, validation
- Examples: Lighthouse, Prysm, Teku, Nimbus

They communicate via Engine API using JWT authentication.

Q8: What is Geth in Ethereum?

Answer: Geth (Go Ethereum) is the most popular Ethereum client, written in Go. It’s:

The official Go implementation
Used by majority of nodes on mainnet
Supports full and snap sync modes (--syncmode light was removed in v1.13)
Provides JSON-RPC API for interactions

Q9: What are the different sync modes in Geth?

Answer:

Mode	Description	Time	Storage
Full	Verifies every block and transaction	Weeks	~1.2TB
Snap (default)	Downloads state snapshot, then catches up	Hours	~1.2TB
Light access	Headers only — but geth removed `--syncmode light` (v1.13); use Helios/Lodestar light clients	Minutes	~1GB

Recommendation: Use --syncmode snap for production RPC nodes.

Q10: How do you check if an Ethereum node is synced?

Answer:

# Using Geth console
geth attach http://localhost:8545
eth.syncing

# Returns:
# {
#   currentBlock: 18500000,
#   highestBlock: 18501234,
#   knownStates: 50000000,
#   pulledStates: 48000000
# }
# When synced, returns: false

Or using JSON-RPC:

curl -X POST http://localhost:8545 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}'

Q11: What is gas in Ethereum?

Answer: Gas is the unit of computation on Ethereum. Each operation (transaction, smart contract execution) requires a specific amount of gas.

Gas Limit: Maximum gas you’re willing to spend
Gas Used: Actual gas consumed
Gas Price: Price per unit (in Gwei)
Transaction Fee = Gas Used × Gas Price

After EIP-1559:

Base Fee: Burned by network (dynamic)
Priority Fee: Goes to validator (tip)

Q12: What is the difference between Geth and Erigon?

Answer:

Feature	Geth	Erigon
Developer	Ethereum Foundation	Erigon Team
Sync Speed	Slower (weeks)	Faster (days)
Storage	~1.2TB	~900GB
Database	LevelDB	MDBX
API	Standard	Extended (Erigon-specific)

Erigon is faster and more storage-efficient but API-compatible with Geth.

55.3 Node Operations Questions

Q13: How would you set up an Ethereum node from scratch?

Answer:

# 1. Install Geth
wget https://gethstore.blob.core.windows.net/builds/geth-linux-amd64-1.13.14.tar.gz
tar -xzf geth-linux-amd64-1.13.14.tar.gz
sudo mv geth /usr/local/bin/

# 2. Start node with snap sync (recommended)
geth \
  --syncmode snap \
  --http \
  --http.addr 127.0.0.1 \
  --http.port 8545 \
  --http.api eth,net,web3 \
  --datadir /data/ethereum

# 3. Monitor sync status
curl -X POST http://localhost:8545 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}'

# 4. Check block number to verify sync
curl -X POST http://localhost:8545 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

Q14: What are the hardware requirements for running an Ethereum node?

Answer:

Component	Minimum	Recommended
CPU	4 cores	8+ cores
RAM	8 GB	16-32 GB
Storage	1 TB SSD	2 TB NVMe SSD
Network	25 Mbps	100 Mbps

For archive nodes (storing all historical state):

Storage: 10-12 TB
RAM: 32-64 GB

Q15: What is an RPC node?

Answer: An RPC node is a full node that exposes APIs (JSON-RPC, WebSocket) for external applications to interact with the blockchain. It’s used by:

Decentralized applications (dApps)
Wallets
Block explorers
Trading bots
Analytics tools

Q16: What is the mempool?

Answer: The mempool (Memory Pool) is where pending transactions wait before being included in a block. It:

Stores unconfirmed transactions
Holds transactions from all users
Transactions are ordered by gas price
Cleared when included in a block or expired

Q17: How do you secure a blockchain node?

Answer:

Network Security:
- Don’t expose RPC to public (bind to localhost)
- Use firewall rules
- Enable TLS/SSL
Key Management:
- Never expose private keys on RPC nodes
- Use hardware wallets for validators
Access Control:
- Implement rate limiting
- Use API keys if needed
- Restrict CORS domains
System Security:
- Run as non-root user
- Keep software updated
- Use monitoring and alerts

Q18: What is slashing in Proof of Stake?

Answer: Slashing is a penalty for validator misbehavior that results in loss of staked tokens. Common slashing conditions:

Double signing: Signing two different blocks at same height
Double voting: Attesting to two conflicting blocks
Surround voting: Creating conflicting attestations

Slashing protects network integrity by making malicious behavior expensive.

Q19: What is a bootnode?

Answer: A bootnode is a well-known node that helps new nodes discover peers on the network. When starting a new node, it connects to bootnodes to get a list of active peers.

Ethereum mainnet bootnodes:

enr:-KO4QA...@bootnode.mainnet.ethdisco.net:30303

Q20: What is the difference between a validator and a full node?

Answer:

Aspect	Full Node	Validator
Consensus	Validates blocks	Proposes & validates blocks
Block Production	No	Yes
Stake Required	No	Yes (32 ETH for Ethereum)
Slashing Risk	No	Yes
Can Query Data	Yes	Yes

55.4 Troubleshooting Questions

Q21: What would you do if your node won’t sync?

Answer:

Check network connectivity:

curl -X POST http://localhost:8545 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":1}'

Check sync status:
Terminal window
```
eth.syncing
```
Check logs:
Terminal window
```
journalctl -fu geth -n 100
```

Verify correct network:

curl -X POST http://localhost:8545 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'

Restart with fresh database (last resort):

rm -rf /data/ethereum/geth/chaindata
systemctl restart geth

Q22: Node is synced but not receiving transactions - what could be wrong?

Answer:

Check if you’re connected to peers: net_peerCount
Check mempool: txpool.content
Verify transactions are reaching the network
Check if your node is properly connected to the P2P network

55.5 Advanced Questions

Q23: What is state pruning?

Answer: State pruning removes unnecessary historical state data while keeping blockchain integrity. Types:

Pruned node: Only keeps recent state (1.2TB)
Archive node: Keeps all historical states (12TB)

Geth flags (⚠️ --pruneancientstore does not exist — the real retention flags are):

--history.state 90000        # Keep last 90k state layers
--history.transactions 90000 # Keep receipts/index for the last 90k blocks

(Note: there is no --history.receipts flag — receipts retention follows --history.transactions.)

Q24: How does Ethereum’s snap sync work?

Answer: Snap sync:

Downloads the most recent state snapshot from peers
Downloads blocks from that point to current head
Verifies state by executing transactions
Once synced, operates like a full node

It provides the same result as full sync but is much faster (hours vs weeks).

Q25: What is the Engine API?

Answer: The Engine API is the communication interface between execution clients (Geth, Erigon) and consensus clients (Lighthouse, Prysm) after The Merge. It uses:

JSON-RPC over HTTP
JWT authentication
Methods like engine_forkchoiceUpdatedV3, engine_newPayloadV3, engine_getPayloadV3 (V2 was pre-Dencun; always match the version to the fork)
The EL/CL are connected over localhost:8551 (authenticated), separate from the public RPC port 8545

55.6 Node Lifecycle & Chain Mechanics Questions

New-format questions covering the material added in Chapters 3-4 and 6.8.

Q26. Walk me through the full lifecycle of a transaction, from submission to finality.

What it is: The end-to-end path of a transaction on Ethereum (see Chapter 6.8): submission via eth_sendRawTransaction → validation (signature, nonce, balance, gas) → mempool (txpool_pending/txpool_queued) → P2P gossip → block proposal (CL selects the proposer; EL builds and executes the payload via the Engine API) → EVM execution + receipts → new state root committed in the header → block broadcast and import by all nodes → Casper FFG finality after ~2 epochs (~12.8 min).

Why it is used: Interviewers ask this to test whether you understand the whole stack — mempool, P2P, consensus selection, EVM execution, state trie, and finality — as one connected system rather than isolated facts.

Interview talking point: “I like to say a tx is included when it’s in a proposed block, executed when the EVM runs it, canonical once the network imports the block (still reorgable), and final after two epochs of attestations. If a tx is stuck, I check the mempool first, then gas/nonce, then whether my node is synced.” Mention that Bitcoin (probabilistic confirmations), Cosmos (instant commit at 2/3+ precommits), and Solana (leader schedule + slots) differ — see the comparison table in 6.8.

Q27. What is the node lifecycle, from provisioning to decommissioning?

What it is: The operational stages of a node (covered in Chapter 4.5): provisioning (hardware sizing, OS, firewall) → install + initialize (client binary, genesis/data dir) → join the network (peers, bootnodes, sync) → operate (monitoring, logs, alerting, upgrades, backups) → incident handling (ch45-48) → and finally decommissioning (stop, back up validator keys, wipe data securely, deallocate).

Why it is used: Ops/DevOps interviews filter for people who plan beyond the install command — how upgrades roll back, where backups live, and what happens on decommission.

Interview talking point: “Before any upgrade I take a backup and note the exact current version so I can roll back; monitoring stays up during the upgrade (it’s the only way to tell a bad deploy from a slow one). On decommission I remove the node from peer/validator sets, back up keys, then purge and secure-erase the disk.” For validators, add: never skip the key backup — keys are the costliest asset on the box.

Q28. What is a sentry node, and why would you run one?

What it is: A sentry setup (Chapter 3.8) isolates your validator from the public internet: one or more full nodes (“sentries”) sit in front of the validator, which only makes outbound connections to its sentries. The sentries handle incoming peer connections, serving the validator’s blocks and attestations to the network while hiding the validator’s IP address.

Why it is used: To protect validators from DDoS: if an attacker discovers a validator’s IP they can isolate it from the network and cause missed blocks/attestations (which costs money). With sentries, an attack hits the sentries, which are disposable.

Interview talking point: “The key design rule is the validator connects outbound-only to the sentries — it never advertises its own IP. Sentries run in separate infrastructure; if one is DDoSed the validator reconnects to the next. This pattern is standard in Cosmos validator operations and common for Ethereum validators that don’t want to run public infrastructure.” Security becomes about the key material + the outbound link, not raw network hardening.

Q29. What is finality, and why do reorgs happen?

What it is: Finality is the point at which a block can no longer be removed from the canonical chain (ch43). It is defined differently per protocol: Ethereum PoS finalizes via Casper FFG after two epochs of attestations (an economic finality); Bitcoin is probabilistic (confirmations); CometBFT/Cosmos finalizes a block at commit time (2/3+ precommits); Solana finalizes on an optimistic-slot + confirmation schedule; Polkadot finalizes in GRANDPA batches. A reorg is an alternative chain replacing the tip — causes include competing blocks (propagation races), equivocating proposers, and (pre-finality) network partitions.

Why it is used: Finality directly determines confirmation policy for exchanges and bridges — trusting a non-final Ethereum block or one zero-confirmation Bitcoin tx is how money is lost.

Interview talking point: “The 12s Ethereum block time does not mean 12s finality — a block is only ‘safe’ once two epochs of attestations accumulate (~12.8 min). I monitor chain_head_reorg and design alerts around the finalized head, not the tip. In Cosmos it’s the opposite: commit is final unless a machine catches an equivocation, so reorgs there are rare and short.” Knowing which protocol has instant vs probabilistic vs economic finality is a classic trap.

Quick Reference Cheat Sheet

Essential Commands

# Check sync status
eth.syncing

# Check peer count
net_peerCount

# Get latest block
eth_blockNumber

# Get balance
eth_getBalance("address", "latest")

# Send transaction
eth_sendRawTransaction("0x...")

# Check chain ID
eth_chainId

Key Ports

Service	Port
P2P (Geth)	30303
HTTP RPC	8545
WebSocket	8546
Metrics	6060
pprof	6061

Summary

These questions cover the most important topics for blockchain node interviews:

Blockchain fundamentals
Ethereum architecture and The Merge
Geth/Ethereum client operations
Sync modes and troubleshooting
Security best practices
RPC and API concepts
Node lifecycle, sentry setups, tx→block flow, and finality/reorgs (Q26-Q29)

Practice these questions and you’ll be well-prepared for your interview!

Next Chapter

In Chapter 56: Hands-on Task Scenarios, we’ll practice common hands-on tasks.

Last Updated: 2026-10-07