SAFE Controls, Objectives, and Constraints - Brainstorm

Autonomi Network Token (incl (e)MAID)
1

There has been ongoing discussion about how to structure reward/pricing algorithms for the internal SAFE network economy of PUTs, GETs, and Safecoin. Forum threads exist going back to 2014 that discuss various aspects of this topic. I’m sure there were many late night discussions in Troon that date back even further. Forum posts containing background information of interest are Safecoin RFC 57, the prior Safecoin RFC 12, as well as some great work performed by @mav and @oetyng on network simulation in Perpetual Auction Currency. Other discussions such as the Put Price Controlled by Supply/Demand and More Economics (15) threads also offered some interesting ideas.

The SAFE Network ecosystem is a complex machine whose operation is greater than the sum of its parts, and the internal economic drivers at play are likely to be no different. The ability for the network to interact with users within the same resource marketplace has interesting implications. Classically, we can view this feature of the network as a closed loop control system having various inputs, outputs and internal settings. The optimal design of this control system offers a unique opportunity to provide the world’s first autonomous data network with the ability to foster its own growth and development through economic mechanisms for the purpose of ensuring the survival of the perpetual web, well … in perpetuity.

The purpose of this thread is to take a step back and brainstorm the main goals or objectives we would like a hypothetical network control system to strive for. I’d like us to also consider constraints and other control parameters of interest. Much of this information is already spread throughout the forum and it would be great to funnel the highlights here as well. For example, consider @Deadloch’s concerns in More Economics (15) and @mav who has already done a lot of the heavy lifting for us in SAFE Network Health Metrics.

We are all well aware that premature optimization is the root of all developer evil. However, it’s not difficult to infer certain properties that are more or less beneficial to network operation as others have already done in prior forum posts. I’m not sure where this will take us, but hopefully the hive mind that is Safe Network Forum will figure it out. The focus here is on network control and regulation via Safecoin incentives, ie.“the carrot”. Other aspects of network control with regard to punishing nodes for improper behavior, ie. “the stick”, that do not have a Safecoin related mechanism are out of scope for this discussion.

Let’s begin with some high level questions. I’ll give an overview of my thoughts in the answer portion and you can tell me why I’m wrong or lucky.

1. What is required to ensure the survival of The SAFE Network and the Perpetual Web?

  • Hardware Supply Chain, ISP/Mesh infrastructure, Electricity, Software Tools, Developers, Operators/Farmers, Content Producers/Creators, Clients/Users, Long-term secure and performant methods/algorithms, great design features and user experience, rapid adoption, unlimited growth in data, adaptability, secure reboot capabilities.

2. In what direct ways can Safecoin be used as a tool to regulate or assist network survival?

  • Pay the Farmer/Operator (PtF) : Maintains or increases Farmer participation and resource contribution.
  • Pay the Producer (PtP) : Increases data contributed to the network.
  • Pay the Developer (PtD) : Increases user access to data, adaptability, great design features and user experience.
  • Pay the Hacker (PtH): Improves performance, security, and adaptability by identifying vulnerabilities or optimizations and ensuring rapid improvement.
  • Pay the Client (PtC): Increases user adoption rate.

3. By what indirect ways can Safecoin be used as a tool to regulate or assist network survival?

  • Serve as a medium of exchange for goods and services other than those offered by directly by the network (storage, retrieval, communiction, computation).

4. What are the four most fundamental objective functions the network should pursue when deciding on how best to spend or save its Safecoin? Are these equally important or is there a hierarchy?

  • Maximize network Security. (Primary Importance)
  • Maximize network Growth. (Secondary Importance)
  • Maximize network Performance. (Tertiary Importance)
  • Minimize network Cost. (Quaternary Importance)

5. What are some “health” or “performance” metrics that can be used to mathematically describe the network’s state of security, growth, performance and cost? (Items might apply to more than one category.)

  • Security: Number of elders per section, nodal age distribution, number of malice events, number of ddos attacks, number of spam events, number of encryption indirections, section relocation rate, number of hops per communication, section routing table size, number of vulnerabilities patched and unpatched, unexpected departure rates, help me here @mav …

  • Growth: Number of sections, number of vaults per section, vault size, spare storage capacity, free storage capacity, number of farmers, number of developers, number of producers, number of hackers, number of clients, transaction count, PUT rates, GET rates, transaction size, use/need for divisibility in payments, number of consensus blocks per section, rates of change of all these things…

  • Performance: PUT rates, GET rates, number of hops per communication, p2p bandwidth, p2p latency, section cache memory, Exaflops,rates of change of all these things…

  • Cost: The “safe price” for a PUT, safe price for a GET, expected departure rates, percentage of Safecoin which the network seeks to hold in reserve (ie. network greediness).

