The latest blog entry includes the following " Coming Down the Pipe:"
“Reed Solomon for uploads to the network: We’re fine-tuning these numbers to reduce the amount of redundancy and keep our durability consistent with our SLA of 11’9s. Our initial choice for RS numbers was very conservative and since we have data about our network for over a year, we can begin to fine-tune it to help increase our performance and decrease redundancy without sacrificing any durability of the files.”
As an SNO this will affect any calculations you may be making as it will result in fewer blocks being stored across the network for any particular amount of data stored and less repair traffic being generated when blocks need to be reformed.
On the upside, this change will not just improve performance for anyone storing data, but it will also provide Storj an improved cash flow as they will retain more of the fees charged for data storage. This may seem like a bad thing from an SNO’s point of view, but if you do the maths on the current data structures you find that Storj has not really left themselves much ‘wiggle room’ to vary the fees charged without also having to vary the amount paid to SNOs per TB of storage space and traffic.
What is not clear is what will happen with current data - this change could result in the satellites deleting 10-30% of the data block already held by the SNOs depending on the new Reed Solomon values as the repair process repairs data held across the system due to nodes exiting the network. The consequence of this may be that anyone with a large storage node could see the amount of storage used drop as the repair process reduces the number of blocks stored faster than new blocks are added.