Tasks

Chapter 56: Hands-on Task Scenarios

Overview

This chapter provides hands-on practice scenarios that are commonly given in blockchain infrastructure interviews. You’ll be asked to complete these tasks within time limits (typically 2-3 hours).

---

56.1 Task 1: Set Up Ethereum Node (Time: 2-3 hours)

Scenario

You have been given a server and asked to set up an Ethereum node that:

1. Fully syncs with the mainnet
2. Exposes RPC API for external applications
3. Is accessible via HTTP on port 8545

Step-by-Step Solution

Step 1: SSH into the Server

ssh user@your-server-ip

Step 2: Check System Resources

# Check CPU
nproc

# Check Memory
free -h

# Check Disk
df -h

# Check disk type (should be SSD)
lsblk -o NAME,TYPE,SIZE,MODEL

Step 3: Install Dependencies

# Update system
sudo apt-get update && sudo apt-get upgrade -y

# Install required packages
sudo apt-get install -y curl wget git build-essential

Step 4: Download and Install Geth

# Download latest Geth
cd /tmp
wget https://gethstore.blob.core.windows.net/builds/geth-linux-amd64-1.13.14-8ab7ff97.tar.gz

# Extract
tar -xzf geth-linux-amd64-1.13.14-8ab7ff97.tar.gz

# Install
sudo mv geth-linux-amd64-1.13.14-8ab7ff97/geth /usr/local/bin/

# Verify
geth version

Expected output:

Geth
Version: 1.13.14-8ab7ff97
...

Step 5: Create Data Directory

sudo mkdir -p /data/ethereum
sudo chown $USER:$USER /data/ethereum

Step 6: Start the Node with Snap Sync

# Run in screen or as service
geth \
  --syncmode snap \
  --http \
  --http.addr 0.0.0.0 \
  --http.port 8545 \
  --http.api eth,net,web3,debug,txpool \
  --http.corsdomain "*" \
  --datadir /data/ethereum \
  --port 30303 \
  --maxpeers 50

Step 7: Check Sync Progress (in a new terminal)

# Check if node is running
curl -X POST http://localhost:8545 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

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

Step 8: Verify Complete Sync

Wait for eth_syncing to return false. Then:

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

# Verify against block explorer
# Visit https://etherscan.io and compare block numbers

Expected Completion Time

• Initial sync: 2-4 hours for snap sync
• Full verification: 1-2 weeks for full sync

---

56.2 Task 2: Set Up RPC Node with Rate Limiting (Time: 1-2 hours)

Scenario

Set up a production-grade RPC node with:

1. Rate limiting enabled
2. Authentication
3. Load balancing ready

Solution

Step 1: Configure Geth

geth \
  --syncmode snap \
  --http \
  --http.addr 127.0.0.1 \
  --http.port 8545 \
  --http.api eth,net,web3,debug,txpool \
  --http.vhosts "localhost,yourdomain.com" \
  --rpc.batch-request-limit 1000 \
  --rpc.batch-response-max-size 25000000 \
  --ws \
  --ws.addr 127.0.0.1 \
  --ws.port 8546 \
  --ws.api eth,net,web3 \
  --datadir /data/ethereum \
  --metrics \
  --metrics.port 6060 \
  --pprof \
  --pprof.port 6061

⚠️ geth has no --http.ratelimit / --ws.ratelimit flags — per-client request rate limiting is done at the reverse proxy (Step 2 below). The --rpc.* flags above are the built-in batch caps.

Step 2: Set Up Nginx with Rate Limiting

sudo apt-get install nginx

sudo nano /etc/nginx/nginx.conf

Add rate limiting configuration:

