This optional (but highly recommended) Session Node update replaces how oxend stores its data. It adds a new SQLite-based storage backend that keeps the entire blockchain and all of oxend's other databases in a single file. It also adds an optional "light node" mode, which keeps only recent block history and brings a Session Node's disk use down from roughly 20GB to under 2GB. It also cuts oxend's memory use, makes syncing more reliable, and goes with new required versions of Storage Server (2.12.0) and Session Router (1.1.0).
Existing nodes don't need to do anything special to upgrade: an existing installation keeps using its current LMDB blockchain database and is not moved to the new SQLite backend. Switching to the new storage, or to light mode, requires either a resync or downloading a new database snapshot (see below), and is up to the operator.
Storage Server 2.12.0 and Session Router 1.1.0 are required
oxend 11.7.0 only accepts pings from Storage Server 2.12.0+ and Session Router 1.1.0+. With an older version of either, oxend logs an "Outdated …" error and stops sending uptime proofs, which will get the node decommissioned. Upgrade all three together. Installing the updated packages from the apt repository handles this for you.
See the Storage Server 2.12.0 and Session Router 1.1.0 release notes for what changes in those.
oxend still requires Lokinet (0.9.14+) alongside Session Router for now. No new ports are needed for this release.
New SQLite storage backend
Until now oxend has stored the blockchain in LMDB, with service node rewards in sqlite.db and ONS in ons.db. 11.7.0 adds a new backend that keeps all of it (blocks, transactions, service node state, rewards and ONS) in a single SQLite database, oxen.db, updated together inside the same transactions.
- New data directories use SQLite by default. A fresh install creates
oxen.dband does a full sync, as before. - Existing installations keep using LMDB. If
lmdb/data.mdbis present (andoxen.dbis not), oxend carries on with LMDB,sqlite.dbandons.dbexactly as before. If both are present,oxen.dbis used and the LMDB database is left alone (oxend logs a warning saying so). - A freshly synced full node is about 16GB under SQLite, compared to 18GB under LMDB (20–22GB for an LMDB node that has been running for a while). A full sync from scratch is roughly 10% slower than LMDB.
Light nodes: keep only recent history
A node using the SQLite backend can now keep only a recent window of block history instead of the whole chain, while still fully validating new blocks, taking part in quorums, signing and serving wallets. Most of the chain no longer matters for consensus, and a Session Node keeping two weeks of history needs about 1.4GB of disk instead of 16–22GB.
Light and full nodes are fully compatible with each other and with 11.6 nodes. Each node now tells its peers how much history it keeps, and a syncing node picks peers that actually have the blocks it needs, so a network mixing full and light nodes syncs correctly.
Setting up a light node from a pruned snapshot
To switch an existing node to a pruned SQLite without resyncing from scratch, download a pruned snapshot. For a single SN node, the new oxend-download-sqlite script (included in the oxend deb package) can do this. The STF publishes daily snapshots of all three database types (lmdb, sqlite archive, and sqlite pruned) at https://public.session.foundation. To install the pruned one:
sudo oxend-download-sqlite https://public.session.foundation/oxen/pruned/oxen.db
The script stops oxen-node (and the storage server), replaces /var/lib/oxen/oxen.db, and restarts them. It does not delete the old lmdb/ directory: once oxen.db is in place that directory is unused and can be removed to free up the space.
Alternatively, if you are using a multi-node setup or non-standard paths, you can download the pruned oxen.db file into your /var/lib/oxen/node-NN (or /path/to/oxen/data), for example using wget. (You can download before restarting if the current node is still using lmdb).
You can determine the database being used from the oxen-node startup logs: look for lines such as:
[global:info|cryptonote_core/cryptonote_core.cpp:984] Loading sqlite blockchain from "/var/lib/oxen/oxen.db" ...
[global:info|cryptonote_core/cryptonote_core.cpp:1081] The blockchain database keeps the last 10080 blocks of history
where the first indicates it is using the sqlite, and the second indicates a pruned database (10080 = 2 weeks history, in this case).
Once a node is successfully restarted using the oxen.db database, you can remove the lmdb/, ons.db, and sqlite.db files from your oxen data directory (/var/lib/oxen by default).
Syncing a pruned node from scratch
If you prefer to sync your node from scratch, you can use the history=2w in oxen.conf (or --history=2w on the command line). Other durations (3d, 12h, …), a block count, or full also work; the minimum is 720 blocks. Two weeks is what we suggest for a Session Node that wants to save space (going shorter has only tiny additional savings).
- The setting is stored in the database itself, and if the
history=option is not given at all, it simply keeps using whatever history is indicated in the database (and thus you don't need to worry about the option at all when starting from a pruned snapshot). - Lowering the history on a node with more history drops the older blocks in the background after startup, in small chunks, so the node starts and runs normally while the trim proceeds. The freed space is given back by the compaction at the next shutdown.
- Light mode requires the SQLite backend: LMDB's write performance becomes poor when large amounts of data are deleted from it.
No conversion from LMDB
oxend does not support converting between database types. To turn an existing LMDB node into a light node, either delete the lmdb/ directory and resync with history=2w in oxen.conf, or install the 2-week snapshot, as described above.
Lower memory use
Service node state archives (a full snapshot of the service node list every 10,000 blocks, going back two years) were all held in memory and rewritten as a single large database value whenever one was added. Each archived state is now stored separately and compressed, and only read when needed. Together with sharing unchanged data between loaded states, this drops a mainnet node's memory use after startup by about 100MB.
Memory usage reduction may appear larger when using sqlite because of how LMDB allocated access to the LMDB database. This difference is somewhat misleading, however: LMDB only used that extra memory as cache when it was available on the system, and such memory was available to other processes that needed it. With sqlite, that memory doesn't show up in the oxend process at all but rather is simply part of the general OS disk cache.
Syncing improvements
- The rewards database no longer copies its entire table on every block, improving performance (especially when syncing blocks).
- Fixed a sync bug where peers were being dropped mid-sync with "returned not all requested objects" errors, caused by two block requests going out to the same peer at once.
- The compiled-in list of known-good block hashes now runs to height 2,215,424 (it previously stopped at 496,896, years ago). Blocks covered by the list skip pulse signature verification and some transaction checks, which speeds up syncing from scratch.
- The "Synced N/M" progress line now reports the actual sync rate over the last minute (it previously reported only processing speed, which could be several times higher than actual progress), and the "Synced N blocks in T" summary at the end of a sync now measures from when the sync actually started.
- During long startup work (such as catching up the service node list and rewards after a restart), oxend now reports its progress to systemd and extends the start timeout, rather than risking being killed by systemd's default 90-second limit.
Upgrade notes
- On first startup, an existing LMDB node updates the table layout of its rewards database (
sqlite.db) and moves its stored service node archive into a new per-state table. This is a one-time update, not a rescan. It does not convert the blockchain itself: the node keeps running on LMDB. sqlite.dbandons.db(in LMDB mode) andoxen.db(in SQLite mode) now use SQLite's WAL mode, so-waland-shmfiles will appear next to them. This is normal.
Distribution support
Debian 11 ("bullseye") and Ubuntu 20.04 ("focal") are no longer supported: both have reached end of life status and no longer receive security updates. Packages are provided for Debian 12, 13, testing and unstable, and for Ubuntu 22.04, 24.04, 26.04 and 26.10. Operators still on Debian 11 should upgrade to at least Debian 12, if not Debian 13.
Other changes
- Fixed L2 proxy-using nodes going offline when Arbitrum stalls. If the L2 chain stopped producing blocks, nodes using an
l2-oxend-proxystopped getting height updates and, after an hour, stopped sending uptime proofs. The proxy now sends a refresh every 10 minutes even when the height hasn't changed. Nodes talking to an L2 provider directly were not affected. - Removed a spurious BLS key mismatch warning logged while syncing the part of the chain from before BLS keys existed, and a flood of "out of sync with batching database" errors when syncing the earliest part of the chain.
Upcoming hard fork
This release does not include a mainnet hard fork. The next hard fork, including larger pulse quorums (25 nodes, with 16 of 24 validator signatures required, up from 7 of 11), are currently running on testnet and will be scheduled for mainnet in a later mandatory update.
Full Changelog: v11.6.1...v11.7.0
Updating service nodes
For Session Node operators using Debian 12+ and Ubuntu 22.04+, the upgraded packages are available from our APT repository (the old deb.oxen.io address continues to work). Upgrading the session-service-node package pulls in the required Storage Server and Session Router updates. Static binaries for other users are available below.
Signature of static build files
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Signed SHA256 hashes of release files. These are signed using Jason's GPG
key available at:
- the oxen-io/oxen-core repository, at /utils/gpg_keys/Jason.asc
- OpenPGP key servers (Jason Rhinelander <jason@session.foundation>, C4992CE7A88D4262)
- https://deb.session.foundation/public.gpg
- https://imaginary.ca/public.gpg
- https://github.com/jagerman.gpg
b5c311a08da169eeae5a34a67fef264a05ffe10bff16f17656f8adfb28a92d5b oxen-linux-x86_64-11.7.0.tar.xz
3b9f985a0c1e0c176be1b6b548bdb046049f333b4f877ac1c4aef4f13150f0ee oxen-macos-arm64-11.7.0.tar.xz
59819c0dcbe6c6bbf61effd1dd1c6b6aa726a2a3655ba1fddbd80eeb80b65279 oxen-win-x64-11.7.0.zip
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEMCXxeJf0bLVTgXjKQB55DgYLsA4FAmrRepoACgkQQB55DgYL
sA6i5RAAgEx5QbfxwwCMcH//dHAmapmy8n01UnmNeawd7Y9UvMI9qz0cyGqD33wA
dvKYw1/L4yjU2rszA3WWwMXY3VU9gde6Nh3WiLBAKGpJhAgEKa2fRnCU4zjAKxk3
mOcq/RVEQJh6AMeVnShG238oWw3ric9U+Mi5HEn0gVvWOm7x8D3XEwGijtYnuO1T
vjP+c3Z/uuNV1B+M25Mcd/soNTx3AcZhJehfD/rV3Tz97/wig1EUhX7/hC6oJw0G
bHH17DGFEyvijITGUA3D7BrO4VLXgoimmGwD2P+xqSDsFcRJYzBgcDSdrYy79f4K
X2o5Vw6Z5RHOXzn0ALtmLeKrDYI7Dv2t/EOElqcf6r4+01jR+RzfP+WjPlknf4e8
o+eCLfzUSXju4tq9rqyslfW890ow876paGhyD7y1BVUH1wyv/r56hnxcFkX44C2g
Qf0DLa+dmP2TEjSnw9Y5wNLtww+6/FQnJ5+lU8w+0WG5MVnDcBac+kkXrA+JTo+6
k83LycLb4Q0q9dhxQwF0iMsZfnWJhAYiNfNNCmgbuZ3sCrZB2y5hbGkTTjx184WK
MTgnm0mVu2NsAwwAWWR2jvslmAIl2dZ/5uEkkcJvMQF2yFcO6ZetKj30P+nnBdhE
yd67lJvUbinHz5SAIPYoPZ/g7SqZjnKwGsyyixB/Qq3r2a8pIAI=
=t5Ky
-----END PGP SIGNATURE-----