Potential misconceptions with the safecoin economy

Autonomi Network Token (incl (e)MAID)
1

TLDR: StoreCost is a rate limit, not a fee for service. Rewards ensure permanence, not security. Membership rules ensure security.

Regarding storecost is a rate limit, not a fee for service:

In the past I’ve said things like storecost infuses chunks with their future costs which implies some sort of idea of unpopular-data-pays-for-the-needs-of-popular-data. Since then I’ve changed my mind.

Storecost is not a fee for service because

  • We don’t know the cost of services into the future.
  • Costs for different operators will vary by location and labor and experience and equipment etc.
  • Costs for each chunk of data will vary by popularity and geolocation and age etc.

So storecost can and should only be a form of rate limiting or spam protection.

To illustrate why this is, imagine the hypothetical scenario of no storecost, upload is free and only constrained by the ability of vaults to process it.

In this case there would be a queue of data. Maybe it’s a first-in-first-stored situation. Maybe it’s randomly selected. Maybe all new data is accepted and the most unpopular old data is dropped as the new data comes in. Whatever it is, the missing element of all these is a consistent way for vaults to decide whether or not to store new incoming data.

Storecost is hoping to solve consistency with decision making, ie allow the client to attach a priority or value (via a fee amount) to new data (or to change perspective on the same idea, allow the network to specify the threshold for spam / not spam).

So I guess what I’m saying is storecost should be as low as possible so that upload is economically constrained (ie by value) rather than technologically constrained (ie by bandwidth or disk space constraints). We don’t want to allow absolutely everything, eg random data, but we do want to allow as much valuable data as we can. Storecost allows setting the incoming data flow as high as possible but not so high it damages the network.

A related tangent: the initial constraint on upload will probably be the difficulty/ease of obtaining safecoin. The additional cost/difficulty/friction of obtaining safecoin will prevent a lot of data from being uploaded compared to, say, a free-but-rate-limited situation. But as safecoin becomes more commonly available and the acquisition and spending of it simplified then the storecost will become the only limit on uploads, rather than the other safecoin-related frictions. I think the current UX ideas for payment and onboarding are fantastic which helps reduce the friction when a user takes the journey from initial discovery of SAFE to uploading data.

The current design of storecost does indeed aim at this since it’s based on spare space which is probably the main factor when deciding how much to rate limit.

Regarding rewards ensure permanence:

Since storecost is not actually funding the ongoing security and delivery of SAFE network services, this must be done by the reward.

It’s very important that the reward should not bias in favour of popular data. It should reward the retention of all data equally. Data fungibility.

Pay-for-GET (in the simplest form) would mainly benefit popular data. Farmers would be doing a cost benefit of keeping unpopular data. At some point that unpopular data would be worth dropping. The reward mechanism should ensure that it never becomes viable to drop unpopular data (and this is why it’s important for the storecost to ensure uploaded data has some initial value hurdle, so that the network is justified in keeping it).

burstcoin uses storage in the form of computed farming-data where the key idea is farming-data is relatively costly to obtain but relatively cheap to utilise for farming so farmers store it rather than continuously re-obtain it, hence proof of storage. Data chunks in SAFE are similar in being relatively costly to acquire but relatively cheap to utilise for farming. It’s important that a) all data is utilised approximately equally for farming and b) only legitimate data is possible to use, ie you can’t use cheap home-made data for farming, only costly client-uploaded data.

This insight into the reward mechanisms and the relation to storecost is important because it shows what not to do. We can’t treat storecost as a benefit to farmers. We can’t treat rewards as a type of fee-for-direct-service but as a fee-for-aggregate-and-future-potential-service.

Some ideas to illustrate this concept

  • rather than reward a GET request for a specific chunk, reward when that (probably popular) GET request is used in combination with some existing (probably unpopular) data. This should make unpopular data equally accountable and useful and valuable as popular data for the purpose of rewards.
  • the frequency and size of rewards should be matched to the rate of change of the network, which is subject to unpredictable rates of change in participation and technology. Upload is constrained by total available bandwidth, relocation and joining new nodes takes time, and rewards should reflect these temporal constraints. GET and PUT volume will vary through the days and the years. Availability of new storage will go through famines and gluts. The reward should be responsive to these things while primarily ensuring the availability of all previously uploaded data. Note that ‘availability’ is mainly ‘can it be downloaded’.

