Geth(12) QA - Kehao Zheng's Website

Q1: How does a transaction propagate across the entire network?#

Overall flow#

1
User submits transaction (eth_sendRawTransaction)
2
       │
3
       ▼
4
  Local txpool receives it, emits NewTxsEvent
5
       │
6
       ▼
7
  handler.txBroadcastLoop() receives the event
8
       │
9
       ▼
10
  BroadcastTransactions() dual-layer distribution
11
       ├─ Send full tx to ~sqrt(N) peers directly     (TransactionsMsg)
12
       └─ Send only hash to all remaining peers        (NewPooledTransactionHashesMsg)
13
       │                                                     │
14
       ▼                                                     ▼
15
  Peers receiving full tx                           Peers receiving hash announcement
16
  Add directly to txpool                            TxFetcher 3-stage pipeline
17
                                                      ├─ Wait 500ms (direct broadcast may arrive)
18
                                                      ├─ Didn't arrive? Queue for request
19
                                                      └─ Send GetPooledTransactionsMsg to fetch
20
                                                              │
21
                                                              ▼
22
                                                         Receive full tx, add to txpool
23
                                                              │
24
                                                              ▼
25
                                                         This peer also fires NewTxsEvent
26
                                                         → continues propagating to its peers...

Within seconds, the transaction reaches virtually every node in the network.

Dual-layer broadcast strategy#

Why not send the full transaction to all peers? Because it wastes too much bandwidth. With 50 peers, sending 50 full copies per transaction, with every node doing the same — traffic would explode.

Geth’s strategy is direct broadcast + hash announcement:

1
func (h *handler) BroadcastTransactions(txs types.Transactions) {
2
    for _, tx := range txs {
3
        switch {
4
        case tx.Type() == types.BlobTxType:
5
            // Blob transactions: announce only (~768KB, too large)
6
        case tx.Size() > txMaxBroadcastSize:  // 4KB
7
            // Large transactions: announce only
8
        default:
9
            // Normal transactions: select sqrt(N) peers for direct send
10
            directSet = choice.choosePeers(peers, txSender)
11
        }
12

13
        for _, peer := range peers {
14
            if peer.KnownTransaction(tx.Hash()) {
15
                continue  // peer already knows this tx, skip
16
            }
17
            if _, ok := directSet[peer]; ok {
18
                txset[peer] = append(...)   // direct send list
19
            } else {
20
                annos[peer] = append(...)   // hash announcement list
21
            }
22
        }
23
    }
24
}

Three key details:

1) sqrt(N) selection: With 50 peers, roughly 7 get the full transaction, the remaining 43 get only the hash. Those 43 will actively request the full transaction if they need it.

2) Deterministic selection: Which peers are chosen is not random — it’s deterministically computed via siphash(key, self_id, peer_id, tx_sender). Different nodes choose different peer subsets for direct broadcast, ensuring good network-wide coverage.

3) Special cases: Blob transactions (~768KB) and large transactions (>4KB) are always announce-only — sending full data is too expensive.

knownTxs: avoiding duplicate sends#

Each peer maintains a knownCache (up to 32768 hashes) recording “transactions this peer already knows about”:

1
Peer A's knownTxs: {tx1, tx2, tx3, ...}
2

3
When I want to broadcast tx2 to peer A:
4
  peer.KnownTransaction(tx2.Hash()) == true
5
  → skip, don't send

A transaction is marked as known when:

I send it to the peer → mark
The peer sends it to me → mark
The peer announces it to me → mark

Per-peer send queues#

Direct broadcasts and hash announcements each have an async channel:

1
Peer struct:
2
  txBroadcast chan []common.Hash   ← direct broadcast queue
3
  txAnnounce  chan []common.Hash   ← hash announcement queue
4

5
broadcastTransactions() goroutine:
6
  Read hashes from txBroadcast
7
  → Fetch full tx data from txpool
8
  → Pack into packets up to 100KB
