Ledger pruning

Github issue: https://github.com/nanocurrency/nano-node/issues/1094

Ledger pruning is a mechanism to safely remove parts of ledger.

  • Current proposal is to allow optional pruning of ledger blocks down to confirmed frontier, frontier predecessor and pending blocks (send blocks to address 0 can be removed, since there can be no receive block generated from that address).
  • All mechanisms that involve pruning must not break the ledger.

Benefits: Reduce ledger size on disk and lower requirements for nodes joining the network.


I have a proposal that is related to this. I was thinking of creating another Github issue but maybe better to just leave my thought here since I don't really know if it's a valid approach.

I have been running a node stored on a RAM-disk for a few weeks with good results, for example, decreased bootstrapping time during the "checking of unchecked block phase". Problem is most people don't have enough RAM to do this. What about dividing the future Ledger into three database files instead of one. Then let the node owner distribute these files to the best available hardware, preferably via the config file. Support for different file sharing protols like NFS, SMB/CIFS.

  1. Latest most accessed blocks: Allow super fast access on NMVe drive or small RAM-disk.
  2. Normal pruned ledger: Store on SSD or HDD for medium speed but cheaper server storage.
  3. Full unpruned ledger history: Cheap cloud storage or NAS. Speed not very important.

Even if not running on a RAM disk this could probably improve the build-in file caching in Linux.

1 Like

Note that this would not do much against ledger spam attacks, because those could simply not receive the sends they create. I also did the math, and I believe simply not receiving the sends is more PoW per disk space efficient than opening new accounts for each send, so increasing the open block proof of work would not make sense as part of such a proposal.


Well, sometimes we need check of random block existence (i.e. confirm_req for representatives or block processor check if block exists), then need to access all databases

Restructuring the chains so that there is a receive chain and a send chain with automatic receives would fix the issue of pending blocks. Automatic receives would also prevent the side issue of "spam attack" where you just send an unrealistic amount of pending blocks to a known account so they can't properly use the account on a wallet.

1 Like