Questions to ponder:

Are the rewards and storecost also related to security? I think a little, but mainly the membership rules (join / disallow / relocate / age / punish / kill) are the biggest factor here, maybe as a gut feeling about 90% of security comes from the membership rules and 10% from the reward/storecost mechanisms.

Where should the storecost go? To the initial vault handling the upload? To the final ones storing it? To all vaults on the upload route? To the network as a whole? I think the existing recycling solution (ie storecost is given to the network as a whole to give as future rewards) is a pretty good approach.

How should the reward mechanism be designed to cover all data rather than only popular data?

Should it be possible for storecost to get to zero? If not, how close to zero could it get?

What tools can we give farmers to best understand how to run their operations? For example, if they have lots of spare disk space but their bandwidth is maxed out, how can this best be explained to them?

Can spare space and spare bandwidth and spare compute be measured in a useful way? Or is it only useful to measure stress / failure results and aim toward a certain degree of stress?

If storecost is a rate limit, how does it work for vaults with varying abilities? Not all vaults would want to rate limit the same way, but storecost is a kind of universal rate limit.

As per the topic title, these points aim to clarify potential misconceptions with the safecoin economy, but may themselves be misconceptions. What do you think?

18 Likes
2

What are your thoughts on say getting paid for gets, but the reward amount is based on a factor of how much the vault is storing and the get itself. So a max is worked out for any get and then each vault that responds to that request in a valid way get upto that max. The actual amount is worked out on some algo based on the amount of data being held. This is like a “value to the network” of the vault.

Maybe
let x = max for a get and is worked on the farming algo
let y = average vault size
let z = individual vault storage
let w = z/y limited to a max of 1

reward = x/2 * ( 1 + w )

With cost to store goes back to network

5 Likes
3

Yeah it’s possible this would work.

My main thought for rewards (in general rather than specifically about your idea) is to ensure the security of chunks. So the main thing missing from the specific idea you propose would be how it makes sure unpopular data is not dropped. As in, rewards must be based on specific data, not just the stats about the data.

One example (maybe not workable in reality) would be to reward based on the result of sign(original GET + some other chunk data) being below a certain target threshold (ie farming difficulty). So a vault would take each GET they receive and iterate through all their chunks seeing if it combines into a reward.

It may seem a bit too much work to do this for every GET, maybe it would be too much, but my point is this method ensures all data is potentially useful for the reward so is all worth keeping. And no individual data is more valuable or useful than any other. The GET becomes merely an event trigger, and the specific data of the GET is isolated from the reward probability.

Also note the work uses the other chunk data, not the name, so the node must actually have all chunks not just keep a record of the names.

Zooming out from the details, I feel reward should aim to retain data, which requires operations that may include any chunk rather than just popular chunks or only stats about what the vault has stored.

10 Likes
4

The only guaranteed way to accomish this is to audit all vault chunks and reward vaults for passing the audit. This also will protect the network from bit rot on vaults operating in good faith.

6 Likes
5

Some brainstorming, just ideas and thoughts definitely no facts!!

StoreCost is a ‘slowing’ force. It slows down uploaders when nodes need some more time to gather more resources. Having to pay to store causes uploaders to undergo a cost benefit analysis, it filters out some uploaders and retains others. Storecost cannot easily create new uploaders but it can reduce and slow existing uploaders. Storecost affects uploaders and nodes, but not downloaders.

Reward is a ‘speeding’ force. It encourages new nodes to join, the network to grow larger, enhancing parallelism and overall resource availability, and speeding up the rate at which future growth can happen. Reward motivates new nodes to join and existing nodes to stay, whilst ensuring low performance nodes do not overly hinder the network. Reward does not impact clients uploading or downloading.

When to slow down and when to speed up?

Downloaders - don’t care about either reward or storecost. This is essentially uncontrolled but will affect strain on nodes so is a factor in slowing or speeding.

