The IOTA network observed a significant increase in the activity, credit by developers, who are implementing solutions, based on the Tangle technology. Considered as a challenge by the IOTA Foundation, this enlargement of the database’s size and create some trouble to nodes, which possess limited hardware resources. As some global snapshots were taken on regular basis, it’s been decided that the growth of the ledger’s size isn’t that practical, because storing transaction’s history is forming an empty database.
Next on the Roadmap – Local Snapshots
In order to make some steps to solve the above-mentioned problem, IOTA announced they’re launching a new feature, called Local Snapshots. Currently, the new implementation has been tested internally and the metrics of its behavior have been collected for analyze.
There will be some changes due to this new feature. One of them would be the decrease of the disk space requirements, which will be significantly reduces, as well as the maintenance (since there won’t be any global snapshots occurring). Another important consequence would be the synchronization time, needed for each node. It will be also diminished to some minutes, which will allow syncing on small local snapshot files, instead of using large bootstrap files.
Understanding the technology
To explain the principle of how these snapshots work, first let’s take a look at IOTA’s Tangle. At first, this data structure wasn’t really certain, but with time it gained the user’s trust. The further we look at the past, the more we realize it’s less likely for unconfirmed transaction to become part of a consensus. The latest examples of pending transactions and the current state of the ledger have both formulated this understanding.
So how does the Local Snapshots work?
Pruning old transaction history and persisting the balances
First, an anchor point is chosen – a confirmed transaction which is mature enough, then all other transactions are directly referred by the primary one to get pruned, so the database is cleaned up. Before the comb-out, the balances affected by the old transactions are checked and recorded in a local snapshot file – the current state of the ledger which then becomes a new starting point.
Faster synchronization for new nodes
Lacking the global snapshots, new nodes now can’t easily retrieve full transaction history. Even if they could do it, it will take a long time to catch up with the latest state of the ledger. So, to remedy this, local snapshot files are also used as starting point for the new ones.
Bootstrapping a new node with local snapshot requires more details about the balances within those files. New nodes which are syncing, need to know when to stop solidifying a chain of transactions and consider it done. To do so, a solid entry points list is stored with hashes of transactions with approvers that did not become orphaned. Once the node reaches one of the hashes in the list, it stops asking for approval and marks it solid, enabling local snapshot files to be used as bootstrapping mechanism for quick syncing.
Local snapshots hopefully will solve the problem with the storage, that arise from the growing rate of IOTA adoption, as well helping the synchronization and setup of new nodes.