Stealth Development Blog Series #35: Major Improvements to RAM Efficiency
March 8, 2026
Overview
Stealth is proud to announce a significant update focused on reducing the RAM footprint of the reference client, “StealthCoind”. This update (v3.3.0.0) represents an immediate reduction of 57.6%, going from 15.1 GB to 6.4 GB of RAM requirements. Additionally, boot times for the client have been reduced by about 65% by this update.
Getting well under the 12 GB threshold represents a potential significant savings in server costs. For example, the price of a VPS at OVH, an excellent hosting provider, nearly doubles from $6.75/mo to $12.75/mo when going from 12 GB of RAM to 24 GB.
Please note that the transaction database needs to update when you upgrade to v3.3.0.0. This could take anywhere from 2 to 5 hours depending on your server. After the database upgrades, boot times will be much faster.
50-Year RAM Projection
The following table shows a 50-year projection of RAM usage:
Stealth is proud to announce a significant update focused on reducing the RAM footprint of the reference client, “StealthCoind”. This update (v3.3.0.0) represents an immediate reduction of 57.6%, going from 15.1 GB to 6.4 GB of RAM requirements. Additionally, boot times for the client have been reduced by about 65% by this update.
The following table shows a 50-year projection of RAM usage:
Year
Total Blocks
Old v3.2 (GB)
New v3.3 (GB)
Savings (GB)
Savings (%)
0
32,846,000
15.1
6.4
8.7
57.6%
1
39,153,200
17.4
7.0
10.3
59.6%
2
45,460,400
19.6
7.6
12.0
61.1%
3
51,767,600
21.9
8.2
13.6
62.4%
5
64,382,000
26.4
9.5
16.9
64.2%
10
95,918,000
37.7
12.5
25.1
66.8%
15
127,454,000
48.9
15.6
33.4
68.2%
20
158,990,000
60.2
18.6
41.6
69.1%
25
190,526,000
71.5
21.7
49.8
69.7%
30
222,062,000
82.8
24.7
58.0
70.1%
35
253,598,000
94.0
27.8
66.3
70.5%
40
285,134,000
105.3
30.8
74.5
70.7%
45
316,670,000
116.6
33.9
82.7
70.9%
50
348,206,000
127.9
36.9
90.9
71.1%
Notably, the updated client can run for nearly more 30 years before a server upgrade beyond 24 GB RAM is required.
An important feature of this projection is that memory savings increase over time, with a 71% savings after 50 years. The reason for this improvement is that simply running the client has a fixed RAM overhead of 3.18 GB. As the chain grows, the savings from slimmer block indices compound, while the fixed overhead remains constant.
What Changed, and Why
The Block Index
RAM needs have been reduced by moving indexed blockchain data to disk.
While the entire blockchain lives on disk as a flat file database, block records are stored in arbitrary order, corresponding to the order in which the client received each block. Upon receiving a block, the client simply appends it to the flat file without any further organization.
Organization of the blockchain is represented by so-called “block indices”. Essential block index information is: (1) the block’s unique identifier (the cryptographic hash of the block), (2) a pointer to the previous block, (3) a pointer to the next block, (4) the flat file in which the block data is stored, and (5) the position within that file where the block data is stored.
The latter two pieces of information give the block index its name, as it serves as an index to look up the raw block data. The pointers represent the structure of a blockchain in that the entire chain can be visited by moving from one pointer to the next.
How Block Indices Got Heavier Over Time
Over the years, developers (including myself) found it convenient to add information to block indices, which are loaded into RAM. To understand how this happened, it helps to know a little about Stealth’s history.
Some fields, like the block time (nTime) and a value called hashMerkleRoot, were likely added early on for convenience. The block time is part of the raw block data, and hashMerkleRoot is calculated from the transaction data in the block. Storing hashMerkleRoot alleviates the necessity of a computationally expensive calculation when validating new transactions.
Stealth is derived from a proof-of-stake (PoS) coin, with roots going back to the original PoS coin, PeerCoin. The PeerCoin developers added a lot of derived information to block indices to reduce the computational burden of validating new PoS blocks. These fields are highly technical, with names like nStakeModifier, prevoutStake, and nFlags.
In 2021, Stealth underwent what was probably the most drastic consensus protocol upgrade ever performed on a live chain, moving from PoS to what we called “Quantum Proof-of-Stake”, or qPoS. We later renamed qPoS to “Junaeth”, because people got confused by the term “Quantum” — a term we took from computer science, which has a different meaning from its use in physics.
The qPoS upgrade saw the addition of about 48 bytes of mostly derived data. These fields are called nTxVolume, nXSTVolume, nPicoPower, and vDeets. The fields nTxVolume and nXSTVolume are needed primarily in applications that summarize blockchain data, such as explorers.
All told, each block index held a minimum of 288 bytes of data across 26 different values. While each block index is not that large, Stealth at the time of writing has nearly 33 million blocks, meaning the in-memory block indices took up a minimum of 9.5 GB of RAM.
The Card Catalog Analogy
A library card catalog serves as a good analogy for what changed. Previously, every card in the catalog had not only its title and location in the stacks (which aisle it was on and the shelf within that aisle), but also the year it was published, number of pages, type of book (novel, textbook, etc.), list of authors, number of words, and so on. Now each card holds only its title, location in the stacks, and Dewey decimal number (so that it can be put in proper order next to others on the same shelf).
In-memory block indices have been modified to require only the 5 essential components described above (block hash, file number, position in the file, and two pointers), totaling just 32 bytes per block. The information that was removed from memory has always lived on disk as well, and is now retrieved from disk when needed.
Fortunately, most of these values are seldom needed during normal execution of the client, so performance is not noticeably affected.
The Block Height Exception
Block height is an exception in that it is needed quite frequently. However, reading the height from disk is unnecessary most of the time. The reason is that most of the code needing block height steps through one contiguous block at a time in a loop. So, instead of looking up the height from disk, these loops now keep a counter that is initialized to the height of the first block visited, and incremented or decremented as the code steps through the blocks.
What Prompted the Upgrade Now?
These improvements have been intended for years. The decision to act was ultimately driven by looking at server bills and knowing that a memory upgrade would save roughly double the server costs within a year. While these costs might not be large for any individual running a node, the upgrade represents a significant savings for the Stealth community as a whole.
The impending 16 GB threshold was a clear catalyst to prioritize the work. The 16 GB boundary sits between “affordable” and “mid-range” for most VPS providers, and the old client would have crossed it within approximately one year. Acting before that boundary was reached was the right time to deliver this upgrade.
Looking Ahead
The memory reduction improvements represented by this update will make Stealth much more viable over the following decades by keeping server costs down for those wishing to run full nodes. These reduced costs should promote building on the Stealth chain, and lower the barriers to continued Stealth adoption and development.
The Block Index
RAM needs have been reduced by moving indexed blockchain data to disk.
While the entire blockchain lives on disk as a flat file database, block records are stored in arbitrary order, corresponding to the order in which the client received each block. Upon receiving a block, the client simply appends it to the flat file without any further organization.
Over the years, developers (including myself) found it convenient to add information to block indices, which are loaded into RAM. To understand how this happened, it helps to know a little about Stealth’s history.
A library card catalog serves as a good analogy for what changed. Previously, every card in the catalog had not only its title and location in the stacks (which aisle it was on and the shelf within that aisle), but also the year it was published, number of pages, type of book (novel, textbook, etc.), list of authors, number of words, and so on. Now each card holds only its title, location in the stacks, and Dewey decimal number (so that it can be put in proper order next to others on the same shelf).
Block height is an exception in that it is needed quite frequently. However, reading the height from disk is unnecessary most of the time. The reason is that most of the code needing block height steps through one contiguous block at a time in a loop. So, instead of looking up the height from disk, these loops now keep a counter that is initialized to the height of the first block visited, and incremented or decremented as the code steps through the blocks.
These improvements have been intended for years. The decision to act was ultimately driven by looking at server bills and knowing that a memory upgrade would save roughly double the server costs within a year. While these costs might not be large for any individual running a node, the upgrade represents a significant savings for the Stealth community as a whole.
The impending 16 GB threshold was a clear catalyst to prioritize the work. The 16 GB boundary sits between “affordable” and “mid-range” for most VPS providers, and the old client would have crossed it within approximately one year. Acting before that boundary was reached was the right time to deliver this upgrade.
The memory reduction improvements represented by this update will make Stealth much more viable over the following decades by keeping server costs down for those wishing to run full nodes. These reduced costs should promote building on the Stealth chain, and lower the barriers to continued Stealth adoption and development.
Fast. Secure. Reliable.
Get the Stealthsend Desktop App
