Proposal — Part 1: A different EOS RAM Market Model

Any proposal for a better solution should always start by establishing a valid foundation on the present reality, which is what allows us to bridge into a new model, but question or contradict its ruling assumptions before objectively proposing the added value of our own perspective and different take on the given subject. Also it shouldn’t stretch too far from the present reality, even if you have a broader picture on how to improve something, otherwise the cost of bridging the old to the new can get significantly costly. But you can always tease.

I will therefore begin this proposal by doing just that and invite everyone else to follow my steps and either support this proposal or actively question or build on it in a similar way. For the prelude I will start with the following quote:

Because the amount of RAM available to a single computer is limited by Moore’s Law and other technological advances, RAM is fundamentally scarce.
- Daniel Larimer

For added dramatic effect, try reading the above sentence, in your head, with a Morgan Freeman accent. Now seriously: it is a clean and smart introduction to convey the value and limitation of RAM which Daniel Larimer addresses in his article EOSIO RAM Market & Bancor Algorithm.

Myth

The problem with the above quote is that it sets the tone for the rest of the article, like an underlying bed on which Daniel proposes and justifies a model for RAM management and economics, that in my personal opinion is however not good at all. And I say not good, not because I consider the solutions he proposed and built into the system invalid, but because it conditioned his perspective, and ours, about this resource to start with.

RAM is not fundamentally scarce. It is quite abundant, it is very easy to buy, it is quite easy to upgrade and it is relatively cheap if you consider that the BP (block producer) in 58th position earns, at the time of writing, 118 EOS daily just for having enough votes and being in standby. The top BP earns 965 EOS per day. And 1 EOS is valued at around 8 USD nowadays; imagine how affordable it will be to add physical RAM if EOS trades for 20, 40 or 80 USD in the not-so-distant future. The one thing I vividly underline in Daniel’s words related to RAM, or anything else for that matter, is that nothing is for free.

Therefore in his attempt to ration limited network resources Daniel proposed different solutions for CPU and bandwidth management and availability which, in my opinion, were ingeniously accomplished. Due to RAM permanent usage requirements though, unlike CPU and bandwidth temporary usage, it makes sense that this resource it dealt with differently since scarcity might pose an issue. Also we can all agree, I believe, that scarcity establishes, and should establish, a direct growing relation with the resource’s cost.

The fallacy here though is the same as in the argument about food being scarce. Food is undeniably a problem still in 3rd world countries, despite every day 1st world civilizations throwing away tons and tons of good and untouched food. Is food really scarce or is it more a problem of access, production and distribution? Well food can be actually both scarce and not, in relative terms as we acknowledge when comparing different countries, but in more absolute terms food is actually not scarce at all when the equation weighs in global availability and waste.

So, since we are in a global decentralized network, let’s weight in availability and waste. In a network with 64GB of which 52GB of RAM are already reserved, at time of writing, but only about 1GB of it actually being used, is memory really scarce or is the economic model behind it driving the cost and promoting the fallacy of scarcity? I mean the available memory is there regardless: 64GB cost the same for BPs whether they are being actually used or not, whether someone is trading on them or not… so where is the real value of paying for reserving vs paying for using RAM? How does that relate to the actual cost of adding RAM to the system?

Market

Contrary to Daniel’s attempt to ration memory resources and avoid scarcity with the implemented market model, scarcity is actually being created by the market itself where memory is treated as an asset and not a technical resource.

Many individuals and “corporations” end up trading on RAM and in the end not only 51GB go to waste but also the cost to actually consume this resource grows in a stupid-like curve shape to no one’s actual benefit other than monetary. When only 1.9% of the reserved RAM (1.56% of total RAM) is actually being used it’s clear how inefficient this model for RAM management is. Not because monetary drive is an invalid premise but because the resource fails to accomplish its purpose. A world with 98% resources still available doesn’t seem scarce at all, unlike one with 81% resources already unavailable regardless of their usage — and yet we’re talking about the same world here.

So in a world where RAM is a basic resource and whose consumption might bring in scarcity, how do you manage this resource?

The free market model clearly doesn’t fit here since there’s no competition and supply is “government issued” if you will. It’s equivalent to a state monopoly who dictates when and how much RAM is available and leaves no space for healthy competition. So a free market without competition is not a free market and since there’s no way for someone to “go to the store” and buy RAM to run their own dapps, we can see the current solution more as a totalitarian capitalist model. This is where the whole thing crumbles and falls into speculative realms.