http {
    limit_req_zone $binary_remote_addr zone=eth_rpc:10m rate=100r/s;
    limit_req_zone $binary_remote_addr zone=eth_call:10m rate=50r/s;

    server {
        listen 443 ssl http2;
        server_name rpc.yourdomain.com;

        ssl_certificate /etc/ssl/certs/your-cert.crt;
        ssl_certificate_key /etc/ssl/private/your-key.key;

        # Rate limiting
        limit_req zone=eth_rpc burst=200 nodelay;

        location / {
            proxy_pass http://127.0.0.1:8545;
            proxy_http_version 1.1;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

            # Timeouts
            proxy_connect_timeout 60s;
            proxy_send_timeout 60s;
            proxy_read_timeout 60s;
        }
    }
}

---

56.3 Task 3: Connect to Testnet and Get Test ETH (Time: 30 minutes)

Scenario

Set up a node on Sepolia testnet and get test ETH from a faucet.

Solution

# Start on Sepolia testnet
geth \
  --sepolia \
  --syncmode snap \
  --http \
  --http.port 8545 \
  --datadir /data/ethereum-sepolia

Get test ETH from faucet:

• https://sepoliafaucet.com
• https://faucet.sepolia.org

---

56.4 Task 4: Debug Sync Issues (Time: 30 minutes)

Scenario

Your node is stuck and not syncing. Diagnose and fix.

Solution

Check 1: Peer Connection

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

If 0 peers: Check network/firewall

Check 2: Network Version

# Check chain ID (should be 1 for mainnet)
curl -X POST http://localhost:8545 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'

Check 3: Logs

# Check Geth logs
journalctl -fu geth -n 100

# Or if running in terminal, check output

Check 4: Restart Fresh

# Stop node
systemctl stop geth

# Remove chaindata (keep keystore if needed)
rm -rf /data/ethereum/geth/chaindata

# Restart
systemctl start geth

---

56.5 Task 5: Set Up Monitoring (Time: 1 hour)

Scenario

Add Prometheus metrics and Grafana dashboard to monitor your node.

Solution

Enable Geth Metrics

geth \
  --syncmode snap \
  --http \
  --http.port 8545 \
  --metrics \
  --metrics.addr 0.0.0.0 \
  --metrics.port 6060 \
  --datadir /data/ethereum

Set Up Prometheus

# Install Prometheus
sudo apt-get install prometheus

# Configure prometheus.yml
cat > /etc/prometheus/prometheus.yml << 'EOF'
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'geth'
    metrics_path: /debug/metrics/prometheus   # ← required for geth, not /metrics
    static_configs:
      - targets: ['localhost:6060']
EOF

# Restart Prometheus
sudo systemctl restart prometheus

Import Grafana Dashboard

1. Install Grafana
2. Add Prometheus as data source
3. Import dashboard ID: 14611 (Ethereum)

---

56.6 Task 6: Set Up Cosmovisor for Auto-Upgrades (Time: 30 minutes)

Scenario

Set up Cosmovisor for automatic node upgrades.

Solution

# Install Cosmovisor
cd /tmp
wget https://github.com/cosmos/cosmovisor/releases/download/v1.5.0/cosmovisor-v1.5.0-linux-amd64.tar.gz
tar -xzf cosmovisor-v1.5.0-linux-amd64.tar.gz
sudo mv cosmovisor /usr/local/bin/

# Create directories
mkdir -p ~/.govmdd/cosmovisor/genesis/bin
mkdir -p ~/.govmdd/cosmovisor/upgrades/

# Move current binary to genesis
sudo mv $(which gaiad) ~/.govmdd/cosmovisor/genesis/bin/

# Create systemd service
cat > /etc/systemd/system/cosmovisor.service << 'EOF'
[Unit]
Description=Cosmovisor
After=network.target

[Service]
User=ubuntu
ExecStart=/usr/local/bin/cosmovisor run start
Environment="DAEMON_HOME=/home/ubuntu/.govmdd"
Environment="DAEMON_NAME=gaiad"
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable cosmovisor
sudo systemctl start cosmovisor

---

56.7 Task 7: Harden a Cosmos Validator With Sentry Nodes (Time: 1 hour)

Scenario

