Network node operators in IOTA previously had to store the full transaction history, swelling the size of their operations.
The IOTA Foundation has addressed these problems with the IRI 1.6.0 which will introduce local snapshots to the network.
This feature will allow operators to run the node without storing the entire transaction history of the IOTA blockchain.
Iri Team Supports Nodes
The local snapshots will help the nodes in running their operations more efficiently. The Foundation’s Jakub Cech noted in the blog announcement:
“This means faster synchronization, lower system resource requirements, and no more waiting for global snapshots to prune the database.”
The majority of logic behind this feature was implemented by Hans Moog, with testing and review support from the entire IRI team.
Cech informed that the IRI 1.6.0 feature is not just about local snapshots. He said that it would make running nodes an overall better experience.
How Can Node Operators Get the Feature?
IOTA node operators simply need to download the latest version of the network and upgrade the node.
Once done, the local snapshots feature will be enabled by default with the most reasonable configuration values.
By default, the nodes will be allowed to store about 30 days of transaction data.
The nodes can change the settings of the feature like LOCAL_SNAPSHOTS_DEPTH, LOCAL_SPAPSHOTS_PRUNING_DELAY, LOCAL_SNAPSHOTS_INTERVAL_SYNCED, LOCAL_SNAPSHOTS_INTERVAL_UNSYNCED among others.
The IRI 1.6.0 is the successor of 1.5.6 which was released before Christmas last year.
With this update, the performance on a synchronizing node will now improve. Earlier, the computational demands of unsynchronized nodes were higher. The update has removed redundant hashing and validation.
It also added a default remote API limit list which will ensure that the nodes are not spammed with outside party requests.
The update also features a getNodeInfo API call that retrieves the list of features enabled on a node, better synch for TCP neighbors and configurable PearlDrive threads.
The team will now work on solidification improvements, database layer refactoring, bug fixes and API redesign and refactoring.