Uploaders - when too much strain is put on nodes by uploaders, slow the uploaders down by increasing storecost. What is ‘too much strain’? Only the nodes can say, not the uploaders. So node strain should be the determination of a suitable storecost. We need a useful measure of node strain to feed into storecost.

Nodes - what is the smallest possible reward that achieves the growth rate needed by the downloaders and uploaders? Or should it be what is the largest necessary reward before there are no further gains and diminishing returns? You can reduce the reward relentlessly until only the most efficient nodes are viable. Likewise you can increase the reward relentlessly until the network becomes flabby and low performance, eg you have thousands of nodes trying to join when you only need hundreds. I’m not really sure yet about suitable mechanisms to manage increasing vs decreasing the reward.

My feeling is that storecost and reward are fundamentally different mechanisms, and the algorithm for each will be separate despite operating on similar input metrics. For example when nodes get strained it’s good to both slow down the straining via storecost and speed up the strengthening of those nodes via rewards. The strain feeds into both mechanisms, but the mechanisms are for different purposes and should operate differently.

Rewards are meant to maintain permanence of data. So the reason strain feeds into that mechanism is the strain puts permanence at risk. But there are other factors of permanence that should be addressed besides the current level of strain. For example the existence of redundant copies of chunks is important for permanence, so rewards should also be based on that measure (maybe using periodic audits as @jlpell suggests to measure the true number of redundant copies?). The ability to replicate a lost duplicate is important (ie go from N-1 back to N replicas), so perhaps the number of new nodes that are waiting to join should be part of the reward measure since they are the ones that will be ensuring this aspect of permanence?

The allow / disallow rules for new nodes joining the network have not been discussed, I’m not sure the degree that they impact the economics of storecost and rewards, or the security of the network, but I feel that it has significant importance because it affects who rewards go to and thus who can use those rewards to further their interest in the network.

My feeling is reward amount should be based on the queue length of new nodes (ie nodes that have all the chunks they need for when they’re inserted into the routing table, but are still waiting to officially be part of the network, maybe there’s some better way to do this but that’s my current thoughts). If there’s a lot of nodes queued the reward may currently be higher than necessary. If there’s too few nodes in the queue the reward amount may be too low. I think this sort of ‘fully primed’ queue is necessary otherwise churn becomes a significant overhead. Better to prime the nodes on a non-urgent basis and have them swoop in when needed rather than lose some node(s) and scramble to join new nodes ‘from scratch’ to ensure there’s no disaster. It’s more responsive to have primed nodes in the join queue, and they could also form a useful way to decide and adjust the reward amount.

12 Likes
6

As a major factor, yes. Although, as I point in a post a few months ago, I would also add another variable called the Dropout Ratio (the number of nodes that voluntarily leave the network). Together, with the queue length, could give, in an indirect but simple way, the health of the network to calculate the optimal StoreCost.

Another idea to consider is to use those 85% of the safecoin, yet to be created, to subsidize both farmers and uploaders. If we want to create a functional and universal network we need farmers to save data as well as the data itself.

This subsidy could be universal or applied only to public PUTs which would be, temporarily or not, cheaper than private PUTs.

7 Likes
7

Another angle is that when you have to pay to upload data, the size of the upload can also be used as a display of wealth. Let’s say the cryptokid next door buys a lambo to brag his wealth, then I answer by uploading a photo of his lambo with such a high resolution that it more expensive than his car - and verifiably so. Maybe not the most likely example, but you get the idea.

I think that bragging with your wealth is such a deep habit in human societies that wherever is a place to do it, it will be done. SAFE is going to be that kind of place, whether we like it or not. Difficult to say if this is going to be significant economic force or not. But I say it is certain that not everybody is aiming for the cheapest uploads all the time.

3 Likes
9

Yes I think this is probably the only real metric of stress/strain that’s useful. (Original post with Dropout Ratio is here, and also discusses join queues).

Maybe it’s possible to measure fullness / spare space somehow as a factor of stress but it seems tricky.

Maybe it’s possible to measure mean / median / peak bandwidth and latency as a factor of stress, but this seems very difficult to utilise since these values will be different between nodes A and B vs A and C vs A and D etc, so how does the network agree on the bandwidth and latency of A in that situation and when do those figures transition A into a stressful state? Maybe using relative values rather than absolute values, but still, I’m not sure how to use this as an input to storecost just yet.

