On 2026-11-15 five pull requests changed how an xOneRS node stores chain data and uses its disks. Two make the history smaller: closed segment files can be compressed with zstd, and new receipts are stored without their bloom filters. Three make disk use easier to plan: segment files also rotate at a byte limit, bulk downloads can go to another volume, and the disk guard follows an online volume resize. None is in v0.1.0, and none of the PRs reports how many bytes it saves; we have not measured it either.

For the datadir layout these change, see how xOne stores XDC chain data. For disk sizing, see disk planning.

How are history segments compressed?

Headers, bodies and receipts live in append-only segment files (XSEG), one per 100,000 blocks. Since PR #1101:

  • A closed chunk below the committed floor can be rewritten as XSEG version 2, with zstd compression per frame and an optional dictionary.
  • The old file stays the source of truth until the new offsets and a frozen_xseg marker are committed; only then is the raw file removed. A crash in between leaves the old file in use.
  • Readers accept version 1 and version 2 files side by side, so a datadir can hold both.
  • xone db compact-history does this for a stopped datadir.

Why are receipts stored without blooms?

A receipt's bloom filter is computed from its logs, so it does not need to be stored. Since PR #1102, new receipts are written in a versioned XRCT envelope that keeps the status or post-state, the cumulative gas, the transaction type and the logs, and leaves out the bloom. A reader rebuilds byte-identical consensus receipts, blooms included, so RPC answers and receipt roots do not change. Older receipts in the legacy form still decode, and an unknown envelope version is refused rather than misread.

What else changed?

REFERENCE TABLEScroll to explore all columns →
Change Flag or command What it does
Size-capped segment files (PR #1070) --snapshot.chunk-bytes (default 2 GB; 0 keeps the block grid only) A segment file also rotates before a frame would pass the limit. A single block larger than the limit gets its own file. Early cuts are recorded in chunk-index.v1.
Staging volume (PR #1077) --datadir.staging <dir> Snapshot import and the HTTPS download buffer use another volume. Across devices, the node copies to a .part file, checks every byte, then renames; a failed move leaves the datadir as it was.
Resize-aware disk guard (PR #1096) none The stop, resume and exit lines of the disk guard are recomputed when the volume size changes, so an online resize moves them. The guard keeps its state and its two-sample exit count, and logs the change.

The staging volume pairs with snapshot import with --staging and HTTPS snapshot import. The disk guard is described in disk watermarks and block sealing.

Do I need to do anything after upgrading?

  • New receipts use the compact form at once; old ones stay as they are and still read.
  • Compression of closed segments is not automatic in the PR description: run xone db compact-history on a stopped datadir to freeze the closed chunks. Back up first.
  • Size-capped rotation applies to new segment files.
  • Measure before and after on your own node, for example with xone db usage or measure-node.sh, and keep the numbers if you want to compare later.

Frequently asked questions

Does xOne compress its history files?

On main, yes: closed history chunks can be rewritten as zstd-compressed XSEG version 2 with xone db compact-history, and readers accept both versions.

Will compact receipts change RPC answers or the receipts root?

No. The bloom is rebuilt from the logs, and the reader returns byte-identical consensus receipts.

Can I put snapshot downloads on a different disk?

Yes. --datadir.staging moves the import and download buffer to another volume.

How much disk does this save?

Not reported. Neither the pull requests nor we have measured it yet.

Sources