Measured on the same networks, besu-xdc (Bonsai) and the xOne clients reached the same head and returned the same core block fields. They differ in datadir size, heap size and in which XDC fields the block JSON contains. This post gives each number with its network and sync mode. besu-xdc is an XDCIndia client too, so this is a neutral comparison.

Measured read-only on 2026-11-14 at 19:20 UTC by the xOne team on its own follower nodes; one sample, not a time series. Source: xOne team measurement, 2026-11-14 19:20 UTC (there is no file link for it).

How was it measured?

Each node answered eth_blockNumber. Lag is the reference head minus the node head at the same second. The reference is a geth-XDC node of the same network: full sync on net2040, snap on Apothem. Reference heads: net2040 841,381; Apothem 85,385,427.

  • Datadir: du -sx --block-size=1 of the datadir.
  • Memory: VmRSS of the main process, read from /proc. RssAnon is heap. RssFile is mapped files; an MDBX or RocksDB map counts as RssFile. Where both are read, this post compares RssAnon. RssAnon and RssFile come from a second read a few minutes after the VmRSS read.
  • RPC sample: 50 calls per node, made against the node and the reference. 30 calls were eth_getBlockByNumber(n,false) for n = node head-130 to head-101. 10 were eth_getBlockTransactionCountByNumber for the last 10 of those blocks. 10 were eth_getBlockByHash(hash,false) for the first 10 hashes.
  • Compare: the whole JSON, after lower-casing strings. Core fields: hash, parentHash, stateRoot, receiptsRoot, transactionsRoot, number, miner, gasUsed, timestamp.

xOneRS is the Rust client; xOneTS, xOnePy and xOneC are the TypeScript, Python and C++ clients (which xOne client).

What does the besu-xdc project publish?

Very little. The besu-xdc repository contains the upstream Besu README only. It has no XDC documentation and no releases. This post therefore does not describe how besu-xdc implements XDPoS. It reports measured behaviour only.

How do upstream Besu storage and sync modes work?

Upstream Besu documents Bonsai as the default storage format and SNAP as the default sync mode for named networks. The table gives the upstream context. These numbers describe upstream Besu. Do not compare them with the XDC datadirs below.

REFERENCE TABLEScroll to explore all columns →
Topic Upstream Besu documentation
Storage format Bonsai is the default: --data-storage-format=BONSAI (data storage formats)
Sync mode --sync-mode=SNAP is the default for named networks; FULL is the default for dev; CHECKPOINT is deprecated (node sync)
Snap sync time A snap-synced Bonsai full node takes about 12-16 h (node sync)
Snap-synced Bonsai node size About 1.14 TB (data storage formats)
Archive Forest for an archive is about 12 TB; Bonsai archive is in progress (data storage formats)
Memory Minimum JVM memory 8 GB; reference machine 8 vCPU and 30 GiB (system requirements)

How do head, disk and memory compare on net2040?

Both besu-xdc nodes were at the head. Datadir and heap sizes differ by sync mode and client. Rows are grouped by sync mode. The xOne archive and minimal nodes are in the measurement but have no Bonsai counterpart here, so they are left out.

REFERENCE TABLEScroll to explore all columns →
Node Head Lag Datadir bytes (GB) VmRSS kB RssAnon kB RssFile kB
besu-xdc full (Bonsai) 841,381 0 10,852,532,224 (10.85) 779,028 752,028 27,676
xOneRS full 841,381 0 20,637,130,752 (20.64) 85,948 65,116 16,492
xOneRS full (second node) 841,381 0 20,703,092,736 (20.70) 601,132 not read not read
xOneTS full 841,381 0 19,564,638,208 (19.56) 298,696 277,000 24,864
xOneC full 841,381 0 17,990,488,064 (17.99) 106,064 58,476 46,888
besu-xdc snap (Bonsai) 841,379 2 5,944,541,184 (5.94) 1,380,196 not read not read
xOneRS fast 841,381 0 147,234,816 (0.15) 211,284 not read not read
xOnePy snap 841,379 2 94,523,392 (0.09) 83,408 not read not read
xOneC snap 841,381 0 142,987,264 (0.14) 79,628 not read not read
  • Full sync: the besu-xdc datadir is smaller than every xOne full datadir. Its RssAnon is larger than the RssAnon of xOneRS, xOneTS and xOneC.
  • Snap or fast sync: the besu-xdc datadir (5.94 GB) is larger than the xOne datadirs (0.09 to 0.15 GB). Only VmRSS is read for these rows.
  • The measurement does not say why the sizes differ. It does not compare node age or pruning settings.
  • xOnePy runs extra worker processes that are not counted in its row.