Some types of malice or incorrectness will be easy to detect so could be used as a measure of stress, but is more likely to feed into a penalty system and from that would indirectly affect dropping out, so the original Dropout Ratio is more useful as an input to storecost and malice can be isolated from storecost. I feel that malice / incorrectness is mainly useful as an input for penalties rather than stress measurement.

So after that bit of brainstorming (not complete, if you can think of other possible causes of stress I’d be keen to know), it seems like measuring stress is going to mainly be down to Dropout Ratio. That’s a nice bit of insight @digipl.

One other aspect to consider, is there any significant distinction to be made between individual node stress vs aggregated node stress vs overall network stress?

Maybe stress and strain and health are all synonyms in this case…? Is there a most useful word to use? Strain and stress seem to imply some spectrum of negativity, whereas health may also have some positive aspect to the spectrum. Subtle distinction for sure, but the word being used implies whether only ‘survival’ is important (care about managing stress/strain) or whether ‘excellence’ is also important (care about maximising health)…? Gets quite abstract and philosophical at this point but I think it matters.

5 Likes
10

Would it be too sterile to instead of using relatively miscellaneous and undefined vocabulary on some spectrum, rather use defined measurements on a gradient that are categorized from unoptimized to neutral to optimized? Maybe too inhuman to even communicate to define the measurements in the first place? Haha. Very late and just spitballing.

2 Likes
11

I think whatever the details, @tfa makes a good point about three likely responsiveness to changes in storecost v reward. I think more will monitor and respond quickly to changes in reward than to storecost.

I wonder if it’s possible to make some estimates based on stakeholders in Blockchain systems. How miners and users respond to changes in transaction fees and mining rewards for example.

3 Likes
12

As I remember it from my experince, miners thinking is simple:

  1. You do your research, prepare hw.
  2. Tune sw to the best possible performance.
  3. As long as it is making more money than are your costs you dont touch it. If you dont have costs, you keep it running until the hw dies. People are lazy :slight_smile:
3 Likes
13

I’m sure many are like that, but how many, and how have things shifted over time due to factors such as greater awareness, competition, ease of switching from one chain to another etc.

I don’t think thought experiments get us far enough, so it would be good if there are studies. I suspect it’s easier to get data set transaction fees, but hopefully some miners have gathered data and eventually published it.

2 Likes
14

Far from convinced there is really that much crossover between bitcoin mining and Safecoin farming. The similarities are superficial IMHO other than the requirement for sufficient reliable bandwidth.
The stated aim from the outset has been to maximise the use of otherwise under-utilised resources. Contrast with the absolute necessity now to have specialised dedicated hardware if a wage is to be earned from mining BTC ETH or any of the other major coins.
As part of our duty of care to the planet as well as our pocket, it makes absolute sense to have the most efficient kit possible but until we know a LOT more about how the network will behave I doubt anyone should buy any kit they would not otherwise have procured anyway.
I reserve the right to maintain I never made this post once we have a few months hard data in though…

3 Likes
15

I agree with everything you say (for once :smile:). PS no editing.

Analysis of Blockchain behaviour won’t show us SAFE farming or consumer behaviour, but it gives us a baseline from which to extrapolate scenarios, and ideas of worst case etc.

I’m also are that human nature may push more similarity than those of us who take a broader view would like.

Anyway, please stop avoiding bash scripts and get back to doing my homework will you!

3 Likes
16

FFS canny even creep onto the forum during my lunch break…

You are so lucky there are no pubs open otherwise I’d be down for a good old-fashioned afternoon sesh.

3 Likes
17

It definitely is not simple and mining is super competitive and complex. AsicBoost is a great example of how far miners are pushing the boundaries.

If there are advantages to be found they will be found. In bitcoin mining they most certainly ‘do touch it’ since they even go so far as to follow the seasons for the best energy: “Over 80% of the miners in Xinjiang, Inner Mongolia will migrate in flocks to Sichuan, Yunnan, and Guizhou to take advantage of the [energy] discount, and they move back or sell their equipment after the dry season arrives in November.”

