A Detailed Analysis of EOS rentbw New Resource Model
Analysis by Dexaran in collaboration with Polar.io / EOS Asia
The new resource model proposes to eliminate the ability to rent resources at Resource Exchange (REX) and resource staking and introduce a resource rental market instead.
The main difference between the rentbw model and the previous CPU/NET staking/ REX renting is that in an old model there was an assumption that the total amount of EOS corresponds to the total amount of resources the network can provide and a certain fraction of this resources can be permanently owned by a user no matter if it is utilized or not.
The new resource model suggests that a user can only rent a certain fraction of resources for a specified period of time which means that the amount of actually available resources for this user is dependant on the overall utilization of the network.
The main goal of the resource distribution model is to ensure that resources are being used efficiently without downtimes and unused shares of physically available resources.
Understanding EOSIO resources
EOSIO is a distributed application execution platform that features two main resources related to this proposal: CPU bandwidth and NET bandwidth. Most notably CPU is the bottleneck of most processes on EOSIO network. In fact CPU is provided by physically existing processors of Block Producers that continuously operate network. CPU can physically perform a number of operations per unit of time. EOSIO network users compete for the ability to make BP CPUs perform their actions. If a user owns 10% of EOS total supply then he may make BP CPUs work on his dedicated tasks for 10% of their total operation time.
The user can constantly ask the network to process his actions until the user's resources are exhausted. Each processed action consumes a certain proportion of the user's available resources. Resources are fully replenished every 24 hours, so “users CPU bandwidth” is the amount of time that the user can load the BP's CPU each day.
It should be noted that no matter that BP CPUs are operating the network 24/7 the actual amount of CPU time available per day is not equal to 24 hours. The max_block_cpu_usage variable determines the amount of CPU time that can be consumed at each block (currently set to 200 ms at EOSIO mainnet). Block time equals to 0.5 second so EOSIO network handles 0.4 CPU seconds per 1 realtime second or 9.6 CPU hours per 24 realtime hours.
What is wrong with resource staking?
In other words, if there were only 1000 EOS on the network, and the user staked 300 EOS for CPU, then he actually allocates 30% of the total network bandwidth for himself. In this case a user may never utilize this allocated resources but he will permanently subtract this amount from what the network can allocate for others no matter that these resources are physically available if the user does not utilize them. It’s not just big stakers: everyone who staked, whether they might be sleeping or working, uselessly put a part of the network computation power to sleep.
What if the user has resources staked but never uses them? - In this case, the network will refuse to allocate unused resources to those users who may need them.
In fact, the network can be used, and there will be a high demand for resources, however, a certain part of the total resource pool will be allocated for inactive users and thus will never be used in reality. As a result, active users will not be able to use the network at full potential.
What is wrong with REX?
We designed the REX to use an algorithm that raises the price toward infinity as the remaining supply of EOS available to rent approaches zero. Recently the REX got into a situation where there was no EOS available to rent at any price, because it is possible for those providing EOS for others to rent to recall them at will. We did not anticipate that such a large amount of EOS would be withdrawn from the REX given the expected demand to earn.
REX is not a resource market. It should be noted that no matter the "algorithm that raises the price toward infinity" the actual APR of sending EOS to REX at the moment when it was exhausted was around ~4% which is a very small amount and not a sufficient incentive for EOS owners to engage in REX thus providing the supply as a response to high demand.
At the moment when demand was very high the lack of incentives to provide the supply resulted in a situation where there was no EOS available to rent at any price (because the lender can not set the price and can only lend EOS at the price dictated by this algorithm which is relatively low no matter the demand).
rentbw resource rental in detail
The new model suggests that the rentbw function must become the main method of obtaining resources at EOSIO mainnet. Let's take a closer look at this function, as this is the main addition to the system that users will interact with. The function takes 6 arguments:
-
const name& payer: who pays for the resources, similar to who pays the rent at REX -
const name& receiver: who receives resources, similar to who received them in REX -
uint32_t days: the number of days for which resources are rented. It is important to understand that the user DOES NOT SPECIFY these time frames. The timeframe is determined by the rent_days variable of the system contract. The user only needs to duplicate the value of this system variable with this argument when calling the rentbw function. If the value specified by the user differs from that specified in the system contract, the transaction will fail. So, if the system contract only allows users to rent resources for 30 days then user can only assign 30 days here. -
int64_t net_frac: the fraction of total NET resources that the user wants to rent. The 10^15 value of this variable will correspond to 100% of the resources managed by the rentbw system. -
int64_t cpu_frac: the fraction of total CPU resources that the user wants to rent. 100% = 10^15 -
const asset& max_payment: The maximum amountpayeris willing to pay. Tokens are withdrawn frompayer's token balance.
The resources are then undelegated after the loan expires. Undelegation does not happen automatically but two expired orders are checked and undelegated at the same action at a time new loan is submitted. There is a rentbwexec function that also serves to process expired loans and return resources to the rental market.
How it works
General idea of the proposal is to make resources available for rental in exchange for a permanently paid fee. The higher the network utilization - the higher the fee to rent new resources is. Fee calculation function implementation can be found here.
As it is shown in this article, the price increases instantly after each increase of utilization but it drops gradually over time after the expiration of each loan.
In the proposal, the price (the amount of fee paid for the resource rental) 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.
The new model is implemented in a system smart-contract (see rentbw.cpp) and it will be part of the eosio account on chain. This contract suggests that users must rent resources for a specified period (currently proposed 30 days) paying a specified fee. The amount of fee required is dynamically calculated at the moment of payment. The fee is then channeled to REX pool thus giving EOS owners the ability to benefit from this new system.
A user must submit a transaction asking for resources rental. Since fee is dynamically calculated at the moment of the request processing a user must specify the "maximum resource rental fee" that he is willing to pay for the given fraction of resources. If this fee is sufficient then the resources would be granted to the user and the overpaid amount would be refunded. Otherwise the request fails.
A user can request a certain "fraction" of the overall physically available resources managed by the rentbw market. The minimum available rent share is determined by the rentbw_frac variable.
The eosio.reserv account
The eosio.reserv account is deployed and it is used to configure the rentbw system. In short words this account is a place where the rentable resources are hanging until someone rents them. After the loan expire the rented resources return to the eosio.reserv account.
Transition from staking & REX to rentbw model
The contract is designed in such a way that it allows for smooth transition. The contract can be configured to manage a certain share of overall network resources and then adjusted to increase or decrease this share on-chain. The adjustment is done via the config_rentbw_function.
During the phase-in period, net_frac and cpu_frac represent the fraction managed by the market at the time the action is called.
There is a system configuration parameter which determines how much physical resources are allocated for which part of the system i.e. for staking & REX and for rentbw system.
It is planned to gradually decrease the amount of physical resources allocated for staking and shift these resources to rentbw market. It should be noted that staking will not be technically excluded from the system - it will just be less efficient i.e. the less resources are allocated for the staking and the more resources are allocated for the rentbw market the less CPU milliseconds a user will get for 1 staked EOS.
It is likely that this resource market will coexist with the resource staking model, but permanent resource staking will be disincentivized through the allocation of close to 100% share of the network resources to the rentbw resource market.
Example
Imagine an experimental system where
- 1000 EOS are total EOS supply
- Assume that initial configuration allocates 10% of resources for rentbw and 90% for staking
- 500 EOS are staked for CPU in a legacy staking system
- max_block_cpu_usage = 500000 for this example i.e. there is 0.5 second CPU per block or 24 CPU hours per 24 real hours
This actually means that a user purchasing 50% of total rentbw (0.5 * 10^15 frac_cpu) pool will get 5% of total network resources i.e. 1.2 CPU hours per day. Another user have staked 50 EOS for CPU and he gets 10% of total CPU managed by the staking model which corresponds to 2.16 CPU hours per day. (50/500 * 24 * 0.9 = 2.16)
Assume that the next step of transition shifts resource allocation to 30% for rentbw and 70% for legacy staking model. Now the user with (0.5 * 10^15) frac_cpu will get 3.6 CPU hours per day for the same amount of frac_cpu and the other user with 50 EOS staked will only get 1.68 CPU hours per day.
Observations
1. The problem of 'nothing at stake'
The resource regeneration period is still 24 hours in a new model. However a user can only purchase resources for a given timeframe (i.e. 30 days according to the proposal).
As a result, the user may find himself in a situation where he owns resources that are not important to him - so he will have all the incentive to invest them in any resource mining scheme, thus stressing the network, as EIDOS did.
Basically there are two problems with the new model:
-
The lower the value of rent_days, the higher the potential overhead associated with EOSIO native resource system (i.e. the physical ability of block producers to perform the required operations).
-
The higher the rent_days value, the more overpaid and unused resources users can theoretically obtain by renting resources and then deploy these resources to stress the system if they do not find a way to benefit from these overpaid resources in a potentially ecosystem-friendly way
Whenever a user receives resources that he is not interested in, he can deploy these resources to stress the network in any resource mining scheme, if this gives any shady hope of making a profit. This problem is known as the problem of nothing at stake.
Ideally a user must never be in a situation where he owns or even locks a certain portion of resources that he does not need. This can prevent the full use of the network in the same way as a user staking all his EOS for CPU and not using the allocated resources prevents the system from utilizing all the physically available resources at full potential without any downtime.
2. The system tends to never utilize 100% of the available resources
No matter the intention to ensure that resources are being used efficiently without downtimes and unused shares of physically available resources the proposed rentbw market does not incentivies users to constantly utilize 100% of physically available resources. It is possible to make the resource market achieve close to 100% utilization of resources with a proper tuning of the system parameters (mostly the exponent parameter of the price curve) however.
It should be noted that '100% of physically available resources' is not a deterministic value but the main goal of the resource distribution model is to make sure that the system offers its users the maximum degree of comfort when interacting with it which means that the system must tend to be in a state where 100% of its potential is deployed at every point of time for those users who are interacting with the system.
The price depends on utilization (adjusted_utilization in fact) and increases with increase of utilization. A scenario where the amount of available resources will be close to 0 and utilization would be close to 1.0 is barely possible which actually means that the network will NEVER be used at its full potential in theory.
3. High resource price volatility VS artificial price increases
NOTE: This is highly dependant on the system parameters and the actual configuration that is still a subject to discussion
In a rentbw resource market the price does not instantly drop right after a big loan expires. Instead it decays over time. In fact this means that the price may not reflect the amount of actually available resources and there are scenarios at which the price may keep unreasonably high for long time.
As it can be concluded judging by Ethereum ICOs in 2017 there could be some "events on the chain" that drive the utilization to its heights. These events could be any activities that require users to participate at a certain point of time - be it ICOs, an especially important round of some game or the launch of a new trading pair on an on-chain exchange. At that point of time users will tend to buy resources no matter the price because they need this resources right at that point of time. If a big loan expires at that point then the price will slowly drop but users will tend to keep buying thus keeping the price high which will turn into a disparity between the availability of resources at the rental market and the amount of physically available resources.
At the other hand if the price will drop too quickly then it will result in extreme price volatility and those lucky buyers who pay for resources right after the expiration of a huge loan would be in a significant advantage.
In theory it is possible to make exponent a function of utilization or adjusted_utilization instead of just sticking to a fixed value.
Conclusion
It should be noted that the proposed system is highly dependent on the configuration, most notably the exponent parameter and decay_secs parameter. The relationship between these two parameters determines how sharply the price rises with the growth of network utilization and with what delay the price falls if the network utilization decreases.
Good thing is that the proposed system is flexible and configurable on chain. Block Producers can adjust most of the parameters after the system is deployed. With properly adjusted parameters it is possible that it will be lending out a high percentage close to 100% almost all the time and there could be a fairly stable percentage of the resources acquired actually being used in practice on a daily basis. These are theoretical considerations and how the system will work in practice in a real market can only be learned by testing it in real conditions.
This resource model tries to ensure that rented resources are going to be used in some way by those who rented them and disallowing users to "freeze" a share of network resources and network capacity by staking resources and not utilizing them. This model intends to introduce market price driving forces to the system which can address the limitations of REX in theory.
Alternative solutions
-
Different family of price curves proposed by EOS Argentina
A couple of words about the Ultra resourcing model: In Ultra there are no CPU/ NET bandwidth. Instead there is an "UltraPower" property of an account which is not actually a bandwidth but a priority. The higher priority (or ultrapower) an account has the more likely its transactions are to execute at each block. Each transaction consumes ultrapower so transactions have the less priority the more an account uses the network. Ultra accounts may go below zero with their priority which means that an account can send transactions and perform actions on chain even if it has absolutely no ultrapower staked.
NOTE: there are no source codes available for review at the moment so this is just a theoretical idea described by Ultra developers
Analysis by Dexaran in collaboration with Polar.io / EOS Asia