Update: The IOTA reference implementation (IRI) is deprecated with the Chrysalis network upgrade and will no longer work with the protocol changes. We recommend switching to the Hornet or Bee node implementation.

Next Snapshot: April 29, 2018 @ 16:00 UTC
Network Restart: April 29, 2018 @ 23:00 UTC

Snapshots are described briefly in our FAQ, but the IRI team wanted to take this snapshot as an opportunity to explain in more detail exactly how the process works, and how our node operating community can help. For an excellent overview of how to prepare and update for snapshots as an IOTA wallet user, please refer to Ralf’s excellent blog post from the previous snapshot. Specifically, we will cover:  

  1. What happens before, during, and after a snapshot; and
  2. How you as an IOTA node operator can prepare, validate, and update your nodes.

Two of the most compelling features of the IOTA protocol (among many!) are that (1) the network is totally permissionless, and (2) transactions are totally fee-free. What’s more, beyond the transfer of IOTA tokens, transactions may be used to encode arbitrary data without any token value at all, a fact which many network participants and developers rely on for their apps! The result for a node operator, however, is that the node database grows more-or-less unabated as people continue to transact, develop, test, and grow the network. This is a good thing. In fact, we are counting on it!  

Data-only transactions often account for somewhere between 90 and 95% of the database growth rate — this means disk space may quickly run out on smaller nodes. We are actively working on local snapshots so that in the not-too-distant future node operators will be able to more effectively manage their own database size. Meanwhile, we provide an interim solution to help keep the database lean and node operators in business without breaking the bank. This is of course: the snapshot.

The 5-step process to perform an IOTA snapshot.

The snapshot process consists of 5 steps, with Step 1 occurring approximately 2 weeks prior to the snapshot date (this is why we try to announce snapshots approximately 2 weeks in advance):

  1. Code freeze.While a snapshot might be as simple as pruning the database and re-starting the Coordinator, we generally take them as an opportunity to introduce a new version of the IOTA node software —IRI. Prior to announcing the release date, all of the latest improvements, patches, and bug fixes that have made it into IRI since the previous snapshot are “frozen” as a release candidate. During the remaining time leading up to the snapshot, the team is at work ‘round-the-clock to test and finalize the release candidate into the next version of IRI.
  2. Stopping Coo. At the moment the snapshot occurs, the Coordinator stops issuing milestones, and the network reaches consensus on the latest milestone issued. The database state at this point in time will be re-used once (A) the database has been preserved as a new initial state of all addresses with a positive balance, and (B) all of these account balances have been validated by the IOTA Foundation and the community.
  3. IF validation. Multiple participants from the IOTA Foundation run Snapshot.ixi on different nodes. This tool extracts all addresses with a current balance from the database. Once everyone independently confirms that the contents match, the snapshot itself is signed and ready for community validation.
  4. Spent addresses. As all IOTA users hopefully know by now, addresses may only be spent from once. To enforce this rule across snapshots, all addresses which have been spent during the current Epoch (time between the previous and current snapshots) are appended to a file called previous EpochsSpentAddresses.txt, which is included in the next database. This ensures that all addresses which have ever been spent from (since the genesis) can be accounted for and prevents address reuse.
  5. Community validation.Arguably the most important part of this entire process: you, our beloved community node operator! Once the results of all previous steps have been validated and pushed to GitHub by our team, this is your time to shine. We provide the following in the form of a Pull Request (PR), similar tovIRI#512:
  • the new IRI code
  • the next milestone index
  • snapshotMainnext.txt(+ signature)
  • previousEpochsSpentAddresses.txt(+ signature)
  • the snapshot timestamp — the time when the network will be resumed (used to filter old transactions, based on attachment time)
  • clear instructions for community members to validate the snapshot

All community members are requested to follow the instructions and validate the snapshot, and we wait 6 hours from the time the PR is pushed to allow enough time for community participation while minimizing overall network downtime. Finally, once everything is confirmed valid, Coo is restarted and begins issuing milestones once again — snapshot complete!

For new node operators— a snapshot is always a good opportunity to get involved and start running your own nodes! The following community-run guides provide comprehensive instructions for getting set up, and you won’t need any special instructions to use the latest snapshot as your starting point:

For existing node operators— you have 3 basic options:

  1. Do nothing. You are free to continue running your existing version of IRI, and as there are no breaking changes in this release, nothing much will change. While the Coordinator is offline, you won’t see any confirmations for about 6 hours. Additionally, you won’t be getting the tag fixes that are shipping with 1.4.2.4, so searching by tag on find Transactions will continue to behave oddly. We strongly advise every node operator to keep IRI up to date to ensure you have the latest performance enhancements and bug fixes.
  2. Migrate existing database. If you would like to keep your existing database and not lose transaction records due to the snapshot, you’ll need to follow some special instructions. Skip ahead to the next section for full details.
  3. Clean database. If you are running on a smaller VPS and short on disk space, you may want to remove your existing database entirely and start fresh. In this case, you should delete your mainnet db folder and replace iri.jar with the Mainnet v1.4.2.4 jar file which will be found on the releases page shortly after the snapshot.

Updated 2018–04–29 19:44 UTC

Keeping your existing database means you’ll need to rebuild the new version of IRI using the previous snapshot. This is possible by following these steps:

  1. Check out the v1.4.2.4_RC branch of the IRI repo, and build it from source as usual.¹
  2. Stop IRI.
  3. Replace your existing iri.jar file with the newly compiled iri-1.4.2.4_RC.jar.
  4. Download the 1.4.2.2 to 1.4.2.4 RC migration utility.
  5. Move it into the folder with the IRI .ini file.
  6. Optional: Backup the existing database (mainnet db).
  7. Runjava -jar iri-1.4.2.2-to-1.4.2.4_RC-db-migration-tool.jar.
  8. The migration utility will rescan transactions. Depending on your hardware setup, this might take between ~30 and ~90 minutes.
  9. Once the migration tool has completed, startIRI 1.4.2.4 RC².

As usual, our community is on top of things and the Full Node Wiki has already been updated with a playbook to make this process painless.  

¹Tip:Add a command to check out the correct branch when building IRI: 

$ git clone https://github.com/iotaledger/iri$ cd iri-> $ git checkout v1.4.2.4_RC$ mvn clean compile$ mvn package

²Note:In earlier versions of this article we recommended to run IRI with the— rescanflag or withDB_RESCAN = true.This is obsolete!Once you have successfully completed the migration utility, neither the flag nor the .ini setting must be applied.

If you run a node and would like to participate in the validation process, it’s not too difficult. Just make sure you have Node.js installed and follow the instructions here: https://github.com/iotaledger/snapshot-validator.  

IF and Community members will be available on Discord in the #snapshots channel to provide support during the snapshot if you would like to participate.

A full set of release notes will be available on the release page when the new version is made available.  

This snapshot includes fixes for:

  • Tag indexing (#728)
  • Running node on testnet with a single flag (#610)
  • TCP networking issues (#592)
  • ZMQ sending issues (#569)
  • Improved milestone solidity tracking (#486)
Follow us on our official channels for the latest updates:
Discord | Twitter | LinkedIn | Instagram | YouTube | CoinMarketCap

Tags

IOTA Foundation

Official posts from the IOTA Foundation, and migrated posts from old platforms.

Recommended for you