Update Proposal for Storage Node Operators

time

tīm

noun

  1. A nonspatial continuum in which events occur in apparently irreversible succession from the past through the present to the future.
  2. An interval separating two points on this continuum; a duration.
  3. A number, as of years, days, or minutes, representing such an interval.

I believe it will happen sometime before the end of 2023

7 Likes

But being realistic, is there any timeframe estimated for this?

It would be nice to know if it is estimated to be in a couple of months from now, or if the changes will take longer than that (but before end 20223 :slight_smile: )

I’ve already answered that there is no decision yet on what they are doing, this is a proposal. I can’t give you a time, I don’t think John can give you a time. They have to decide what they are going to do, and then there are going to be some changes that need to be made to the payout scripts, any relevant documentation, possibly the node dashboard that estimates earnings, and a variety of other internal documents, spreadsheets, and the like. Assuming they plan this out, then they will have a better idea of when it will make sense to cut over to what the new economic model will be.

As of right now, I have not seen anyone talk about a date, other than before the end of the year. I haven’t even read someone hint at a date.

I would assume that it would not impact the most current payout, and likely there would be a payout gap after they announce the rollout strategy. That’s a guess on my part, but considering they would have to update the dashboard and such, and communicate these changes out, it will take some time. I also expect a lot of node operators to show up after that payout day who either are running an outdated version of the node software, or never check the forum, to be asking a lot of questions. For those SNO’s, it may go off like a bomb, unless Storj Labs sends out an email or adds details to the dashboard.

So, no date. Maybe John will talk about one in the Twitter meeting. But I think when they announce the final decision on the numbers, they will likely also announce the plans for when they will switch.

6 Likes

This hashed probably been hashed about before by smarter people on the thread, but I think the costs of being an SNO are different for each member. And with reducing prices, I think you’ll get different operators dropping out in different regions with different capacities.

  • Electricity cost is the obvious factor, needed to keep the drives spinning. Decreasing payouts may cause more nodes to drop in high electricity cost areas (Europe, California, etc).

  • Bandwidth costs. For some users bandwidth is free and unlimited. For others, there may be a fee like $30 per month once over a terabyte. For others it’s a price per GB or TB. Reduing egress payouts could cause some nodes to drop out entirely, and others to throttle to very low bandwidth.

  • Sysadmin cost. Franky, as a home user, it is kind of difficult to get storj up and running well, it takes a lot of time. And that time is regardless if the node is small or large. So a lot of smaller node operators may drop off sooner.

  • new operator impacts. The new operator profitability experience is kind of a joke between the held payouts and the long time to fill a node. A new operator should know what kind of pricing they are a getting into. But reduced payouts combined with the existing steep learning and profitability curve could cause a dramatic decrease in new nodes, leaving only old ones on the network.

So the effects could be highly variable, I would urge storj not to proceed too rapidly. I don’t know how much information storj has on their nodes’ distributions (capacity, bandwidth, age, etc). Perhaps a survey pushed out to operators would gather more information.

Nailed it.

1 Like

Please post questions you want to get answered on the upcoming Twitter Spaces on this thread preferrably sooner than later so to give the team a chance to find the required data before the Twitter Space is scheduled.

5 Likes

How about in the first post?

1 Like

A post was merged into an existing topic: Updates and Live Q&A Twitter Space March 15, 2023 @ 2:30pm ET

The incentive would probably only have to be slightly bigger than the cost of sysadmin’s time to set up and maintain Gateway ST. If you say it’s indeed half an hour, and assuming a customer performs 100 TB of egress monthly, the breakeven point would be at around ~5% of discount?

It would probably make sense in Europe, but not in the States, latency too high. And IIRC the US1 satellite has the highest egress. Hetzner is pretty unique with their reliability and bandwidth offer.

I’m in!

Wrong thread :stuck_out_tongue:

1 Like

Fair. I didn’t didn’t catch that it was a link and only read “this thread”. Someone feel free to move that!

Thanks, mentioned it there as well.

Please post questions for the Twitter Spaces on the aforementioned thread, it is important so we know who asked each question so we can properly follow up and you will get tagged with an answer if it gets posted on the forum rather than or in addition to getting answered live, as it may be important for others to be able to easily refer to the answer, too (I am not a mod so I can´t move the post for you, sorry.)

1 Like