6. Should there be any Constraints imposed on the network’s prime objective functions? Are there possible scenarios where we would ever want to constrain or limit growth, security, and/or cost?

  • Security = No
  • Growth = Maybe
  • Performance = Yes
  • Cost = Yes, if the network reserves are too high/low.

7. Should there be constraints/targets imposed on the health and performance metrics?

  • Yes, hard limits some cases. (Ex: section sizes allowed to range from 64 to 256 nodes +/- some tolerance, the GET price can never go above max unfarmed SC in a section, the PUT price can never go above the max farmed SC in a section )
  • No in others. (Ex. the network has no control over the number of spam events).

8. What are some other subtle ways to use Safecoin to reward human behavior that helps the network meet its goals for security, growth, and cost?

  • Provide higher reward rates based on trust level / nodal age. Extend the concept of nodal age to all user categories so this could be done separately for farmers, providers, developers, hackers, clients etc. Age would need to be a measure of network time, not wallclock time. How does one quantify the network’s trust in a developer?
  • SAFE Gifts. The network picks farmers, developers, producers, or clients at random (assuming they have reached a certain age) and sends them some coins as a gift just for taking part in the network.

As I mentioned at the beginning of the thread, I feel this exercise will assist in the development of a real closed-loop network control algorithm. Ideally, we will end up with a more detailed and more exhaustive design spec similar to @mav’s first attempt with the SAFE Health Metrics. The safe-cli and a safe vault with test safecoin is now in the wild, its a good time to start thinking about these things again in more detail.

16 Likes
2

Not sure if you’d call this a cost but what about ‘cost of slowness’, as in do end users get their data fast enough? What’s the cost of them getting it slightly slower? Or a lot slower? The cost to them and the cost to the network?

I think in general my point is the list of ‘cost’ concepts do not put enough emphasis on the end users who provide valuable growth resources (word of mouth marketing, usage and popularity to lead up to the too-big-to-fail stage, embodiment of the existential purpose of the network). Their costs matter too, even if measured in difficult units such as ‘time waited’ or ‘learning curve’ or ‘misinformation encountered’.

And more generally, I think consumers are very high on the list of stakeholder importance, but don’t really get much say in the metrics in the original post. Not sure how to reconcile it, but it’s something that keeps coming up in my mind.

Well, we wouldn’t want to use excessively large keys, or an incredibly secure but slow signing algorithm etc. So I think there are constraints on security.

I’ve also heard that growth and security are interrelated (ie growing too fast or too slow would affect the security) but I’m not so clear on that relation. But if the relation exists, then security must be constrained in some way.

I’m glad to see some numbers at last. What are the reasons for these numbers being suitable? I’m not saying they’re wrong or should be changed, just, why these numbers? What are the trade-offs that have been considered?

Really lots more to say but time is limited just now so let’s start with this! Thanks for starting this topic, should be interesting.

4 Likes
3

These are good points to discuss. Lumped into the “Growth” objective is latency, bandwidth and computational performance. When considering possible control mechanisms for maximizing performance/growth while minimizing cost, a variety of pareto optimal strategies are likely to arise. For the moment consider only these two objectives. At one extreme you have maximum performance, with the highest associated cost. At the other extreme you have minimal performance with the least associated cost. In between there exist a variety of equally optimal strategies that balance these two objectives. Only through analysis of this pareto optimal set, the imposition of some constraints that prove some strategies to be infeasible, or reliance on additional information can one determine which choice of action offers the best “bang for the buck”. This is essentially what you are describing above. Consider this toy example:

  1. A section in the network is able to provide performance level P for a GET reward of G. The section reduces the GET reward to 0.5G and the resulting performance level drops to 0.9P. This would be considered a preferred state of operation because the network was able to reduce the GET reward by 50% while only losing 10% in performance. This also allowed for a reduced PUT cost.
  2. Although the network performance has only dropped 10% and PUT costs are down, clients are very unhappy with this slight reduction of performance. Not only that, but they are impatient and expected a significant performance boost of at least 1.4P by now. The sections need to increase GET rates. Rates rise to 0.75G, 1.5G and 2G with corresponding increases in performance of 0.95P, 1.5P, and 1.6P. Since there was only negligible growth in performance by increasing GET rewards from 1.5G to 2G, the network settles on the preferred GET rate of 1.5G, which also satisfies the objective constraint that the minimum acceptable performance must be greater than 1.4P. For the moment, performance has been maximized and cost has been minimized in a pareto optimal manner.

In the “Cost” objective I neglected to list the subcategories of all the PtF, PtP, etc. rates used to reward the end users for their efforts. Do these not adequately reward the end users for the various roles they play? I do like where you are going with time cost. Minimization of time and opportunity costs to the end user as a means to improve growth and with it the security enhancement this growth brings with it.