9
  → Send TransactionsMsg
10

11
announceTransactions() goroutine:
12
  Read hashes from txAnnounce
13
  → Send NewPooledTransactionHashesMsg (includes hash + type + size)

Announcements carry type and size metadata, letting the receiver decide whether to fetch without a round trip.

TxFetcher: three-stage fetch pipeline#

When a peer announces a transaction hash, the receiving node’s TxFetcher processes it through a three-stage pipeline:

1
Stage 1: Waitlist (wait 500ms)
2
  Hash announced → placed in waitlist
3
  Wait 500ms to see if the full tx arrives via another peer's direct broadcast
4

5
  Why wait? Because another peer is very likely broadcasting the full tx to you.
6
  If it arrives → done, no need to fetch actively
7

8
Stage 2: Queue (ready to request)
9
  500ms passed and still not arrived → move to request queue
10

11
Stage 3: Fetching (send request)
12
  Take from queue, send GetPooledTransactionsMsg to a peer that announced this hash
13
  → Peer replies with PooledTransactionsMsg (full tx data)
14
  → Add to local txpool
15

16
  If no reply within 5 seconds → retry with a different peer

Key constants:

1
maxTxAnnounces     = 4096       // max pending announcements per peer
2
maxTxRetrievals    = 256        // max txs per fetch request
3
maxTxRetrievalSize = 128 * 1024 // max 128KB per fetch request
4
txArriveTimeout    = 500ms      // waitlist timeout
5
txFetchTimeout     = 5s         // fetch request timeout

Underpriced transaction cache#

TxFetcher also tracks transactions rejected by the txpool as “too cheap”:

1
Fetch tx8 → txpool rejects (fee too low)
2
→ tx8's hash is cached for 5 minutes
3

4
During those 5 minutes, if other peers also announce tx8:
5
→ TxFetcher skips it immediately, no re-request

Avoids repeatedly wasting bandwidth fetching the same transaction that’s doomed to be rejected.

Q2: How does a node sync the entire chain from scratch?#

Two sync modes#

	Full Sync	Snap Sync
Downloads	headers + bodies + receipts	headers + bodies + receipts
State acquisition	Re-execute every tx from genesis	Download state snapshot at pivot block
Tx execution	All (hundreds of millions)	Only last ~64 blocks
Time	Days	Hours
Requires snap protocol peers	No	Yes

Snap sync is the default mode. It skips the most time-consuming step: re-executing historical transactions.

Sync pipeline overview#

1
Consensus layer: "New head at block N"
2
       │
3
       ▼
4
Stage 1: Skeleton sync (download headers backwards)
5
  Download header chain from block N towards genesis
6
  512 headers per batch, stored in scratch space
7
       │
8
       ▼
9
Stage 2: Backfill (concurrently download bodies + receipts)
10
  Once skeleton links to local chain, spawn concurrent fetchers:
11
  ├─ fetchHeaders()   — read already-downloaded headers from skeleton
12
  ├─ fetchBodies()    — download block bodies (txs, uncles, withdrawals)
13
  └─ fetchReceipts()  — download receipts (snap sync only)
14
       │
15
       ▼
16
Stage 3: Processing and import
17
  Full sync:  processFullSyncContent()
18
              → InsertChain() executes every tx, builds state from scratch
19
  Snap sync:  processSnapSyncContent()
20
              ├─ Below pivot: import with downloaded receipts (no execution)
21
              ├─ SnapSyncer downloads state snapshot at pivot in parallel
22
              └─ Above pivot (~64 blocks): full execution

Skeleton syncer: why download backwards?#

The skeleton is the core mechanism for header downloading. It starts from the head provided by the consensus layer and downloads backwards:

1
Chain head → → → → → → → → → → → → → → Genesis
2
  ←─────────────────────────────────────
3
         skeleton download direction

Why backwards? Because after the Merge, the consensus layer tells you “the chain head is here.” You only know the endpoint, not what blocks are in between. Downloading backwards allows:

