Profile disk use

mentioned in merge request !297 (merged)

Note: Currently in translation for the forum.

Disk Storage Consumption of an Archive Node

Introduction

The storage demands of running a Duniter node pose a considerable challenge, particularly given its focus on modest hardware compatibility. This issue becomes even more critical for archive (and smith nodes), which are required to store the entire blockchain history from the genesis block onward.

Method

To provide an accurate estimate of storage requirements, I monitored the storage of a full archive node (target/release/duniter --chain=gdev --blocks-pruning=archive --state-pruning=archive). I recorded the imported block number and the node's storage usage every 30 seconds, maintaining this process consistently over several weeks.

Results

Figure 1 illustrates the relationship between the number of imported blocks and the corresponding disk space usage of the node. The data reveals a clear non-linear growth in storage over the observation period. On shorter time scales, this growth manifests as discrete steps, highlighting periods of sudden increases in storage consumption.

Disk space usage over time — **Figure 1**: Number of blocks versus disk space usage over the monitored period.

Figure 2 illustrates the distribution of the duration of these discrete steps in block numbers. The step durations are highly variable, with a noticeable predominance around 100 blocks (equivalent to 10 minutes).

Distribution of step durations — **Figure 2**: Distribution of durations of the steps observed in the disk space usage.

Figure 3 presents the evolution of the node's disk space usage, displaying both the recorded data and the fitted curve. The fitting assumes that the disk space at block 0 is approximately zero. To model the growth behavior, the data was fitted using the simplest continuous function that provided an adequate representation: a second-degree polynomial without a constant term. This function highlights the accelerating nature of storage requirements as the blockchain progresses.

Fitted disk space evolution — **Figure 3**: Evolution of disk space usage from node start fitted using a second-degree polynomial.

Prediction

I have not yet conducted a detailed investigation into the stepwise increase in storage usage, a behavior also observed in other chain nodes utilizing ParityDB. While this phenomenon does not directly influence the overall growth in storage size, its underlying cause remains unclear at the moment. They are likely attributable to either deferred file deletion at the database/system level or quasi-periodic compression of intermediate data structures at the node level. To clarify the source of this behavior, recording data from a node operating with RocksDB should provide some insights.

Based on the observed results, it is evident that disk space usage follows a non-linear trend. The limited data collected can be accurately fitted using a second-degree polynomial. Figure 4 presents the projected disk space usage based on this polynomial fit, alongside the propagated error margins derived from the covariance matrix of the fit. This provides a preliminary forecast of storage requirements while highlighting the uncertainty inherent in the current limited dataset.

Prediction based on fit and error propagation — **Figure 4**: Prediction of disk space usage after 6 years, including propagated errors from the covariance matrix.

Observations from the Polkadot network indicate that an archive node requires approximately 2,765 GiB of storage after 4.71 years of operation (stakeworld.io, Polkadot wiki). In contrast, our network remains largely inactive, with storage growth primarily driven by the operations necessary for forging empty blocks and maintaining basic network functions, such as UDs and certifications.

Given these conditions, our prediction of 500 ± 250 GiB of storage after 4 years—while based on limited data—appears plausible when compared to heavily utilized networks like Polkadot. This estimate offers a rough benchmark of future storage demands, especially when viewed alongside long-running networks such as Polkadot and Kusama, where higher activity levels contribute significantly to storage growth.

Conclusion

The currently available data results in a model with moderate predictive power for up to 2 years and low predictive power beyond that. However, it offers a reasonable estimate, especially when combined with the observed trends in Polkadot node storage requirements, indicating that over the next 3 to 4 years, storage demands are unlikely to exceed 1 TiB. This aligns with the targeted reference machine’s capabilities and fits within the current SSD size and pricing trends for modest hardware requirements.

To refine these predictions, ongoing monitoring of disk space usage on the active node will be crucial, particularly as network activity increases. A rise in transaction volume, especially with on-chain storage of transaction comments, could have a notable impact on future storage needs. By regularly updating the model, we can ensure more accurate forecasting as the network and its dynamics evolve.