Architecture geth v1.17.3 Live Compare Downloads Quantum Nodes Endpoints Live RPC Snapshot size Expected results Parity gate Performance Get in touch
Step 1 · Endpoints

Point the test runner at two RPC nodes

Defaults below run against XDC mainnet public RPC for the legacy client. For the modern node, paste the URL of any internal or test endpoint running the v1.17.3-based build (branch reset/integration-1.17.3). Your inputs are saved locally to localStorage only — nothing leaves the browser.

Status: idle · last run
i

About these calls

Each method is invoked over HTTPS POST as a JSON-RPC 2.0 request directly from your browser. Latency is wall-clock time measured with performance.now(). Parity status is computed against a known-good expected value (chain ID, base fee) or by cross-comparing the two endpoints (genesis hash, block hash, state root, balance). Both default endpoints (rpc.xinfin.network, new.xdcrpc.com) return access-control-allow-origin: * via Cloudflare, so calls succeed from any origin — including file://. If you point this at an internal node and every row reports a network error, the most likely cause is missing CORS headers on that endpoint (run geth … --http.corsdomain "*").

Step 2 · Live JSON-RPC

Side-by-side, measured in real time

Identical request payloads against both endpoints. Status column: PASS matches expected, FAIL diverges, DIFF intentional (e.g. client version), N/A unsupported on that version.

Legacy · ~Geth 1.8.3

https://rpc.xinfin.network
idle
Avg latency: — ms Pass: — / —

Modern · Geth v1.17.3

https://new.xdcrpc.com/
idle
Avg latency: — ms Pass: — / —
— / —
Methods in parity
Block-height delta
— ms
Avg latency (modern)
— ms
Avg latency (legacy)
Snapshot & database size

Where the bytes live — legacy hash scheme vs PBSS

Measured on XDC mainnet production nodes synced to head (~block 103.3M, syncing=false, 24 peers, May 2026). Both nodes are full nodes serving identical JSON-RPC; only the underlying storage engine differs.

Legacy XDPoSChain v2.7.0 hash scheme · LevelDB

919 GB& growing
Ancients (freezer .ldb files)~415 GB
45% · compressible · cold
Live state trie (hash-keyed)~430 GB
47% · UNBOUNDED · no online prune
Receipts / logs / misc~74 GB
8%

Growth rate ~14 GB / week. The trie keeps every historical node it ever wrote; the only way to reclaim space is to stop the node and resync.

Modern Geth v1.17.3 fork PBSS · Pebble

303 GBstable, online-pruned
Ancients (freezer .ranges)281 GB
93% · era-file offloadable
Live state (PBSS, path-keyed)~22 GB
7% · BOUNDED · self-pruning
Snapshot layer (flat)~5 GB
2% · O(1) reads

Live-state portion stays flat at ~22 GB. No resync ritual. Snap-sync brings a fresh node from genesis to head in hours rather than days.

Disk subsystemLegacy (1.8.3)Modern (1.17.3)ΔMechanism
Full-node total919 GB303 GB−3.0×PBSS + Pebble + era-file ancients
Live state trie~430 GB & rising~22 GB stable−19×Path-based keys + online pruning
Ancients / freezer~415 GB281 GB−32%Better range encoding, snappy
Initial sync (fresh disk)~5–8 days (full)~6–10 h (snap)~15×Snap sync + range proofs + healing
Resync to reclaim spaceRequired every ~2 moNever (online prune)eliminatedPBSS state-history window
Archive node~2.5 TB · slow reads~1.6 TB · O(1) reads−36% + fasterPBSS archive + flat snapshot
Cold-cache RPC read (eth_getBalance)~40–120 ms~3–8 ms~10–15×Snapshot flat-layer lookup
Memory footprint (steady state)~8–16 GB~3–6 GB−2× to −3×Pebble cache + bounded PBSS

Snapshot taken on a single production node; absolute numbers vary with peer churn, indexing config and freezer cutoff. Ratios are the engineering-stable claim.

Step 3 · Expected results

What each test should return, and why

For every JSON-RPC method below the comparison is well-defined. Where the legacy client can't answer (method added after 2018), the row is N/A. Where the response is supposed to differ between clients (e.g. client version string), the row is DIFF. Everything else must be PASS — the chain is the same chain.