Applying this to SAFE and the economy, I’m pretty sure people will start investing intensively in areas that are the biggest bottlenecks, (which are currently assumed to be latency and bandwidth). People predicted ASICs for bitcoin but they came much sooner than expected and many other optimisations caught people by surprise. I suspect the same will happen for SAFE no matter what economic algorithms are put to use.

Just trying to add appropriate context and caution around farming; I feel it’s not going to be simple either in the design nor in the lived experience.

I wish I had a bunch of resources on hand, I’ve read lots on this but they pass into history for me, but here’s one such article that I think is informative

Some very relevant quotes
“These assumptions tend to be incorrect.”
and
“you will always be able to create custom hardware that can outperform general purpose hardware.”

I feel that this means there needs to be an accepted (ie hardcoded) level of ‘bad-performance-ness’ to the network, otherwise the efficient players will always slowly but surely push out the smaller ones. It’s not a concept I like to promote, but it seems like an unavoidable tradeoff. If we want someone with a 1 Mbps connection to compete with a 1 Gbps connection we have to have some external force that levels things out. “The market” will always vote (inadvertently) for faster and better so some protection will be needed for the smaller players. Maybe I’m wrong, would love to see a design that shows it. My feeling is the only way to make it level for everyone is basing the economy on latency since there’s almost no room for improvement there, everyone is already fairly equal.

Really interesting conversation coming out so I appreciate all the discussion happening even if I happen to disagree sometimes I love all the comments.

9 Likes
18

At one time there was inclusion of an automatic “throttle” being applied to super-farmers that would reduce the advantage of elite hardware/software/bandwidth solutions. Something along the lines of a certain amount of production above the average metric being neutralized. Is this not still on the drawing board?

2 Likes
19

That last sentence is unusually strident for you @mav! And an assumption IMO. It’s true if there are no other factors, and it’s those other factors which create the levers we can use, and obviously you are well aware of that.

I haven’t thought about this since the early days and know far less about the Blockchain mining business than you.

So maybe I’m naive in still hoping that we can construct a ‘better’ network, even in the view of the market by designing for widest participation.

It’s a shame we can’t collaborate with Satoshi, his insights would be valuable in how to stop things better! Or maybe he’s here doing exactly that!

Anyway, I think we’re aiming for widest practicable participation because decentralising is the good we seek in order to deliver S. A. F. E.

There’s going to remain a market for AWS and at the same time there can be a market for SAFE. I just realised taking about “the market” isn’t helpful as it hides complexity and meaning so I’ll just revisit my early understanding along with the aim of widest participation.

My understanding was that:

  • we ensure that those with minimal costs and relatively little need to earn are rewarded sufficiently to ensure their participation in large numbers. So people using existing equipment at home, in businesses etc, and even mobiles at some point. This might mean they fill specialised roles to some extent, doing less performant things or things that don’t require very long before joining, but we need to be careful about that because an important part of their function is to compete against ‘professionals’ (and each other) in order to put downward pressure on rewards and keep the returns for those investing in advantage, low.

  • we do want, and will reward those who deliver better performance, which means there will be a commercial side to farming. But to maintain wide participation, this must not be rewarded to the extent that they can corner the market. (By scooping up so much of the rewards there aren’t enough left to encourage the first group to participate.) The lever here is that they will have much higher costs than most of the first group, so providing this applies at scale it can remain a brake on centralisation. Maybe this is wishful thinking?

I think the problem is how when to pull this lever, and then how hard, again I think this is what @mav is getting at, what exactly is the lever, or rather the barrier to acceptance and being rewarded?

Hence don’t give big advantages based on performance for gaining entry to allow wide participation, and latency comes in heavily for weighting distribution to maintain wide distribution of rewards. @mav?

I see I’m rambling a bit here to see if I understand you @mav, so please put me right as needed. I don’t want to spend a lot of time in this right now, but I do want to keep up with the discussion.

3 Likes
20

Satoshi could afford a non-squeaky jacket :slight_smile:

4 Likes
21

Squeakiness is a premium feature.

5 Likes