New scanning tools for node operators
The February call started with an overview of the latest updates to the Swarm network. As highlighted by Niki Papadatou, node operators now have access to a local scanning tool via an API endpoint. This tool detects and reports the number of all pinned file chunks, signalling the presence of any corrupted or missing chunks. Additionally, a Swarm Scan API tool is available for node operators, directing them to the least populated neighbourhoods and providing precise information on the storage depth of a given neighbourhood.
At the same time, the team has implemented local fixes that are expected to yield significant improvements to the localstore, such as the upload store, improvements for pinning, stamping, etc. A piece of great news: from now on, dates for all new releases will be communicated two weeks in advance, providing ample time for everyone to prepare and share their feedback on the upcoming changes.
Addressing community inquiries about erasure codes, Niki emphasised, “I want to say that this is an optional feature, which can be set in the headers during an upload.” She added that, currently, all tests indicate the expected levels of chunk redundancy, and the process is behaving as anticipated.
Enhancing the Swarm network through SWIPs
Three SWIPs (Swarm Improvement Proposals) were presented during the call.
Črt Ahlin provided an overview of two proposals currently in the development phase and awaiting integration into the repository:
- The first proposal, centres on responsible neighbourhood splits, aiming to prevent data loss during storage radius expansions. The SWIP proposes socially responsible node behaviour, where nodes only expand their storage radius when a sufficient number of "SR nodes" are available to secure the remaining data, preventing data loss and preserving trust in the Swarm network.
- The second proposal focuses on enhancing the cost-effectiveness and efficiency of storage within the Swarm network by doubling the reserve size. This adjustment would increase the overall storage capacity of the Swarm network, either by reducing the required number of nodes or achieving greater storage with the same number of nodes. Since this would require additional compute and storage from node operators, your input on this proposal is vital.
- The third SWIP, presented by Antonio Gonzalo, focuses on leveraging the Swarm network’s infrastructure to ensure higher security levels for on-chain data storage. He detailed how Swarm could be used for storing data, particularly from Layer 2 networks. The SWIP emphasises maintaining data integrity and availability via a stake-based mechanism involving insurer nodes, which would guarantee the genuineness of data uploads, preventing manipulation by malicious actors.
If you’re a node operator, don’t hesitate to share your thoughts on Discord or GitHub.