We know you have all been waiting for this for quite some time. Finally we have finished implementing local snapshots, a feature that allows you to run your node without storing the full transaction history. This means faster synchronization, lower system resource requirements, and no more waiting for global snapshots to prune the database.

While Hans Moog implemented most of the logic behind this feature, reviewing and testing local snapshots has been a huge effort for the whole IRI team.

IRI 1.6.0 is not just about local snapshots. We have been working on many other improvements as well, which we believe will make running a node a much better experience from now on!

What do I need to do?

It’s simple. You just download the latest version and upgrade your node. Local snapshots are enabled by default, with what we believe are reasonable configuration values.

You can of course change things up as you like. For example, you can control how much data the node stores using the following two configuration options:

LOCAL_SNAPSHOTS_DEPTH

LOCAL_SPAPSHOTS_PRUNING_DELAY

By default, nodes will store around 30 days worth of transaction data.

You can also change the interval at which synced nodes perform local snapshots using:

LOCAL_SNAPSHOTS_INTERVAL_SYNCED

Unsynced nodes perform snapshots less frequently, so they can focus resources on getting up to speed first:

LOCAL_SNAPSHOTS_INTERVAL_UNSYNCED

You can read more about using local snapshots in the documentation.

Operating public-facing nodes with local snapshots

By default, nodes with local snapshots enabled store around 1 month worth of transaction data.

If you are operating a public node and want to have LOCAL_SNAPSHOT_PRUNING enabled, please stick to at least the default value of LOCAL_SPAPSHOTS_PRUNING_DELAY (40000) or higher.

What else does IRI 1.6.0 contain?

A lot. Many of the improvements were already shared in version 1.5.6 right before Christmas, but it’s worth highlighting some of them here:

Greatly improved performance on a synchronizing node

Previously, the computational demands for a node that was not yet synchronized were very high. We have made significant improvements by removing redundant hashing and validation of replies in the gossip protocol.

Default remote API limit list

As a security measure for nodes, we are now limiting some remote API calls by default. This ensures your node doesn’t get spammed with request from outside parties that know its address. Calls limited by default are:

addNeighbors

getNeighbors

removeNeighbors

attachToTangle

interruptAttachToTangle

You can make these calls available remotely by defining a different REMOTE_LIMIT_API in the configuration file.

Retrieve a list of features enabled on the node

The getNodeInfo API call now returns a list of features that a node has enabled. This allows you to determine, for example, if the node supports remote proof of work!

Improved synchronization for TCP neighbors

The synchronization of nodes neighbored with TCP could get stuck in certain scenarios. This has now been fixed by our community member GJEEE!

PearlDiver threads are now configurable

Another contribution by our community member, CodeMonkeySteve allows you to control PearlDiver threads better. This is useful if you want to utilize as many cores as possible on a dedicated node server, for example.

Code cleanups, refactoring and documentation

Quite a bit of effort went into cleaning up some of the code base and adding documentation. Shout-out goes to our community member #ChEfKoCh (legacycode) for help with that!

What’s next?

We have quite a few things we want to focus on next:

Solidification improvements — simpler and more performant solidification logic.

— simpler and more performant solidification logic. Database layer refactoring

API redesign and refactoring

Configuration and other bug fixes

Release notes

The following list is truncated for brevity. See the release page for a full list.

Non-local snapshot changes that were also included in IRI 1.5.6 are listed under the 1.5.6 tag.

Feat: added config variables for local snapshots #981

Feat: Introducing the GarbageCollector of local snapshots #995

Feat: Fixes + Improvements for IRI that are required for local snapshots #1095

Feat: Introducing several executor services for IRI #1131

Activate Local Snapshots #1172

Introducing a repair mechanism for corruptions in the ledger database #1174

Introducing a parameter validation for the local snapshot config parameters #1175

Introducing a dedicated Transaction Requester Background Worker #1178

Feat: Added an option to fast forward the ledger state #1196

Perf: Massively improved the performance of the replayMilestones method #1197

Increase rescan performance of old milestones after IRI restart #1204

Refactor: made boolean parameters receive a value #1224

Feat: Disable snapshot logic completely if disabled in the config #1228

Fix: Node requested old transactions forever #1235

Feat: Write snapshot files to temp files first #1256

Spent addresses are updated on local snapshot nodes #1258, #1263

Spent addresses are present on local snapshot nodes #1266

Report local snapshot node transaction history via getNodeInfo #1264

Change the minimum value for LOCAL_SNAPSHOTS_PRUNING_DELAY #1267

Thanks!

Big thanks go to our community for your patience while we finalized this feature and to all the RC testers who gave us feedback on the different builds. You made this huge milestone for IRI possible.

Another big thanks goes to the whole IRI team for their great efforts!

If you have feedback or questions, please join the discussion on the #iri channel of our Discord.