Rapid storage price changes adversely impact UX/DX

[awmacpherson]

Strategic context

Pricing UX problem impacting cost predictability and hence viability for professional use cases.

Problem statement

Swarm's dynamic storage pricing means that users cannot reliably forecast their costs per byte over an interval greater than a single round (twelve minutes and forty seconds). Equivalently, one cannot specify a fixed TTL for a storage quota at purchase time.

If one's goal is, say, to host some dataset for 90 days, the most cost-effective way to do this on Swarm today is to purchase a short-dated quota and keep it topped up as long as one needs, paying whatever the cost is at the time. One can estimate what the cost of a 90-day quota would be and pay that amount up-front, but that has the risk of overshooting (hence wasting money) or undershooting (hence needing a top-up anyway, or expiring early).

Concretely, the current state of price updates presents two challenges:

• The price updates are much more frequent than the intervals over which people usually want to make infrastructure spending decisions.
• After compounding, price changes over those intervals are much larger than what developers are used to.

Suggested approach

Before we can even evaluate candidate solutions to this issue, some basic questions need to be answered:

• Does the current system work? Assess the extent to which the system actually is "dynamically self-regulating" [BoS 3.4.5]. Evaluate the strength of the effect of price adjustments in practice on supply and demand over different timescales in Swarm. Make comments about system stability.
• What are the costs of the current approach? Assess potential externalities of the dynamic price adjustment mechanism. Try to quantify its effect on users.
• What properties should storage pricing have? How will we know if we've solved this problem? Formulate objectives for pricing range and stability expectations based on market research, target audience, and user feedback.
• How much and what type of intervention are we prepared to consider? The current mechanism cannot know about the current goals of Swarm and has extremely limited capacity to respond to the prevailing market context. Sometimes, new research or shifting goals or market conditions may reveal that a different design or parameter tuning is preferable to the deployed version. To realise this improvement, intervention is needed. How often are we prepared to intervene, and what types of interventions are allowed? Even if the long-term goal is for systems to pass the "walk-away test," i.e. be zero-intervention, can we accept a "high-intervention" solution as a stop-gap solution to UX problems while we work towards a more sustainable approach?

[kosmostasis]

This is quite interesting. I don't have specific takes on the open questions, though I've had my own experience overshooting and undershooting. One unexpected occurrence that came to me while reading your proposal, was having something similar to what Superfluid does for token streams, to set a budget to be streamed/paid over time, or even conviction voting, where users stewarding a pool of resources dedicated, for example, to maintaining data considered public goods available, could signal their preferences in real time.