DIFD4

How this node is configured

DIFD4 exists partly to test whether a full Radix validator can be run on much less disk than is usual, without giving anything up. It runs a build of the standard node with a small patch that exposes some of RocksDB’s own settings as environment variables. The figures below are measured on this node, not estimated.

The patch changes settings only. It adds no new storage format and needs no resync, reformat or fresh snapshot: RocksDB records the block size and compression per file, so existing files stay readable and are converted as they are rewritten by normal compaction. That matters because it means an existing node can try this and roll back.

What changed

The single biggest lever turned out to be block size, not the compression algorithm. At 4 KiB a compressor has very little context to work with; at 64 KiB it has sixteen times as much. That is also why filesystem-level compression looks so effective on a standard node — it gets to work on 128 KiB extents rather than 4 KiB blocks.

Capping the write-ahead log matters more than it sounds. The default is no limit, and RocksDB then keeps log files back to the oldest unflushed memtable — so one rarely-written column family can pin everything newer. On the standard nodes measured here that had grown to 22 GB and 29 GB. Moving the log to its own directory also keeps it off the same spindle as the data.

Result, measured 22 September 2026

Both nodes hold the same chain at the same height, with transaction indexes disabled on each, so the comparison is like for like. Disk figures are in GB (10⁹ bytes, as df reports them); memory figures are in GiB (2³⁰ bytes) and are resident set size. The ledger has held at 287 GB for a week, so it is a settled figure rather than a snapshot of a conversion in progress.

The daily swing is arguably the more useful result than the size. A standard node’s disk use rises and falls by about 18 GB every day as the uncapped write-ahead log fills and is truncated; DIFD4’s moves by under a gigabyte. A node whose disk demand is predictable to within a gigabyte can be sized honestly.

This patch does not reduce memory. An earlier version of this page said it did. That figure was taken before DIFD4 joined the active set; taking part in consensus added roughly 5 GiB, and DIFD4 now uses about as much memory as a standard node. It runs on a 16 GB machine with a 13 GiB cap, with no restarts and no out-of-memory events.

Caveats, because this is a work in progress. DIFD4 has only been in the active validator set since 17 September 2026, so the evidence on long-run behaviour under load is still thin. An earlier version of the patch that set only bottom-level compression saved barely 1% — nearly all of the gain here comes from doing all levels together with the larger block size. Anyone reproducing this should measure their own node rather than trust these numbers.

Correction, 22 September 2026: an earlier version of this page gave DIFD4’s ledger as 266.8 GB and the saving as 33% (37% in total). 266.8 was the same figure in GiB, compared against a standard figure in GB. Measured in the same unit, the saving is 28% on the ledger and 32% in total.

If you run a Radix node and want the details, the contact route is the validator list linked above.