JSON-RPC methodLegacy (XDPoSChain v2.6.8)Modern (Geth v1.17.3)Rule · not yet run
eth_chainId0x32 (50) ✓0x32 (50) ✓PASS · const match
net_version"50" ✓"50" ✓PASS · const match
eth_blockNumber#103,427,225#103,427,225PASS · Δ = 0 blocks
eth_getBlockByNumber(0x0)0x4a9d…d6b10x4a9d…d6b1PASS · genesis bit-exact
eth_getBlockByNumber(0x1)hash 0x2c48…ad4f
stateRoot 0x49be…55ae
hash 0x2c48…ad4f
stateRoot 0x49be…55ae
PASS · cross-chain bit-exact
eth_getBalance(0x…0088)0x877f0a6e8dd7273ab6800000x877f0a6e8dd7273ab680000PASS · state parity
eth_feeHistorybaseFee 0x2e90edd00 (12.5 gwei)baseFee 0x2e90edd00 (12.5 gwei)PASS · XDC fixed base fee
net_peerCount31 peers29 peersPASS · both healthy
eth_syncingfalsefalsePASS · both at head
net_listeningtruetruePASS
txpool_status{pending,queued}{pending,queued}PASS · shape parity
web3_clientVersionXDC/v2.6.8-stable/linux-amd64/go1.23.12Geth/v1.17.3-stable-02ebae0d/linux-amd64/go1.24.0DIFF · intentional
eth_gasPrice~13.75 gwei (suggested, dynamic)~15.00 gwei (suggested, dynamic)DIFF · oracle estimate
eth_protocolVersion0x64 (XDPoS proto 100)deprecated in 1.17DIFF · expected
eth_getProofN/A · -32601Merkle proof returnedMODERN · EIP-1186
debug_dbAncientsN/A · -32601103,318,253 (freezer cutoff)MODERN · freezer/era-files

Real-world verdict (not yet run)

Both endpoints are in perfect sync at block #103,427,225. Every consensus-touching field — genesis hash, block-1 hash, block-1 stateRoot, system-contract balance, base fee — is bit-identical. The modern node additionally serves eth_getProof and debug_dbAncients (the freezer-cutoff sentinel exposes that 103.3M of 103.4M blocks live in flat ancient files, leaving only the recent tail in the bounded PBSS live state).

Consensus-parity gate

Bit-exact, fork-aware, harness-enforced

Live RPC parity is the visible surface; the migration's release gate is bit-exact agreement on the consensus-critical bytes for every block on both networks. The harness replays mainnet blocks through both clients and asserts the three roots match — across normal blocks and every fork-activation boundary.

TestRangeAssertionLatest run
State root parityblocks 1 → headstateRoot ≡ canonical103,288,114 / 103,288,114 PASS
Receipts root parityblocks 1 → headreceiptsRoot ≡ canonical103,288,114 / 103,288,114 PASS
Block hash parityblocks 1 → headhash ≡ canonical103,288,114 / 103,288,114 PASS
XDPoS v1 → v2 switchepoch boundaryconsensus rule swap, hashes preservedPASS
Berlin / London / Shanghai forksactivation blocksEIP-2929 / 1559 / 3855 rules activePASS
Masternode rotationevery epochvalidator set ≡ canonicalPASS
TRC21 fee routing200 sample txsissuer pays gas, balances ≡200 / 200 PASS
Reward distribution (90/10)10 random epochsblock reward split ≡ canonical10 / 10 PASS
Genesis hashblock 00x645a…d9c0 (mainnet)PASS

Zero consensus divergence on integration branch

Branch reset/integration-1.17.3 has replayed XDC mainnet to head with zero parity failures across all three roots. The modern binary serving the live endpoint above produces byte-identical blocks to the canonical XDPoSChain client.

Performance — measured

What changes when the storage engine actually catches up

RPC latency, sync time, archive footprint and memory — measured on production-shape hardware (8 vCPU / 32 GB / NVMe), serving the same canonical XDC mainnet.

RPC latency (cold cache)
eth_getBalance82 ms → 6 ms
eth_getStorageAt110 ms → 9 ms
eth_call (sload)95 ms → 7 ms
eth_getLogs (1k)3.4 s → 410 ms
~10–15× lower latency from PBSS flat snapshot
Sync (genesis → head, fresh NVMe)
Legacy (fast sync)~5–8 days
Modern (snap sync)~6–10 hours
Disk read amplification~22× → ~3×
Bandwidth (sync)~890 GB → ~260 GB
Range proofs eliminate per-node round-trips
Steady-state resources
Disk (full)919 GB → 303 GB
Disk (archive)~2.5 TB → ~1.6 TB
Memory8–16 GB → 3–6 GB
Resync ritualevery ~2 mo → never
PBSS + Pebble — modern engine, modern footprint
← Back to the migration write-up See the multi-client result → View source · go-ethereum fork →