We appreciate all the feedback and engagement from the storage node operator community. While we’ve been doing a lot of testing as we’ve developed, we’ve only just recently reached production. We’re very excited about what the future holds in terms of customer demand. We’re also really happy with the growth of the storage node network. While the network is really in its infancy today, we expect to see steady growth of the network both in terms of customer demand and capacity.
Since launching into production last month, we’ve had a few community members inquire about our plans around test data, bandwidth utilization, and whether we’d stop uploading test data to the network in the months to come. This post is intended to clarify our test plan and the economics for Storage Node Operators over the next few months.
With last week’s payout, you probably noticed two things:
- There was potentially less storage and bandwidth utilization than in prior months
- There was an unannounced surge payout of 2.5x
Here’s some clarification on what we’re doing on the Storj side of things to help make sense of what you’re seeing.
Why Do We Test The Network?
We upload and download test data on the network on an ongoing basis for a variety of reasons. These tests include everything from performance and load testing to durability and functional unit testing. The actual amount of data and bandwidth we use during testing far exceeds what we need from a data gathering and analysis perspective. The majority of our test data is used to provide an ongoing incentive and reward for our SNOs to remain on the network as we grow customer demand for cloud storage.
Testing and Satellites
Previously, we used one of our R&D Satellites (satellite.stefan-benten.de) for performance tuning and configuration A/B testing, as well as load and performance testing the network. Recently, we’ve separated the functions out, creating a dedicated Satellite for load and performance testing (saltlake.tardigrade.io), and shifted responsibility for uploading test data to that Satellite.
Ultimately, we will be deleting test data uploaded from satellite.stefan-benten.de and replacing it with data uploaded through saltlake.tardigrade.io, and that data will be cycled regularly. As we cycle through test data, it will continue to be distributed throughout the network, so SNO drives won’t be filled with the same test data indefinitely.
As we transition to using the new performance testing Satellite, we concurrently need to significantly ramp up the amount of test data on the network. We generally try to keep the network sized to anticipate near-term customer demand—that means uploading several PB of test data to the network while reducing the amount of test data on the R&D Satellite. In addition, we try to test egress (download) bandwidth in a way that’s similar to the patterns we expect to see from customers.
What the Storage Node Operator community is seeing in the reduction of data on the network, is the transition as we dial down usage on one Satellite and dial it up on another. One artifact of this transition is that it takes a substantial amount of time to upload several PB of data, and operationalizing those uploads so we can evenly distribute the test egress across the largest number of Storage Nodes.
In terms of the amount of download traffic we generate during testing, we’re targeting a similar usage pattern to what we expect from early customers with early use cases - mainy backup and other similar low frequency retrieval use cases. Our current target is to download approximately 10% of the data stored each month. As we get more customer data on the network, we’ll continue to tweak our test protocols to match customer behavior.
Surge Payouts
We don’t have anywhere near the amount of test data we want on the network today, so we included a surge payment in the March payout as a “thank you” to our loyal Storage Node Operators who’ve been diligently providing storage and bandwidth to date. Until we reach the planned levels of test data storage and bandwidth, we’ll continue to use surge pricing this way, dialing down the surge amount as we increase network utilization. The most important things in this process include both generating valuable test telemetry and feedback as well as ensuring that we continue to reward our loyal storage node operators.
As we’ve mentioned before, we use surge payouts much like a ride-sharing service might. During certain times when Uber or Lyft need more drivers in specific areas (the supply side of their network) they offer a surge payout for drivers to incentivize them to get out and pick up riders. On the Storj Network, we reserve the ability to use surge payouts as a tool to compensate Storage Node Operators (the supply side of our network) who provide their excess capacity and bandwidth. It’s worth noting that on our network, Storj Labs pays the surge payout cost, whereas, on a ride-sharing service, it’s passed on to the rider.
For example, if we foresaw a large amount of incoming data from one of our customers, we might send out a notification that we’d implement surge pricing in the coming month to incentivize more Storage Node Operators to join the network. This past month’s surge payout was to incentivize Node Operators to maintain their Storage Nodes on the network.
We continue to make progress on increasing the demand for the network and look forward to announcing our customers as they’re ready to tell their stories.
Overall, our goal is to make sure the network grows in a healthy way and a big part of that is making sure it is rewarding to be a storage node operator. With the paint barely dry on the platform from our production launch, we have a long road ahead of us. We hope our storage node operators currently on the network remain a part of this platform as we grow. We’re doing what we can to make storage node operation economically viable today, as we build the customer demand that will drive storage node utilization in the future.
And judging by the likes of our 2 posts, I’m currently in the lead 