How do head, disk and memory compare on Apothem?

All nodes were at the head or one block ahead of the reference. The sizes differ widely between the xOne rows.

REFERENCE TABLEScroll to explore all columns →
Node Head Lag Datadir bytes (GB) VmRSS kB RssAnon kB RssFile kB
besu-xdc snap (Bonsai) 85,385,427 0 29,531,799,552 (29.53) 2,217,196 2,240,324 27,608
xOneRS snap 85,385,428 -1 75,107,868,672 (75.11) 519,008 489,112 33,192
xOnePy snap 85,385,428 -1 31,119,683,584 (31.12) 179,856 166,264 14,236
xOneC snap 85,385,428 -1 51,045,007,360 (51.05) 10,107,556 349,504 9,793,144
  • The xOneC VmRSS is mostly mapped files (RssFile 9,793,144 kB). Compare its RssAnon, 349,504 kB.
  • In the besu-xdc row, RssAnon is larger than VmRSS. RssAnon and RssFile were read in a second pass a few minutes after VmRSS, so the two reads can differ.
  • The besu-xdc datadir (29.53 GB) is smaller than the xOneRS (75.11 GB), xOneC (51.05 GB) and xOnePy (31.12 GB) datadirs.
  • Where both are read, the besu-xdc RssAnon (2,240,324 kB) is larger than the RssAnon of every xOne row.

For xOne sizes by mode, see xOne storage layout and hardware and disk.

Does the RPC output of besu-xdc equal the reference?

Core fields are equal. The JSON shape differs. For every besu-xdc node, the core fields of all 40 block objects were equal to the reference. Every xOne node that answered returned the same whole JSON as the reference on all 50 calls.

REFERENCE TABLEScroll to explore all columns →
Network Node Whole JSON equal, of 50 Block objects with equal core fields Differing keys (count of calls)
net2040 besu-xdc full (Bonsai) 10 40/40 node adds totalDifficulty (40); node lacks penalties, validator, validators (40 each)
net2040 besu-xdc snap (Bonsai) 10 40/40 the same four keys, 40 calls each
Apothem besu-xdc snap (Bonsai) 10 40/40 the same four keys, 40 calls each
net2040, Apothem every xOne node that answered 50 40/40 none

Here is what the JSON contains. A besu-xdc block object has totalDifficulty. The geth-XDC reference did not return that key in these samples. The besu-xdc object has no validator, validators or penalties, and the reference returns them. The 40 block-object calls differ in shape; the other 10 calls are equal. See the RPC surface for the xOne side and the geth-XDC comparison.

What does this measurement not show?

It is one sample. It has no time series, no sync time, no throughput and no block production for besu-xdc. It has no mainnet node.

Correction

On 2026-11-15 we removed an Apothem row that was labelled "xOneRS snap (second node)". That node reports the version xOne/v1.1.0/linux-amd64/go1.25.0: it runs xOneGo, the earlier Go line, not xOneRS. The other rows are unchanged.

Frequently asked questions

Does besu-xdc reach the same head as xOne?

Yes, in this sample. On net2040 the besu-xdc full node had lag 0 and the snap node had lag 2. On Apothem its snap node had lag 0.

Is besu-xdc smaller on disk than xOne?

It depends on the sync mode. On net2040 the besu-xdc full datadir is 10.85 GB against 17.99 to 20.70 GB for xOne full nodes. The besu-xdc snap datadir is 5.94 GB against 0.09 to 0.15 GB for xOne snap and fast nodes.

Why do some besu-xdc RPC calls differ?

The block JSON has a different set of XDC fields. It adds totalDifficulty and lacks validator, validators and penalties. The core fields were equal on all 40 block objects per node.

Sources