Welcome to Storj Bytes, a quarterly newsletter from the Storj Labs team. Storj Bytes is your resource for the latest product and technology updates and a look ahead at our roadmap. It also details community feedback and how we’re integrating it into our work.
Storj Labs is thriving with product and technology adoption because of you, the community. Every single community member is crucial and plays a role in advancing distributed storage in our industry and how Storj grows. Without our ecosystem of Farmers, Renters, Moderators, Contributors, and Developers, many of whom have been with us since the very beginning, Storj wouldn’t be what it is today.
We’re now, as a community, in a position to drive the future of blockchain-based storage for all. We’ve finalized our token sale and are poised to accelerate company growth and development of the platform. We’ve aggregated community feedback and are focusing in the near term on improved onboarding and consistent payment plans. Development and services are our priority in Q4, and we hope this newsletter addresses these topics and provides visibility into what we are currently building and what new capabilities are on the horizon.
Our C-library has increased the efficiency and reliability of file transfer and encryption
Earlier this year, we improved the network reliability for file downloads, including shard mirroring and reconstructing a file from its parts
A distributed storage network utilizes its Farmer community and storage availability. When Farmers go offline, storage space decreases, resulting in an unacceptably low probability of file retrieval. We’ve made great strides to improve retrieval reliability by creating multiple copies of files and implementing an algorithm, “Reed-Solomon”, that is able to reconstruct a file from just a fraction of its data shards.
Specifically, one of the issues with Clients receiving a file is that Farmers have had less than a 50 percent probability of being available to serve this data. The node´s (Farmer’s) ability to retrieve data was dependent on the size of the file being received: a larger file size coincided with a decreased probability of data retrieval. Data retrieval issues are directly related to a node’s performance and behavior. Nodes could go offline due to power failures, crashes, intermittent internet connections, and so on. The solution to these unfortunate circumstances was mirroring the node that’s in a failed state, and adding erasure encoding. When a node is inactive, other nodes in its vicinity will voluntarily hold pieces of data that were originally stored on the node that failed. Erasure encoding comes into play in the event that too many nodes that hold data or parity shards have gone offline. The file’s metadata is stored on the Bridge. The metadata conta…