Let's talk about the elephant in the room: The Storj economic model (node operator payout model)

Well that just shortness their runway. We’re gonna have to assume that will be insignificant in the future. Hopefully by the time their reserves run out. I’d rather focus on what the future situation should look like rather than trying to find out when it should be implemented as that could change a lot with fluctuating STORJ value. So for ease of discussion I’m gonna assume test data will be mostly gone at that point.

on repear work i forgot expansion factor so 10$ for tb to sno egress + 20$ for tb to Hetzner x 2.78 = 65.6$ for 1 tb Repear work, i thin this process will kill Storj Laps much faster then 20$ for today Egress to SNO

That is not correct. When 28 pieces are lost, the repair worker needs to download 29 pieces and upload 28. So it’s pretty much 1 to 1. The expansion factor does not apply.

Thank you for pointing, its my lack of knowledge’s.

1 Like

After all it is hard even to think about investments to Storj infrastructure without knowing how it would be, that’s why I hope Storj Lab will not lasting this situation for long, as at this ingress rates existing storage will end soon.

But that’s just hypothetical. We don’t know (yet) what Storj will come up with.

Right. Currently you don’t know if you should invest or shut down your nodes.

My guess is that short term, we’re not going to get a hit in payouts. This month is looking like a 1TB ingress month. That’s gonna fill up smaller nodes quickly, directing even more ingress to larger ones. They can’t really afford to lose capacity right now as @Vadim mentioned.

Actually, it’s quite fair for customers to pay if customers want any reliability. Test data are what Storj engineers can use to develop features and evaluate whether they function correctly at scale. The only question is what should be the ratio of test to customer data. Maybe some rather insignificant value like 5 to 10%, maybe more.

What I’d assume though is that in the long term it should be somewhat routine to run tests involving, let say, 1PB of data.

Sure at a reasonable eventual rate. But you can’t expect customers to pay double if half the data is test data. And it’s not the customer who can choose to optimize and minimize the use of test data. So I think the responsibility to pay for that should for now be with Storj. Basically it should eat into their margins so they have an incentive to not go overboard with it.

1 Like

Did Vetting process has been modified somehow? When I started 2 years ago, it was said that only 5% of the normal traffic is directed to new nodes in vetting. This summer I think it was still 5-10%. Now I just started a new node and is like it fills with 1TB/month, and is only 2 days old. And the number of new nodes/day is huge. I didn’t check my other nodes, but I’m pretty sure the 1TB/month is not 5% of ingress traffic.

5% of all ingress goes to unvetted nodes. If 5% of nodes are unvetted, you get the same amount of ingress as on any other node. Technically you can even get more data than on a vetted node.

I guess we found another element that should probably be fine tuned as the network grows. At some point unvetted nodes will account for less than 1% of the total number of nodes and there really isn’t a good way to assign a fixed percentage of all traffic to go there. Instead it should probably calculate how much of each upload should go to unvetted nodes based on vetted vs unvetted node counts so that there actually is a static rate of say 10% of ingress on unvetted nodes vs vetted ones.

It’s a partner that will potentially bring in a lot of customers though.

1 Like

I just saw we’re having 17k+ active nodes now: https://storjstats.info

1 Like

yeah, but the reason I’m saying this is this exponential growth curve in data storage.

vs this linear growth in active nodes.

That’s not gonna work if those trends continue. Though the first graph does show that free space doesn’t really drop on nodes, possibly suggesting that many nodes expand when they start to fill up. (I know I do this)

Niceee… keep me in vetting more :heart_eyes:.
Good job Storj Labs for attracting new customers. In the long run, nodes will multiply and storage will increase, so I think it will keep up with demand, stabilising the profits too, but for now is awsome. I don’t have where to put more nodes though…

yeah. An ingress is pretty crazy currently.

For vetting, keep this in mind.
image
Interesting change there. The number of unvetted nodes dropped significantly again. So yeah, ingress is pretty good. Since about 13% of nodes are unvetted, you can expect about 40% of normal ingress on an unvetted node currently. But these numbers include inactive nodes and full nodes. So it might be quite a bit higher than that.

What do you think about “different payout plans for SNOs”, that can be opted in by SNOs from month to month, that offers different plans for engress and stored space. Something like:
Plan A. 3$ for stored space, 1$ for engress.
Plan B. 1$ for stored space, 10$ for engress.

Plan A can benefit full nodes, with little engress, and will encourage them to stay on and don’t delete and restart a new node.
Plan B will benefit semi full nodes with a lot of engress.

In theory I think it would be cool. In practice I’m afraid this just allows node operators to make it not profitable for Storj. They are also making less money on the data on your node once it’s full, so what are they gonna pay that $3 with if the storage income doesn’t cover it?

I’d say differentiating like that only makes sense if you also differentiate customer payments based on specific service models and then node operators can pick what service models to provide data for. But then you wouldn’t just be able to twitch based on existing data you already store.

1 Like

This was proposed many times, with—if I remember correctly—no clear answer from Storj yet.

This is a natural proposition, cloud companies tend to offer many such trade-off levels (compare AWS with their storage classes, from S3 Standard to S3 Glacier Deep Archive). I suspect Storj is just too small to attempt to optimise services for many different tiers, and so it might be better to just focus on providing one tier that works well. It’s more difficult for Storj than for centralised services to offer many storage tiers.