Thanks for the heads up. I’m sure @Alexey will take care of it. He’s always catching me sticking things in inappropriate places.

I took care of it. Lots of questions for this Twitter meeting.

5 Likes

@MattJE96011 An answer to your question has already been posted by our VP of Finance here.

3 Likes

they are clustered already, and they not a bottleneck, data is transferred directly between customers and nodes when they use a native integration, and between gateways and nodes if the customers uses gateways. So perhaps you mean clustering for gateway. This is already done too.

1 Like

Hello @weyanz,
Welcome to the forum!

Your node will not have the same latency for the each customer. This metric is hard to confirm or measure. Measure the latency between satellites and nodes doesn’t make sense, data is transferred between the customer and the node. So we need to collect reports from the customers instead (and we do, but not a spent time, only spent storage and egress). However, this will varies even for the same customer depending on their circumstances like how much their bandwidth is loaded, so likely this metric will never be confirmed.

1 Like

After reading many posts, I see that we are still don’t understand how Storj network is organised, how all the parts work, what is their purpouse, who comunicates with who, what services are there, what is paid for and what is free, what Storj is paying for, what servers has, etc etc. I didn’t read all the docs and whitepapers, so maybe the info is out there, but I see some confusion even from the smarter members.
Can someone make a For Dummies guide to Storj network? To clarify all these things and to easely refer others to it?
Thanks!

Huh, maybe you are right and that is why we see some strange numbers floating around!
I will give it a try, but I don’t have all the numbers. To make it even simpler, I leave out repair.

From a customer’s point of view, they pay 4$/TB storage and 7$/TB download. It doesn’t matter if they download from S3, HTTP or any other edge server or use the native STORJ uplink.

From the STORJ perspective, they pay the nodes 1.5$/TB and need to pay 2.7 nodes. That is a total of 4$/TB they pay for storage and 20$/TB egress. What we don’t know is how much they pay per TB traffic for edge services. We only know how much they pay for edge services in total. 2.7M in Q4 2022 or in other words, more than twice of what they pay to nodes! I assume their costs are roughly the same as the rest of the industry so I will use 5$/TB for traffic. Maybe someone from STORJ can chime in on that.

From a node perspective, we get 1.5$/TB for STORAGE and 20$/TB egress.

What does that mean in reality?

Use case 1: a customer uploads 1TB, stores that for one month, and then download that again over a native integration. In that case, the client pays 11$ (4$ storage plus 7$ download) to STORJ. STORJ pays 24$ (20$ egress + 4$ storage) to nodes. So there are 13$ missing and being subsidized by ICO.

Use case 2: a customer uploads 1TB, stores that for one month, and then download that again over S3. In that case, the client pays 11$ (4$ storage plus 7$ download) to STORJ. STORJ pays 24$ (20$ egress + 4$ storage) to nodes plus 5$ to run the S3 gateway. So there are 18$ missing and being subsidized by ICO.

Maybe that helps to understand, why the current model can’t work forever.

5 Likes

Trying to calculate this out,

I have 8x 12 TB Ironwolf Nas in Raid6 thats,

7.8W per drive x 8 @ $0.0950 per kWh = $0.19 cents per day for electricity.
To add unlimited egress on my home internet = $20.00 (The 1TB included is being used by plex and seed box, using that to count the rest of my electricity as a net zero.)

Roughly $5.70 per month electricity for the hard drives.

Total additional monthly cost of my setup is $25.60 per month
(Not including server costs, server electrical costs etc. since its a 24/7 seed box/plex server ill net zero that part)

I have the 2.5G Up 2.5G Down WAN

At a $1 per TB and $4 egress, id need to have at least 21 TB filled and 1 TB of egress per month and nothing held back before I break even for the additional costs of running Storj. To be fair thats not counting the wear and tear on my hdds, or the increased computer electricity.

If I look at purely electrical costs, I would be profitable with a much lower amount stored to be fair to the project. But you have to consider I’d need to hold back around $260 over 5 years to replace a drive if needed.

Would be great if Storj found became more popular for streaming media, TURN services, maybe localized CDN services, image sharing, something where data would have a lot of egress even if more data isn’t being stored.

With the reduced prices, you should not hold any amounts back. You are making it much harder and longer to run a break even on investment, you need to give newer nodes a break on the hold back amounts.

1 Like