IOTA: IRI 1.6.0 with local snapshots out now!

  • Friday, 11 January 2019 16:39
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_DEPTHLOCAL_SPAPSHOTS_PRUNING_DELAYBy 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_SYNCEDUnsynced nodes perform snapshots less frequently, so they can focus resources on getting up to speed first:LOCAL_SNAPSHOTS_INTERVAL_UNSYNCEDYou can read more about using local snapshots in the documentation.Operating public-facing nodes with local snapshotsBy 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 nodePreviously, 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 listAs 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:addNeighborsgetNeighborsremoveNeighborsattachToTangleinterruptAttachToTangleYou 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 nodeThe 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 neighborsThe 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 configurableAnother 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 documentationQuite 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.Database layer refactoringAPI redesign and refactoringConfiguration and other bug fixesRelease notesThe 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 #981Feat: Introducing the GarbageCollector of local snapshots #995Feat: Fixes + Improvements for IRI that are required for local snapshots #1095Feat: Introducing several executor services for IRI #1131Activate Local Snapshots #1172Introducing a repair mechanism for corruptions in the ledger database #1174Introducing a parameter validation for the local snapshot config parameters #1175Introducing a dedicated Transaction Requester Background Worker #1178Feat: Added an option to fast forward the ledger state #1196Perf: Massively improved the performance of the replayMilestones method #1197Increase rescan performance of old milestones after IRI restart #1204Refactor: made boolean parameters receive a value #1224Feat: Disable snapshot logic completely if disabled in the config #1228Fix: Node requested old transactions forever #1235Feat: Write snapshot files to temp files first #1256Spent addresses are updated on local snapshot nodes #1258, #1263Spent addresses are present on local snapshot nodes #1266Report local snapshot node transaction history via getNodeInfo #1264Change the minimum value for LOCAL_SNAPSHOTS_PRUNING_DELAY #1267Thanks!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.IRI 1.6.0 with local snapshots out now! was originally published in IOTA on Medium, where people are continuing the conversation by highlighting and responding to this story.

Additional Info

Leave a comment

Make sure you enter all the required information, indicated by an asterisk (*). HTML code is not allowed.

Disclaimer: As a news and information platform, also aggregate headlines from other sites, and republish small text snippets and images. We always link to original content on other sites, and thus follow a 'Fair Use' policy. For further content, we take great care to only publish original material, but since part of the content is user generated, we cannot guarantee this 100%. If you believe we violate this policy in any particular case, please contact us and we'll take appropriate action immediately.

Our main goal is to make crypto grow by making news and information more accessible for the masses.