Disk billing#1841
Conversation
|
One odd thing is that the cost to enable billing changes between boots, by sometimes a substantial amount. I think it's due to install order and therefore what gets written after virtual-server gets installed. |
The right way to solve this is to get the initial RAM usage by scanning the entire database. That way, it doesn't depend on when virtual-server is installed. The scan may need to be split into multiple actions. |
…refore after auth)
Vserver resource balance caching and db-writes during reconciliation
recollateralize relay shortfall from enable-billing over time
hit the wrong button when submitting review
Disk billing
This adds billing for "objective" disk storage to complement the existing billing for CPU and NET.
The
virtual-serverservice now distinguishes between "rate limited" and "capacity limited" resources. Rate limited resources are those like network bandwidth and CPU, where there's a max throughput at any given time but that doesn't compound over time. Capacity limited resources are those with fixed limits over the lifetime of the entire network, like disk storage. Once disk is consumed, unless it is freed, it is permanently stored. Therefore, it deserves its own billing strategy.Capacity limited resource billing
Capacity limited resources are, rather than billed using a satoshi-proof-of-work-style price adjustment algo as we do for rate-limited resources, billed according to an AMM style relay. More precisely, as storage is consumed, it approaches the max amount of storage available for the network, and climbs up a price curve. At full disk consumption, the area under the curve (which is the total amount of tokens that would have had to be paid into the relay to purchase the disk consumption) is equal to the total token supply of the network token.
Note
I rewrote my git history to take ~70 commits and turn it into 6 that are more sanely grouped. Probably not compileable at the intermediate commits.