Absurd is to establish that food is to be sold and not eaten and that is the same consequence that the current RAM model brings to the EOS network: pure economic value. Not that food doesn’t have a cost and should be therefore charged for, but if in the end no one eats it: why food? You might as well call RAM something else like DIAmonds, RUBies or PERls since RAM as a resource is clearly not serving its underlying purpose as a technical requirement for the system to grow.

Proposal

It seems clear to me that a better alternative would be to pay RAM per usage instead, where there’s no speculation anymore and the cost of RAM changes directly with the network’s memory requirements. It’s a fair provisioning of network resources that serves RAM to whoever produces content/value first and is automatically regulated by inflation, scarcity and supply rates.

These last decades offered us many answers in regards to efficient alternative resource management models from resource-based economics to usage-based pricing strategies. Nevertheless I’ve been witnessing more and more complex solutions for the RAM issue being discussed and proposed that nevertheless still fail to address the fact that RAM shouldn’t be an asset but a technical resource.

The underlying proposal I would like to bring to the table is very simple and straightforward:

• RAM as a natural resource
  As a natural resource RAM should be always available and be sustainable: too much of it and it’s not cost-efficient for BPs; too little and it compromises the system. RAM should therefore be produced/added in a consistent and sustainable way as well as its distribution.
• RAM usage drives cost and supply
  Instead of paying to reserve RAM at speculative market prices, RAM is paid per usage: the more you use the more you pay. Also the more RAM is used, the more BPs should supply and when needs outgrow supply rate the cost rises and when supply outgrows usage rate the cost falls accordingly.

Implementation

The difference between temporary CPU/bandwidth usage and permanent RAM requirements that led Daniel to pursue a whole new direction in regards to this resource, doesn’t actually need to be dealt with in such a disparate manner.

The same way a user stakes EOS for CPU and bandwith usage, one can also stake EOS for memory usage, the difference being that these are not restored with time but traded and locked in a more persistent way.

Instead of reserving memory and paying for it like the present solution, a user can stake EOS for memory usage only. Then as a user needs to store data, the system automatically trades those staked EOS for RAM in direct proportion to how much space one needs in regards to available memory. If a user wants to delete or change those records, memory can be traded back for EOS. If a user runs out of staked EOS for RAM then any attempt to store more data in the system will fail and throw an error, forcing a user to buy and/or stake more EOS for RAM usage if he wants.

To prevent scarcity at any given moment a user shouldn’t be able to claim more RAM to himself other than the equivalent percentage of EOS he holds and stakes or that other users might eventually delegate to him — a complementary solution that would also need to be implemented. A user who stakes 1% of total EOS supply for RAM cannot take more than 1% of the total RAM by default. If a user overflows his RAM entitlements due to inflation, then the cost to acquire more RAM for that user is proportionally higher than for the rest. This measure creates a usage cap to allow everyone to claim memory if needed and regulate cost of usage overflow.

As RAM is added to the system, availability increases, the cost of persisting data drops and users can be refunded in RAM staked EOS. To keep a healthy system the rate and frequency of adding RAM shouldn’t be inferior to that of inflation which allows some predictability as well. BPs only need to keep up with usage demand and inflation in order to reduce debt / overflow and allow organic growth of the network.

If all this sounded a bit too much to follow let me draw it for you below.

Example

Initial Setup
A network with total supply of 1000 EOS, a daily inflation of 12 EOS added to supply, 64GB of RAM and 3 users with different balances, staked EOS and RAM proportionally made available to them.

Day 1
User A uses 10 EOS worth of RAM = 655.36MB.

Day 2 — Step 1/4
Inflation added to total EOS supply, available RAM per user drops, RAM overflow caps overall available RAM.

Day 2 — Step 2/4
User B uses 9.88 EOS worth of RAM = 639.8179MB.

Day 2 — Step 3/4
User A and B need 7MB more of RAM each, RAM for User A is more expensive than for User B, User A needs to stake more EOS for RAM, RAM cap is lifted afterwards.

User B paid only 0.1081 EOS for +7MB of RAM while User A paid 0.2281 for the same +7MB of RAM since he was in debt. This way if User A takes more RAM that would be otherwise available to other users without staking/paying for it, the cost of adding more RAM increases for User A.

Day 2 — Step 4/4
More RAM is released into the system, users are entitled to use more RAM and are proportionally refunded in RAM staked EOS since cost of persisting data in memory dropped — more supply.

In a way you can say that RAM resources are released not with time like CPU and bandwidth but with system availability.

All this guarantees that there will be always free memory available, removes speculation from RAM itself back into the EOS token (which is great!) and RAM price and availability is stabilized on a regular basis.

Continue reading in: Proposal — Part 2: EOS RAM Market Dynamics.

Copyright and attribution are implicit.