DIFD4
A Radix network validator, and a sister node to DoItForDan running on separate infrastructure with a different provider and location, so the two do not share a failure.
Status: operating normally
- Validator fee
- 15% — set when the validator was created, so it has applied from the first epoch. No pending change.
- Delegated stake
- Accepted — open to anyone.
- Registered
- 17 September 2026.
- Infrastructure
- A dedicated node on its own host, independent of the operator's other validators.
How this node is configured
DIFD4 exists partly to test whether a full Radix validator can be run on much less disk and memory 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
| Setting | Standard node | DIFD4 |
|---|---|---|
| Compression | Snappy, and none at the bottom level | zstd on all levels, 26 of 27 column families |
| Block size | 4 KiB everywhere | 64 KiB on the 11 archival families, 4 KiB on the rest |
| Write-ahead log | in the ledger directory, size unlimited | separate directory, capped at 1 GiB |
| Block cache / open files | defaults (max_open_files=-1) |
2 GiB cache, max_open_files=20000 |
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 17 September 2026
| Standard node | DIFD4 | Change | |
|---|---|---|---|
| Ledger (SST files) | 400.2 GB | 266.8 GB | −33% |
| Write-ahead log | 22.2 GB | 0.7 GB | −97% |
| Total on disk | 422.4 GB | 267.5 GB | −37% |
| Memory in use (resident) | 11.7–14.7 GB | 9.7 GB | — |
| Missed proposals | 0 | 0 | — |
Both nodes hold the same chain at the same height, with transaction indexes disabled on each, so the comparison is like for like, and both memory figures are resident set size. DIFD4 runs on a 16 GB machine with a 12 GB cap; 8.7 GB of its total is the process itself and the remainder is filesystem cache, which the kernel reclaims on demand. 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. The ledger figure is also still falling as older files are rewritten, so 266.8 GB is an upper bound rather than a settled number. And 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.
If you run a Radix node and want the details, the contact route is the validator list linked above.
Why another validator
The Radix active set is the top 100 registered validators by delegated stake. Several of the lowest-staked places in that set are held by nodes that are not keeping up — missing proposals, or running old versions. Because the set is fixed at 100, those places are not free: a validator that misses its turn slows the round for everyone.
Adding a well-maintained node with enough stake to enter the set displaces the weakest place in it. That is the reason this node exists, and it is why the operator has worked to get the running cost of a node down — it makes doing this affordable more than once.