Sync_modes
Chapter 12: Node Synchronization Modes
Section titled “Chapter 12: Node Synchronization Modes”Overview
Section titled “Overview”Understanding node synchronization modes is critical for any blockchain infrastructure engineer. When you’re asked to set up a node and make it “fully sync,” you need to understand which sync mode to use and how it works.
12.1 What is Synchronization?
Section titled “12.1 What is Synchronization?”When you start a new node, it needs to download and verify the entire blockchain history. This process is called synchronization.
┌─────────────────────────────────────────────────────────────────────────────┐│ BLOCKCHAIN SYNCHRONIZATION │├─────────────────────────────────────────────────────────────────────────────┤│ ││ New Node Starts ││ │ ││ ▼ ││ ┌─────────────────────────────────────────────────────────────────┐ ││ │ SYNCHRONIZATION PHASES │ ││ │ │ ││ │ 1. Connect to Network │ ││ │ - Discover peers via bootnodes │ ││ │ - Establish P2P connections │ ││ │ │ ││ │ 2. Download Headers │ ││ │ - Block headers (lightweight verification) │ ││ │ - Verify chain structure │ ││ │ │ ││ │ 3. Download Bodies │ ││ │ - Full block data (transactions) │ ││ │ │ ││ │ 4. Verify State │ ││ │ - Execute transactions │ ││ │ - Build state database │ ││ │ │ ││ │ 5. Reach Head │ ││ │ - Synced with network │ ││ │ │ ││ └─────────────────────────────────────────────────────────────────┘ ││ │└─────────────────────────────────────────────────────────────────────────────┘12.2 Ethereum Sync Modes
Section titled “12.2 Ethereum Sync Modes”Comparison Overview
Section titled “Comparison Overview”┌─────────────────────────────────────────────────────────────────────────────┐│ ETHEREUM SYNC MODES │├─────────────────────────────────────────────────────────────────────────────┤│ ││ ┌───────────────────────────────────────────────────────────────────┐ ││ │ │ ││ │ FULL SYNC │ ││ │ ┌─────────────────────────────────────────────────────────┐ │ ││ │ │ - Downloads and verifies EVERY block │ │ ││ │ │ - Executes all transactions │ │ ││ │ │ - Most secure (full verification) │ │ ││ │ │ - Slowest initial sync (1-2 weeks) │ │ ││ │ │ - Storage: ~1.2 TB │ │ ││ │ └─────────────────────────────────────────────────────────┘ │ ││ │ │ ││ └───────────────────────────────────────────────────────────────────┘ ││ ││ ┌───────────────────────────────────────────────────────────────────┐ ││ │ │ ││ │ SNAP SYNC (DEFAULT - RECOMMENDED) │ ││ │ ┌─────────────────────────────────────────────────────────┐ │ ││ │ │ - Downloads latest state snapshot │ │ ││ │ │ - Builds historical data from there │ │ ││ │ │ - Fastest sync (hours instead of weeks) │ │ ││ │ │ - Same end result as full sync │ │ ││ │ │ - Storage: ~1.2 TB │ │ ││ │ └─────────────────────────────────────────────────────────┘ │ ││ │ │ ││ └───────────────────────────────────────────────────────────────────┘ ││ ││ ┌───────────────────────────────────────────────────────────────────┐ ││ │ │ ││ │ LIGHT CLIENT (not geth) │ ││ │ ┌─────────────────────────────────────────────────────────┐ │ ││ │ │ - Only downloads block headers │ │ ││ │ │ - Verifies via beacon sync committees (Ethereum) │ │ ││ │ │ - Fastest sync (minutes) │ │ ││ │ │ - Limited: cannot query historical state │ │ ││ │ │ - Storage: ~1 GB │ │ ││ │ │ - Geth removed --syncmode light in v1.13 (2023) │ │ ││ │ └─────────────────────────────────────────────────────────┘ │ ││ │ │ ││ └───────────────────────────────────────────────────────────────────┘ ││ │└─────────────────────────────────────────────────────────────────────────────┘12.3 Full Sync
Section titled “12.3 Full Sync”How Full Sync Works
Section titled “How Full Sync Works”┌─────────────────────────────────────────────────────────────────┐│ FULL SYNC PROCESS │├─────────────────────────────────────────────────────────────────┤│ ││ Step 1: Connect to Network ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Node → Bootnode → Get Peer List → Connect to Peers │ ││ └─────────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ Step 2: Download Headers (Genesis → Current) ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Block 0 → Block 1 → Block 2 → ... → Block N │ ││ │ (Verify proof-of-work/validators per header) │ ││ └─────────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ Step 3: Download Block Bodies ││ ┌─────────────────────────────────────────────────────────┐ ││ │ For each block: │ ││ │ - Get transactions │ ││ │ - Get uncle hashes │ ││ └─────────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ Step 4: Execute Transactions ││ ┌─────────────────────────────────────────────────────────┐ ││ │ For each transaction: │ ││ │ - Validate signature │ ││ │ - Update state trie │ ││ │ - Verify state root │ ││ └─────────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ Step 5: Build State Database ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Final state: accounts, balances, contract storage │ ││ └─────────────────────────────────────────────────────────┘ ││ ││ Time: Days to Weeks ││ Storage: ~1.2 TB ││ │└─────────────────────────────────────────────────────────────────┘Running Full Sync
Section titled “Running Full Sync”# Geth - Full Syncgeth --syncmode full
# Erigon - Full Syncerigon --syncmode fullWhen to Use Full Sync
Section titled “When to Use Full Sync”- ✅ Maximum security required
- ✅ Validator/authority node
- ✅ When you don’t trust snapshot data
- ❌ Not recommended for quick setup
12.4 Snap Sync (Fast Sync)
Section titled “12.4 Snap Sync (Fast Sync)”How Snap Sync Works
Section titled “How Snap Sync Works”Snap sync is the default and recommended mode for most use cases.
┌─────────────────────────────────────────────────────────────────┐│ SNAP SYNC PROCESS │├─────────────────────────────────────────────────────────────────┤│ ││ Step 1: Initial Connection ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Connect to network, find recent peers │ ││ └─────────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ Step 2: Download State Snapshots ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Recent state: │ ││ │ - Account balances │ ││ │ - Contract code │ ││ │ - Storage slots │ ││ │ │ ││ │ Downloaded from multiple peers in parallel! │ ││ └─────────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ Step 3: Download Recent Blocks ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Download blocks from snapshot state to chain head │ ││ │ - Execute transactions │ ││ │ - Verify state changes │ ││ └─────────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ Step 4: Continue Normal Sync ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Once caught up, continues like full node: │ ││ │ - Validates new blocks normally │ ││ └─────────────────────────────────────────────────────────┘ ││ ││ Time: Hours (vs Weeks for full) ││ Result: Identical to full sync ││ │└─────────────────────────────────────────────────────────────────┘Running Snap Sync
Section titled “Running Snap Sync”# Geth - Snap Sync (default)geth --syncmode snap
# Or just don't specify (snap is default in recent versions)geth
# Erigon - Snap Syncerigon --syncmode snapSnap Sync Process Flow
Section titled “Snap Sync Process Flow”┌─────────────────────────────────────────────────────────────────────────────┐│ SNAP SYNC VISUALIZATION │├─────────────────────────────────────────────────────────────────────────────┤│ ││ Current Head: Block #19,000,000 ││ ││ ┌──────────────────────────────────────────────────────────────────────┐ ││ │ SNAPSHOT STATE (Block #18,950,000) │ ││ │ - Complete account state │ ││ │ - Complete contract storage │ ││ │ - Downloaded in chunks from multiple peers │ ││ └────────────────────────────────┬───────────────────────────────────────┘ ││ │ ││ ▼ ││ ┌──────────────────────────────────────────────────────────────────────┐ ││ │ CATCH-UP PHASE │ ││ │ Block #18,950,000 → Block #18,960,000 → ... → Block #19,000,000 │ ││ │ Execute all transactions, verify state │ ││ └────────────────────────────────┬───────────────────────────────────────┘ ││ │ ││ ▼ ││ ┌──────────────────────────────────────────────────────────────────────┐ ││ │ SYNCD! NOW AT HEAD │ ││ │ Normal block validation begins │ ││ └──────────────────────────────────────────────────────────────────────┘ ││ │└─────────────────────────────────────────────────────────────────────────────┘12.5 Light Sync (Status: Removed from Geth)
Section titled “12.5 Light Sync (Status: Removed from Geth)”How Light Clients Work
Section titled “How Light Clients Work”Light clients only download block headers and verify chain validity — they do not run a full node.
# ⚠️ Geth removed --syncmode light in v1.13 (2023):# Remove this flag from any old geth systemd units — the client will refuse to start.# Erigon never supported light mode.
# Modern Ethereum light access uses dedicated light clients (Helios, Lodestar light-client,# nimbus-eth1) which verify the chain via beacon-chain sync committees + RPC.Light Client Limitations
Section titled “Light Client Limitations”| Feature | Full Node | Light Client |
|---|---|---|
| Query balances | ✅ | ✅ |
| Query contract state | ✅ | ⚠️ (needs proof) |
| Send transactions | ✅ | ✅ |
| Historical data | ✅ | ❌ |
| Verify specific tx | ✅ | ⚠️ (needs help) |
| Storage | ~1.2 TB | ~1 GB |
12.6 Checking Sync Status
Section titled “12.6 Checking Sync Status”Using Geth Console
Section titled “Using Geth Console”# Attach to Gethgeth attach http://localhost:8545
# Check sync statuseth.syncingOutput When Syncing
Section titled “Output When Syncing”{ currentBlock: 18500000, // Block we're currently processing highestBlock: 18501234, // Network's current head knownStates: 50000000, // Total states known pulledStates: 45000000, // States downloaded startingBlock: 18000000 // Where we started}Output When Synced
Section titled “Output When Synced”falseUsing JSON-RPC
Section titled “Using JSON-RPC”# Check if syncingcurl -X POST http://localhost:8545 \ -H "Content-Type: application/json" \ -d '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}'
# Check current blockcurl -X POST http://localhost:8545 \ -H "Content-Type: application/json" \ -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'12.7 Making Your Node Fully Sync - Step by Step
Section titled “12.7 Making Your Node Fully Sync - Step by Step”Step-by-Step Guide
Section titled “Step-by-Step Guide”┌─────────────────────────────────────────────────────────────────────────────┐│ HOW TO MAKE NODE FULLY SYNC │├─────────────────────────────────────────────────────────────────────────────┤│ ││ STEP 1: Choose Your Client ││ ┌───────────────────────────────────────────────────────────────────┐ ││ │ For most cases: │ ││ │ - Geth (most popular, well-tested) │ ││ │ - Erigon (faster, less memory) │ ││ │ - Nethermind (good for archive queries) │ ││ └───────────────────────────────────────────────────────────────────┘ ││ ││ STEP 2: Choose Sync Mode ││ ┌───────────────────────────────────────────────────────────────────┐ ││ │ Recommended: SNAP SYNC (--syncmode snap) │ ││ │ - Fastest: Hours instead of weeks │ ││ │ - Result: Identical to full sync │ ││ │ - Safe: Verified by execution │ ││ └───────────────────────────────────────────────────────────────────┘ ││ ││ STEP 3: Start the Node ││ ┌───────────────────────────────────────────────────────────────────┐ ││ │ geth --syncmode snap --http --http.api eth,net,web3 │ ││ └───────────────────────────────────────────────────────────────────┘ ││ ││ STEP 4: Monitor Progress ││ ┌───────────────────────────────────────────────────────────────────┐ ││ │ # Check every few minutes │ ││ │ curl -X POST http://localhost:8545 \ │ ││ │ -H "Content-Type: application/json" \ │ ││ │ -d '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' ││ │ │ ││ │ When it returns "false" → Your node is synced! │ ││ └───────────────────────────────────────────────────────────────────┘ ││ ││ STEP 5: Verify Synced Status ││ ┌───────────────────────────────────────────────────────────────────┐ ││ │ # Compare your block with network │ ││ │ eth.blockNumber (your node) │ ││ │ should equal network block height │ ││ └───────────────────────────────────────────────────────────────────┘ ││ ││ ⏱️ Expected Time: 2-4 hours for snap sync ││ 💾 Expected Storage: ~1.2 TB ││ │└─────────────────────────────────────────────────────────────────────────────┘Quick Start Commands
Section titled “Quick Start Commands”# OPTION 1: Quickest - Snap Sync (RECOMMENDED)geth --syncmode snap --http
# OPTION 2: Full Verification - Full Sync (slower)geth --syncmode full --http
# OPTION 3: Light access (not geth — use Helios or a hosted node)# helios --network mainnet --execution.rpc http://localhost:854512.8 Troubleshooting Sync Issues
Section titled “12.8 Troubleshooting Sync Issues”Common Problems
Section titled “Common Problems”| Problem | Cause | Solution |
|---|---|---|
| Stuck at 0 | Wrong network/discovery | Check bootnodes, network |
| Very slow | Low resources/peer count | Increase peers, check CPU |
| Stuck at header | Database issue | Remove datadir, restart |
| Peers keep dropping | Network/firewall | Check port 30303 |
Diagnostic Commands
Section titled “Diagnostic Commands”# Check peer countcurl -X POST http://localhost:8545 \ -H "Content-Type: application/json" \ -d '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":1}'
# Check network versioncurl -X POST http://localhost:8545 \ -H "Content-Type: application/json" \ -d '{"jsonrpc":"2.0","method":"net_version","params":[],"id":1}'
# 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}'Reset and Restart
Section titled “Reset and Restart”# Stop the nodesystemctl stop geth
# Remove chaindata (NOT the keystore!)rm -rf /data/ethereum/geth/chaindata
# Restartsystemctl start geth12.9 Cross-Protocol Synchronization (Cosmos, Polkadot, Solana)
Section titled “12.9 Cross-Protocol Synchronization (Cosmos, Polkadot, Solana)”“Snap sync” is Ethereum’s term, but every ecosystem solved the same problem — syncing fast without replaying all history — differently. Never assume the same flags or concepts apply.
| Ecosystem | Fast-sync mechanism | How it works | Typical time |
|---|---|---|---|
| Ethereum | Snap sync (geth) | Peer-to-peer state trie download from snapshot | Hours |
| Cosmos/CometBFT | State sync | Trusted RPC peers provide a snapshot of the app state at a recent height (via statesync RPC); the node verifies it with light-client verification, then blocksyncs the rest | Minutes |
| Polkadot/Substrate | Warp sync | Downloads the finalized state via GRANDPA proofs (one authority-set change at a time), then syncs headers | Minutes-hours |
| Solana | Snapshot download | Download an incremental snapshot (tower state) from trusted RPC endpoints; the ledger then fills in | Minutes for snapshot + catch-up |
Cosmos/CometBFT State Sync
Section titled “Cosmos/CometBFT State Sync”Unlike Ethereum, CometBFT state sync is trust-with-verification: you trust RPC servers to serve you a snapshot, but you verify it using light-client logic (checkpoints signed by the validator set). Configuration lives in config.toml (not CLI flags):
[statesync]enable = truerpc_servers = "https://rpc.cosmos.example.com:26657,https://rpc2.cosmos.example.com:26657"trust_height = 18000000 # a height you can verify out-of-bandtrust_hash = "9B3F..." # its block hashtrust_period = "168h" # must be < unbonding periodNote the flags are not --statesync.enable or --seeds= — those are config.toml fields. CLI flags like --p2p.persistent_peers exist, but state-sync and seed config are in the TOML.
Polkadot/Substrate Warp Sync
Section titled “Polkadot/Substrate Warp Sync”# Polkadot v1.0+ defaults to warp sync; explicit:polkadot --sync warp --chain polkadot
# Older / full sync:polkadot --sync fullWarp sync pulls in the state at the last GRANDPA-finalized block using consecutive authority-set changes as proofs, so a fresh node can be at the tip in about an hour on modest hardware — a huge change from the days of 12+ hour syncs.
Solana Snapshot Sync
Section titled “Solana Snapshot Sync”# solana-validator downloads snapshots from --known-validator endpoints automatically.# Force one:solana-validator --snapshot-interval-slots 25000 --limit-ledger-size 50000000 ...Solana nodes in practice download an incremental snapshot (state + recent votes) and replay the remaining slots from the ledger, which is why the hardware (especially IOPS) matters so much during catch-up.
Interview talking point: “Fast sync is ecosystem-specific: Ethereum does state-trie snap sync, Cosmos trusts-and-verifies RPC snapshots via CometBFT state sync, Polkadot uses warp sync with GRANDPA proofs, and Solana downloads tower snapshots. They all trade a bit of ‘replay everything’ trust for hours of time — and each one verifies the downloaded state with the chain’s own finality/light-client machinery.”
12.10 Interview Questions
Section titled “12.10 Interview Questions”| Question | Answer |
|---|---|
| What sync mode is fastest? | Snap sync (hours vs weeks) |
| What sync mode is most secure? | Full sync (verifies everything) |
| How to check if node is synced? | eth.syncing returns false |
| Difference between snap and full? | Snap downloads state snapshot; full verifies every block |
Summary
Section titled “Summary”- Snap Sync: Recommended for most use cases (hours)
- Full Sync: Maximum security (days to weeks)
- Light clients: Available via dedicated light clients (geth
--syncmode lightremoved in v1.13) - To make node fully sync: Run with
--syncmode snapand wait - Check sync status with
eth.syncing- returnsfalsewhen synced - Other ecosystems have their own fast-sync: Cosmos state-sync, Polkadot warp sync, Solana snapshots (see 12.10)
Next Chapter
Section titled “Next Chapter”In Chapter 13: Cosmos Ecosystem Overview, we’ll explore Cosmos and Tendermint-based chains.
Last Updated: 2026-02-20