Starting from a known trusted point (head provided by CL)
Each header contains parentHash, verifying chain continuity in the backward direction
Eventually connecting to locally existing chain data

Subchains: handling interruptions and restarts#

Sync can be interrupted (network disconnect, node restart). The skeleton tracks progress using a subchain list:

1
Initial state (CL announces head = 1000):
2

3
  Subchain 1: [Head: 1000, Tail: 1000]
4
               (just the tip)
5

6
After downloading 200 headers:
7

8
  Subchain 1: [Head: 1000, Tail: 800]
9
               (headers 800~1000 downloaded)
10

11
Node restarts, CL announces new head = 1050:
12

13
  Subchain 1: [Head: 1050, Tail: 1050]  ← new tip
14
  Subchain 2: [Head: 1000, Tail: 800]   ← previous progress
15

16
After filling the gap between 1000~1050:
17

18
  Subchain 1: [Head: 1050, Tail: 800]   ← merged!
19

20
Continue downloading backwards, eventually link to local chain (or genesis):
21

22
  Subchain 1: [Head: 1050, Tail: 0]     ← complete

Each subchain records three values: Head (newest block number), Tail (oldest block number), Next (parent hash of Tail, for link verification). Progress is persisted to disk, so restarts don’t lose already-downloaded data.

Snap sync’s pivot block#

The key concept in snap sync is the pivot block:

1
Genesis ──────────────────────── Pivot ──── Chain head
2
  │            Zone A             │  Zone B  │
3
  │                               │          │
4
  │  Import with downloaded       │ Full     │
5
  │  receipts (no execution)      │ execution│
6
  │                               │ (~64 blk)│
7
  └───────────────────────────────┘          │
8
     Meanwhile: SnapSyncer downloads          │
9
     state snapshot at pivot                  │

The pivot is chosen at least 64 blocks behind the chain head. Why 64?

Full execution of 64 blocks ensures local state is correct
64 also corresponds to half the trie’s in-memory retention depth (the 128-block GC window from Chapter 10)

SnapSyncer uses the snap protocol to download the complete state at the pivot in parallel from multiple peers — account trie, storage tries, and contract bytecode. This is much faster than re-executing all historical transactions.

Concurrent fetcher architecture#

Body and receipt downloading use a concurrent fetcher pattern:

1
fetchBodies() goroutine:
2
  for {
3
      1. Take a batch of headers needing bodies from queue (up to 128)
4
      2. Select a peer that has this data
5
      3. Send GetBlockBodiesMsg
6
      4. Wait for BlockBodiesMsg response
7
      5. Validate data, pass to processor
8
  }
9

10
fetchReceipts() goroutine: (snap sync only)
11
  Similar logic, up to 256 receipts per batch

Multiple fetchers run concurrently, pulling different ranges of data from different peers, maximizing download bandwidth utilization.

Key limits#

1
MaxBlockFetch   = 128    // max 128 bodies per request
2
MaxHeaderFetch  = 192    // max 192 headers per request
3
MaxReceiptFetch = 256    // max 256 receipts per request
4
maxResultsProcess = 2048 // max 2048 results to import at once
5
fsMinFullBlocks   = 64   // min fully-executed blocks in snap sync

Q3: What is Fork ID and why is it needed? (EIP-2124)#

The problem#

Ethereum has gone through many hard forks (Homestead, Byzantium, London, Shanghai…). Different nodes may run different software versions with different forks activated. If two nodes on different chains try to sync with each other, they only waste time and bandwidth.

How to quickly determine during handshake whether two nodes are compatible?

Fork ID design#

Fork ID is an extremely compact identifier — only 8 bytes:

1
type ID struct {
2
    Hash [4]byte  // CRC32(genesis hash + all activated fork block numbers)
3
    Next uint64   // Block/timestamp of next upcoming fork (0 = no known future fork)
4
}

How it’s computed#