You run a Cosmos (CometBFT) validator. Attackers have been DDoS-ing validators to cause missed blocks. Harden your setup so the validator’s IP is never exposed to the public internet (see Chapter 3.8 for the concept).

Architecture

                PUBLIC INTERNET
                      │
        ┌─────────────┴─────────────┐
        │                           │
   ┌────▼────┐                ┌────▼────┐
   │ Sentry  │◀──inbound──▶   │ Sentry  │    2+ sentry full nodes
   │  node 1 │                │  node 2 │    (public P2P:26656)
   └────┬────┘                └────┬────┘
        │  outbound only           │  outbound only
        └────────────┬─────────────┘
                     ▼
              ┌────────────┐
              │  Validator │    NO inbound connections;
              │ (firewalled│    connects outbound to sentries
              │  P2P:26656)│
              └────────────┘

Solution

# 1. On the SENTRIES: set node IDs and enable P2P exchange normally
#    (sentries peer with the rest of the network; they stay public)
gaiad tendermint show-node-id          # record the sentry node IDs

# 2. On the VALIDATOR: config.toml — connect ONLY to your sentries,
#    disable peer exchange (pex) and never gossip the validator's own ID:
#    ~/.gaiad/config/config.toml  →  [p2p] section
#      pex = false                      # don't learn/advertise new peers
#      persistent_peers = "sentry1-id@sentry1-host:26656,sentry2-id@sentry2-host:26656"
#      private_peer_ids = "sentry1-id,sentry2-id"   # never gossip their IDs
#      unconditional_peer_ids = "sentry1-id,sentry2-id"

# 3. On the SENTRIES: config.toml knows the validator but never spreads its ID
#    [p2p]
#      pex = true
#      private_peer_ids = "validator-id"   # keep validator ID private
#      persistent_peers = "validator-id@validator-private-ip:26656"

# 4. Firewall the validator: deny inbound 26656 entirely
sudo ufw default deny incoming
sudo ufw allow out 26656/tcp
# (allow outbound P2P; allow RPC 26657 only from your ops IP)

# 5. Restart both sides and verify the validator accepts NO inbound peers
sudo systemctl restart gaiad
ss -tn state established '( sport = :26656 )' | wc -l     # 0 inbound expected

Expected Outcome

• The validator’s public IP is absent from all P2P address books (pex=false).
• A DDoS on the sentries does not cut the validator off — it reconnects to the surviving sentry.
• gaiad status | jq .SyncInfo.latest_block_height keeps advancing and the validator keeps producing blocks.

---

56.8 Quick Command Reference

Common Commands During Interview Tasks

# Check if Geth is running
ps aux | grep geth

# Check logs
journalctl -fu geth
tail -f /var/log/geth.log

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

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

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

# Get account balance
curl -X POST http://localhost:8545 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x...", "latest"],"id":1}'

# Stop node gracefully
sudo systemctl stop geth

# Restart node
sudo systemctl restart geth

Common Interview Task Checklist

[ ] SSH into server
[ ] Check system resources (CPU, RAM, Storage)
[ ] Install Geth or other client
[ ] Create data directory
[ ] Start node with appropriate flags
[ ] Verify sync is progressing
[ ] Wait for full sync (or show progress)
[ ] Test RPC endpoints
[ ] Demonstrate common queries
[ ] Clean up / answer questions

---

Summary

These hands-on tasks simulate real interview scenarios:

1. Set up Ethereum node - Most common task
2. Configure RPC with security - Production focus
3. Testnet setup - Basic verification
4. Debug sync issues - Troubleshooting skills
5. Add monitoring - DevOps skills
6. Cosmos setup - If Cosmos is the focus
7. Sentry hardening - Validator security (Harden a Cosmos Validator With Sentry Nodes)

Practice these tasks to be ready for your interview!

---

Next Chapter

In Chapter 57: Quick Reference Cheat Sheet, you’ll find a printable quick reference.

---

Last Updated: 2026-10-07