Rising developer activity and an influx of new users on the IOTA network are creating fresh challenges for the IOTA Foundation. The rapidly growing ledger is putting pressure on the system — especially on nodes that have limited capacity.
Beta tests will determine whether the concept works
The development team already performs routine cleanup operations so nodes can restart with freed storage. However, cleanup is becoming increasingly difficult as the ledger grows, so the team has developed a new feature: local snapshots. This addition is not a surprise — local snapshots have long been part of IOTA’s roadmap. Initial tests are underway, but for now only on the Foundation’s own infrastructure. Network users will be kept informed about analysis results and further implementations as testing proceeds.
Lower storage requirements and faster synchronization
The Foundation has published early details that matter to node operators, outlining how local snapshots will change operational requirements. One clear benefit is a significant reduction in disk space needs for many node operators. The Foundation says some nodes could soon require only a few hundred megabytes of storage. Frequent, resource-intensive maintenance tasks should become unnecessary once the network moves away from global snapshots.
Because local snapshots produce small node databases, synchronization times are expected to drop to mere minutes. Ultimately, nodes should be able to process several thousand transactions per second without running into database-related issues. That scalability improvement is a particularly notable advantage.
How the Tangle’s design supports local snapshots
To explain the concept without too much technical jargon: part of the rapid growth in IOTA’s transaction history was due to older transactions that remained unconfirmed. The further back you go in the ledger, the greater the chance of encountering these unconfirmed transactions, which can be reattached to the Tangle if they lack confirmation for too long. Another relevant characteristic of the Tangle — the data structure underlying IOTA — is that it becomes more secure with continued use. For transaction validation it is usually sufficient to look at the state of the ledger and the set of pending transactions.
Data pruning as a core optimization
The basic idea behind local snapshots is straightforward. The process prunes transaction history while preserving account balances. Local snapshots are anchored to specific confirmed transactions selected by the system; these anchors must have reached a certain age, though exact historical thresholds have not been finalized. Once anchors are chosen, the system removes transactions that are directly or indirectly referenced from those anchors. A database cleanup runs in parallel — but before deletion, affected balances are analysed.
The mechanism is designed to ensure that the ledger state (the “ledger status”) is preserved in the new local snapshot files so users and applications continue to see a consistent account state.
Permanodes become feasible
The Foundation’s presentation makes the migration sound promising, but some synchronization challenges remain. New nodes will not be able to access the full historical transaction log in the way global nodes can. That limitation complicates network cleanup operations. Even if new snapshots can request a full history via permanodes, synchronization could still be time-consuming under some scenarios. Permanodes — nodes that retain the complete transaction history — were previously incompatible with a network relying on global snapshots. With the local snapshot approach, running permanodes should again be viable, enabling preservation of the full transaction history. The Foundation envisions a solution where new nodes can access existing Tangle files, with the consent of the Foundation and the community, to help bootstrap local snapshots.
What is required to create a new node from a local snapshot?
Newly planned nodes must determine how far back in the transaction chain they need to inspect. To simplify this, the network will publish a list of “solid entry points” — specific hashes that mark accepted starting points. When a node reaches one of these hashes, it will stop querying for additional approvals and mark relevant transactions as solid. According to the Foundation, this approach enables the rapid, minute-scale synchronization described earlier and reduces deployment complexity overall.
What changes after rollout?
Primarily, local snapshots will reduce network storage requirements. The Foundation also expects node operations to become more automated and to require less maintenance. Easier setup for new nodes will benefit community members and companies interested in running infrastructure. The upcoming beta tests will reveal how well the changes perform in practice and which adjustments may still be needed.