1
func NewID(config *params.ChainConfig, genesis *types.Block, head, time uint64) ID {
2
    // Start from genesis block hash
3
    hash := crc32.ChecksumIEEE(genesis.Hash().Bytes())
4

5
    // Gather all fork points (by block number and timestamp)
6
    forksByBlock, forksByTime := gatherForks(config, genesis.Time())
7

8
    // Mix in each already-passed fork
9
    for _, fork := range forksByBlock {
10
        if fork <= head {
11
            hash = checksumUpdate(hash, fork)   // activated → mix in
12
            continue
13
        }
14
        return ID{Hash: checksumToBytes(hash), Next: fork}  // not yet → set as Next
15
    }
16
    // Same for timestamp-based forks...
17

18
    return ID{Hash: checksumToBytes(hash), Next: 0}  // no known future forks
19
}

Concrete example:

1
Mainnet genesis hash: 0xd4e56740...
2
Activated forks: Homestead(1150000), Byzantium(4370000), London(12965000), ...
3
Current head: 20000000
4
Next unactivated fork: suppose Prague at block 21000000
5

6
Hash = CRC32(genesis_hash)
7
     = CRC32_update(hash, 1150000)    // Homestead
8
     = CRC32_update(hash, 4370000)    // Byzantium
9
     = CRC32_update(hash, 12965000)   // London
10
     = ... each activated fork mixed in sequentially
11
     = 0xABCD1234 (final 4 bytes)
12

13
Next = 21000000 (next unactivated fork)
14

15
Fork ID = {Hash: 0xABCD1234, Next: 21000000}

Four validation scenarios#

During handshake, two nodes exchange Fork IDs and check compatibility:

Scenario 1: Same fork state — fully compatible

1
Local:  Hash=0xABCD, Next=21000000
2
Remote: Hash=0xABCD, Next=21000000
3
→ ✓ On the same chain, same forks activated

Scenario 2: Remote is a subset (still syncing) — compatible

1
Local:  Hash=0xABCD, Next=21000000 (London etc. activated)
2
Remote: Hash=0x1234, Next=12965000 (London not yet activated)
3
→ ✓ Remote node may still be syncing, hasn't reached the London fork block yet
4
     But it knows Next=12965000 (London), meaning it's aware of this fork

Scenario 3: Remote is a superset (we’re behind) — compatible

1
Local:  Hash=0x1234, Next=12965000 (London not yet activated)
2
Remote: Hash=0xABCD, Next=21000000 (London activated)
3
→ ✓ Local node may be behind, it will catch up

Scenario 4: Mismatch — incompatible, disconnect

1
Local:  Hash=0xABCD (mainnet)
2
Remote: Hash=0x9999 (some testnet)
3
→ ✗ Different fork history, cannot be the same chain

Why not just compare genesis hash + full fork list?#

Compactness: Fork ID is only 8 bytes. A full fork list grows with each hard fork.
Forward compatibility: The Next field lets older node versions know “a new fork is coming,” even if they don’t know the specifics.
CRC32 irreversibility: You can’t reverse-engineer which specific forks were activated from the Fork ID, but that doesn’t matter — you only need to know “are we compatible.”

gatherForks() implementation#

gatherForks() scans the ChainConfig struct via reflection to collect all fork points:

1
ChainConfig fields:
2
  HomesteadBlock:     1150000     ← block-number-based forks
3
  ByzantiumBlock:     4370000
4
  LondonBlock:        12965000
5
  ShanghaiTime:       1681338455  ← timestamp-based forks
6
  CancunTime:         1710338135
7
  ...
8

9
gatherForks() output:
10
  forksByBlock = [1150000, 4370000, 12965000, ...]
11
  forksByTime  = [1681338455, 1710338135, ...]

Deduplicated and sorted, then mixed into CRC32 sequentially. This means every time a new hard fork is added, Fork ID updates automatically — no need to manually maintain a compatibility list.

Welcome