Makes me curious if there would be any desire from app devs for the network to offer cache at some cachePut rate and for farmers to sell cache to the network.
Apps being able to use a cache would possibly speed things up and allow consolidation of data before hard Put.
Obviously would be a future feature like safe compute.
What I was trying to point out is that the way paying for PUTs (proportional or only full) is done results in more cost because to condense data requires extra PUTs since you must get the data onto the network to condense it. And thus you must have more cost.
The above does not include you condensing your own data, and that is a good thing to be done anyhow since it will save costs no matter how the PUT cost is determined.
Obviously there maybe some APPs that are condensing and store anyhow. But really you are not implementing condensing to overcome PUT cost since that is the purpose anyhow.
I think this could be addressed with a combined fixed (PUT) and variable (size) component to the price of every transaction. The variable component could be tiered (i.e. 1 mb costs more per byte than 1 gb). As an example with easy numbers in fiat, uploading a mb of data costs $1 (FC) + $0.50 (VC) while uploading a gb costs $1 (FC) + $5 (VC).
If something like this has already been proposed further down the thread, apologies. Just catching up on this topicā¦
not a tech expert, but wounder if the algorytm for farming and storecost will be taking into consideration the stakeholders- so that the award of farming will not be short term big in terms of safecoins and cost of puts will not be big . Is that even adjustable?
I expect most things will be put to the test with Fleming and Maxwell releases before real network launch, so yes, testing, adjusting, testing, adjusting until itās running smoothly enough to launch with real coin.