Codex Storage
Replies: 2 comments 8 replies
-
|
I'm not sure I understand how your deriving the stake where, for example how did we got to |
Beta Was this translation helpful? Give feedback.
-
|
27.61 = stake per TB * 4 (capacity in TB of one hard drive on this server) = 6.90€ * 4 Maybe the lost stake per disk failure is not relevant and I should just put the lost stake per contract. |
Beta Was this translation helpful? Give feedback.
-
|
Your also mentioning something that I didn't take into account: when someone looses data, they not only loose their stake, but also the money they would have won by finishing the contract.. |
Beta Was this translation helpful? Give feedback.
-
Oh, I see didn't make the connection 👍 |
Beta Was this translation helpful? Give feedback.
-
Yes, I think this is important and has some interesting implications, for example - do payouts happen gradually over the lifetime of the contract or does it happen at the end? I would assume that in general, gradual payouts are more vulnerable as they loosen the assumptions built into the stake, but I'm not 100% sure on this yet. |
Beta Was this translation helpful? Give feedback.
-
|
I would say it happens at the end, don't matter much, since at the end of the contract, 99% of the money going to the hoster wallet will actually be it's stake (if we talk about a 100x stake factor) However, the stake burning should be gradual to allow some downtime. (probably exponential)? If we burn the stake too quickly, that would be bad: let's say we burn everything in 6 hours, my server looses internet for 10 hours. I still have the data, but at that point, I lost all my stake, so I might has well delete the data and find new contracts. |
Beta Was this translation helpful? Give feedback.
-
|
In the general case, if one of the argument is that the stake might be prohibitively high, I need to clarify my general intuition behind it. The stake is a security guarantee that should reflect the hosters commitment to hold on to the data, i.e. skin in the game and risk exposure. The idea is that, the stake serves as both a signal of this commitment and as a deterrent from deviating from the protocol. |
Beta Was this translation helpful? Give feedback.
-
|
To expand on this, I think it would be wrong to make a direct connection between amount of storage provided vs signaling commitment, this are a bit different things, but not necessarily mutually exclusive. The tricky part is reconciling this two notions - for example, does signaling "commitment" implies that the provider has enough storage to satisfy the contract needs? |
Beta Was this translation helpful? Give feedback.
-
|
The goal of this write-up was mostly to build some intuition and explore the economics behind the stake. What I've learnt looking into it:
This wasn't meant to be a critic or an argument, just some "facts" to have in mind while designing the protocol :) The reason why I used the staked factor, and thus made the stake linearly dependent on the contract cost, is precisely because the users have to pay the interests for the stake. |
Beta Was this translation helpful? Give feedback.
-
Oh I didn't perceive it as such, I think these are great points and the intuitions seems correct to me. My comments where just thinking out loud/expanding on some of the intuitions :) |
Beta Was this translation helpful? Give feedback.
-
I'm trying to build some intuition on the stake amount.
I take it from the point of view of the hoster, since they will be choosing their price after all. I based my data on a 12 * 4TB sata server that costs 330€/month. And a 5% wanted APR (on staked money + cost of server)
Other assumption, the host sell contracts on a monthly basis (a shorter contract will have a lower stake, so this matters a bit <- i'm not sure about this anymore, need to check)
Note that this is very crude, and just to give us some order of magnitude.
The "raw storage" cost to the host 6.87€ / month / TB
I add the margin: 6.90€ / month / TB
So a one month, 1 tb contract would cost 6.90€ on storage only.
Lets say I stake 100% of the amount of the contract (so for a 6.90€ contract, a 6.90€ stake)
I add the monthly APR of my stake to the contract cost (0.05 / 12 * 6.90 = 0.03€)
The contracts now costs to the user 6.93€ (for 1tb for 1 month)
Now, what happens if the host loose a 4TB disk?
That would cost him 27€ in stake.
Here is some data with some different stake "factor":
So the good thing is that we can really go mumbo jumbo with the stake factor without increase too much the contract cost, if we just count the APR.
Now, we'll look at redundancy rentability in the point of view of the host.
If we count a 1% disk failure per year, it means that on this server, with a 1000x staked factor, the host will loose on average 3.300€/year.
Which is approximately the cost of the server.
So with a 1000x stake factor, it's worth it for the host to rent a second server, and mirror the first one with it.
And to the user, that would cost 35.66€/TB/month. (S3 costs 24€/TB/month)
With 100x stake factor, he looses 331€/year. At this level, it's already worth to sacrifice some capacity by setting some RAIDs 5.
With 10x stake factor, he looses 33€/year. That's probably worth to loose this amount, and so not take any steps to avoid loosing data.
Note that with this system, the majority of the "cost" for the host is not actually renting the server, but his stake. This server which costs 330€ per month would require 33,000€ of stake at 100x stake factor.
That may be a big limit of the system, maybe we should think about delegating stake.
And all of this is for a single hoster. Of course, in practice, we would want multiple hosters.
If you want pay 35€/TB/month, you could either have one hoster with 1000x staked factor, or 5 with 10x staked factor. (or 1 500x, 1 100x and 1 1x, why not)
This is also not taking into account that if someone wants to store data on your server, it's often to retrieve them later. A hoster could sell contracts without margin, or at lost, and recoup on the BW
Beta Was this translation helpful? Give feedback.
All reactions