About the EOS Resource Model Proposal
Answering block.one’s call to give feedback on the new EOS resource model, EOS Argentina has discussed internally the implications of the proposed changes and would like to open the discussion to the EOS community with the following comments.
On the pricing function
In the proposal, the price as a function of utilization u is
p(u) = min_price + (max_price — min_price) * (u ^ (exponent — 1.0))
where min_price, max_price and exponent are configurable parameters, and u goes from 0 to 1.
Our concern is that this function does not seem to be sufficiently justified. In particular, we believe there should not be a maximum price. As in RAM pricing, by using a proper function the price may go from zero to infinity.
The main problem associated with imposing a maximum price is that nobody knows how the market will behave in the future. If we attempt to solve this by setting a very high maximum, then we are prone to suffer inefficiency in a normal case scenario, unless the exponent parameter is too high. But if exponent is too high, then the price will be almost equal to min_price for a very long u interval. The latter situation means that in a low demand scenario, the price is being directly imposed by a parameter instead of letting the market find the price.
A possible solution to this issue is to use instead a function more similar to the functions typically used in automated market makers. For example:
p(u) = K1 / (1 — u)² — K2
Where K1 — K2 will be equal to min_price, and C = 100K1 — K2 will be the price at
u = 0.9. Thus, we are proposing only two configurable parameters like min_price and C. Alternatively, the exponent 2 may also be configurable to a number larger than 1.
Further comments
- It sounds reasonable to use min_price = 0 for CPU.
- min_price > 0 for NET might be useful to disincentive large data transactions, therefore reducing the costs of storing the blockchain history. The sustainability of storing the full history is necessarily conditioned to a sufficient decrease of storage costs over time. Still it might be the case that a careful increase in the cost of NET can be beneficial for the network.
The above observations lead us to think that it might not be a good idea to have the same parameters for both CPU and NET.
EOS Argentina is currently discussing our observations with part of the Block One Team and other Block Producers. Nonetheless, we believe that changing the Resource Model is something that should involve all of the community, we invite anyone who has comments or improvements to the proposal to reach out to us through any of the channels shown below.
Telegram: EOSarg |Twitter: eosargentina |
