The basic principle behind Local Snapshots is relatively easy to understand and can be divided into different aspects:

Pruning of old transactions and persisting the balances

We first choose a confirmed transaction that is sufficiently old and use this transaction as an “anchor” for the local snapshot.

We then prune all transactions that are directly or indirectly referenced by this transaction and clean up the database accordingly.

Before we clean the old transactions we check which balances were affected by them and persist the resulting state of the ledger in a local snapshot file, which is subsequently used by IRI as a new starting point.

Solid Entry Points (fast sync for new nodes)

While pruning old transactions is no problem for nodes that are already fully synced with the network, it poses a problem for new nodes that try to enter the network, since they are no longer able to easily retrieve the complete transaction history dating back to the last global snapshot.

Even if we assume that they are able to retrieve the full history by asking permanodes for the missing transactions, it would still take a very long time to catch up with the latest state of the ledger. This problem is not new and one of the reasons why a lot of node operators bootstrap their nodes with a copy of the database from another synchronized node.

To solve this problem, we use the local snapshot files not just as a way to persist the state of the node but also to allow new nodes to start their operations based on the exact same file (which can be shared by the community and the IF in regular intervals).

To be able to bootstrap a new node with a local snapshot file we need to store a few more details than just the balances:

First of all a new syncing node needs to know at which point it can stop solidifying a chain of transactions and just consider the subtangle solid. To be able to do so, we determine which one of the transactions that we deleted, had approvers that did not become orphaned and store their hashes in a list of “solid entry points”.

Once a node reaches one of those hashes it stops asking for its approvees and marks the transaction as solid (like the 999999….99 transaction after a global snapshot).

This enables us to use local snapshot files as a bootstrap mechanism to get a new node synced very quickly (within minutes), which at the same time is much easier to provide and retrieve than a copy of the whole database.

Seen Milestones (even faster sync)

While solid entry points allow us to stop the solidification process as soon as possible, it can still take a while to learn about all subsequent milestones that happened after our chosen cut-off point.

Since we want the local snapshot files to be a viable and efficient way of bootstrapping a new node we also save all subsequent milestone hashes in the local snapshot files, so that new nodes can immediately ask for missing milestones, without having to passively wait for their neighbours to broadcast them.

Permanodes

Since the pruning of data will be controlled by a simple configuration setting, it will now be possible to run permanodes that keep the full history of transactions, which has so far been impossible due to the fact that global snapshots were a network wide event.