Category: Storj (SJCX)

Storj Bytes Community Quarterly Newsletter – September 2017

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.


TECHNOLOGY IMPROVEMENTS

Our C-library has increased the efficiency and reliability of file transfer and encryption

Community members have requested an easier way to integrate with our Node.js core. As a result, the engineering team has largely been focused on migrating the Node.js core and CLI to a C-library called libstorj, with Node bindings called node-libstorj. We wrote libstorj as a replacement for the older JavaScript library with the purpose of interacting with the Storj network. We chose to build the core in C because of its portability, performance and efficiency. The bindings provide a portable way for other languages to interact with the network. Prior to the bindings, developers had trouble implementing a library that can reliably download files. Since developers invested significant time in this implementation, it detracted from the overall main goal of what they were trying to achieve: incorporate the Storj network in their application. Furthermore, by migrating to C, and re-architecting the code base, overall performance has greatly increased. This has directly resulted in an increased efficiency of the network transfer connection initiation time, the general response time for commands, how files are encrypted, and how larger files are transferred.

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…

This article was originally published on: The Storj Blog on