Popular starting points

Loading the full XDC search index…

Developer hubBuild · PageFrom your first contract to your next application.Wallets & custodyDiscover · PageUnderstand the network. Find your place in it.Get XDCDiscover · PageUnderstand the network. Find your place in it.Run a nodeBuild · PageFrom your first contract to your next application.Ecosystem applicationsDiscover · PageUnderstand the network. Find your place in it.Post-quantum initiativeResearch · PageA clear view of the engineering ahead.
↑ ↓ to selectEnter to openEsc to close
Browse all resources →
HomePublicationsSource sample

INFRASTRUCTURE / PRESERVED SOURCE SAMPLE

XDPoS on a modern go-ethereum base, measured

A preserved source sample explaining the Labs’ modern-geth re-baseline, with its original text, measurement table and FAQ. Performance and readiness claims remain attributed to the source.

READ WITH CONTEXT

A sample, with its claims attributed.

The source identifies this as a demonstration of its blog format. The complete article text, source abstract, table and FAQ are preserved below. Client counts, production measurements and consensus-parity statements are the author’s reports; they have not been independently reproduced here.

Syncing mainnet does not establish validator readiness. Client diversity can reduce shared implementation risk, but the source’s absolute claim that no single implementation can halt the network is not a guarantee. Resource use depends on configuration, hardware, workload and measurement method.

Original source abstract

XDC's XDPoS engine was re-based onto modern go-ethereum v1.17.3. A modern mainnet node measures ~303 GB on disk versus ~919 GB for a legacy full node — about 3× smaller — with bit-exact consensus parity preserved.

ORIGINAL SAMPLE ARTICLE / XDC INNOVATION LABS

XDC Network now runs four independent execution clients across three languages — go-ethereum (GP5) and Erigon in Go, Nethermind in C#/.NET, and Reth in Rust — all syncing mainnet. This post summarizes the engineering case for re-platforming the XDPoS engine onto a modern go-ethereum base, with the figures measured in production.

What changed

The XDPoS consensus engine was re-based onto pristine go-ethereum v1.17.3, inheriting a decade of upstream engineering — path-based state (PBSS), Pebble, freezer/ancients, snap sync, and the modern wire protocol — without touching consensus. The result is bit-exact consensus parity with the canonical chain.

The measured result

The headline is disk and CPU footprint. On XDC mainnet production nodes:

Measurements reported in the source sample. Not independently verified here.
MetricLegacy full nodeModern (geth v1.17.3)Delta
Disk on mainnet~919 GB~303 GB~3× smaller
CPU at idle headbaseline~40× lighter—
ConsensusXDPoSXDPoS (bit-exact)unchanged

These are measurements from the multi-client fleet, not projections.

Why client diversity matters

XDC is the first XDPoS chain with full client diversity. Because four independent implementations sync the same chain, no single implementation can halt the network — a resilience property that the comparison and architecture pages document in detail.

This is a sample post created to demonstrate the blog's structure (TL;DR, claim→evidence, a data table, and an FAQ block) — all of which double as Generative Engine Optimization signals. Every figure above is already published on the XDC Innovation Labs architecture and migration pages.

FROM THE SOURCE FRONTMATTER

Source FAQ.

These answers reproduce the sample’s claims and carry the same qualifications above.

Does the modern client change consensus?
No. XDPoS is layered additively onto go-ethereum v1.17.3; consensus is bit-exact with the canonical chain.
How much smaller is the modern node on disk?
A modern mainnet node measures about 303 GB versus roughly 919 GB for a legacy full node — about 3× smaller.

Continue with the evidence.

The source points to its architecture and migration publications. Read them alongside the current readiness context.

Full migration publication Source architecture publication Current client-readiness context Original source file
← Back to all publications