By ‘consumers’ do you mean the clients? If so I think you have a point here. That’s why I listed the PtC, “pay the client” or perhaps more appropriately defined, “pay the consumer” reward mechanism. What other mechanisms can you think of?

Yeah, this is a tricky one, I think you’re right. There are indirect constraints based on the a minimum acceptable levels of performance, which rules out certain security measures. Although, it does bring up the question of whether or not the user should be allowed to pick their preferred level of security for a corresponding reduction in performance (an important security vulnerability mitigation technique that deserves its own thread in the lounge). This also shows how lumping network “performance” in with the growth objective has a downside. Originally I had considered 4 network objectives (Security, Performance, Growth, Cost) but but thought it necessary to reduce them to three since it is difficult for humans to think 4D. Since no one else has commented yet, I may edit the OP if you think that this differentiation is better.

This was only an example to get people thinking I’m afraid, the selected numeric values were subconscious. When I think of section sizes and section splits, it reminds me of cellular division, or when bee/ant colonies get too full and split to expand to new locations. For biological cellular division there needs to be two replicated copies of all the necessary subparts.

I’m a fan of biomimetic design, and like to think that sections (cyberlogical cells) should do the same. So the distribution of elders, adults, and child vault sizes is roughly the same in the two sections following a split. This perspective doesn’t necessarily impose hard numbers, but demands that the maximum section size before a split is at least double the size of the section when it was formed. I think the network should be allowed to optimize initial and pre-split section sizes within broad constraints as it sees fit based on the Growth, Performance, Security, and Cost objectives. (Yeah, I’m editing the OP to differentiate Growth and Performance.) The way I see it, the absolute minimum the section size must be equal to or greater than the minimum replication factor, so for now that looks like 8x. A reasonable hierarchical breakdown that comes to mind for a reasonable constraint on minimum section population is this : 16 elders + 32 adults/workers + 16 infants = 64, but obviously this distribution is a candidate for optimization.

It’s difficult to reason about the numeric values without considering vault size and resource proof performance. If we further differentiate different hardware platforms in the same way that cloud providers offer micro, small, medium and large compute/storage instances, and require some distribution of per node resource capabilities with regard to storage, bandwidth, latency, and compute; then we are looking at minimum section sizes of 128 to 256 nodes that respectively grow to 256 or 512 nodes before a split occurs. Again, I’m more in favor of giving the network reasonably wide tolerances and letting (evolutionary) optimization subroutines identify what settings achieve the growth, performance, security, and cost objectives most effectively.

1 Like
4

Based on @mav https://forum.autonomi.community/t/perpetual-auction-currency/29488

I would add hard top for auction system to not allow farm more SafeCoins than is maximum supply.
At 85% SafeCoins left there would be max 1:8,5 ratio for PUT:GET
At 10% SafeCoins left, there would be max 1:1 ratio for PUT:GET
At 1% SafeCoins left. there would be max 1:0,1 ratio for PUT:GET

Reward = (Summary of PUT in last 24h x StoreCost) / (Summary of GET in last 24h) x (ratio)

This means that with ratio 1 is total SafeCoin paid for all PUT in last 24h (or any other set time period) about same as total Reward paid to all farmers.

In an auction people could choose smaller ratio based on there votes.

In this system not many GETs means bigger average reward per each GET. This could lead to not motivate people to overflow network to farm more coins.
Low demand to pay for PUT or low StoreCost means overall low reward per GET.
Farmers would like to set StoreCost to allow as much PUT possible at highest StoreCost the market will accept.

Formula for hard top ratio is:
(Farmed coins left in %) / 10
can be changed to (Farmed coins left in %)^n / 10
with n=2 or 3…

I would like to see to not have too big range to set ratio to make UI simple.
The similar system can be used to set range for StoreCost. Than user would set StoreCost and Reward ratio.

EDIT: After testing that only less coins can be farmed with ratio bellow 1, than the hard limit to ratio 1 can be moved to 99% of all farmed SafeCoin. New ratio formula would be (Farmed coins left in %).

1 Like
5

I’m not clear if you meant this in general or specific to the safe network, but for safe network I’d say this is the case, and it is because the network uses (required operations of vault)*(time) as some sort of proof of work. If the network is expanding quickly, then it would seem to imply that vaults are contributing less work before obtaining more prominent roles in the network. This means the cost of attack could be lower.

Personally, I like the idea of using stake to bond vaults. I think that if the vaults are bonded by more than just their node age then the network should be able to grow more quickly. Of course the downside of this is that it isn’t as inclusive since not everyone has or can afford to acquire SAFE coins. But I’m starting to get into ‘stick’ instead of ‘carrot’ territory due to the implied slashing, so I’ll stop typing now.

1 Like