rent_days. All the parameters described in the “Configuration” section within the documentation here are adjustable not just during initialization but any time after (however, in practice it probably doesn’t make sense to touch the weight ratios or
target_timestamp after the transition completes).
rent_days is by days, not by hours or minutes.
rent_days meaning it only has a resolution of days (NOT hours). Furthermore, the period shouldn’t be too low anyway because the resource regeneration interval of the EOSIO protocol is hard-coded to 24 hours. Allowing a rental for less than 24 hours means that the borrower is able to spend those resources multiple times and get more than they are actually paying for. (Also, in general borrowers can get a little bit more use out of their resources than
rent_days because the expiration of their loan has to be explicitly done and that may lag the actual expiration time by a little bit. That is why it is good to ensure someone is calling
rentbwexec frequently enough to minimize such lags.)
Concerns on potential price asymmetry caused by in-flight change of
configrentbw that changed the price curve radically while their transaction was in-flight, or just due to the regular volatility of the market) by setting a tight bound on the
max_payment parameter of the
rentbw action based on the market data at the time they generated/signed the transaction. If it suddenly became more expensive, the transaction would be rejected because it wouldn’t satisfy the
Furthermore, if the change by
configrentbw is to change
rent_days, then in-flight user
rentbw transactions should be protected automatically (even without a tight bound on
max_payment ) because the days argument of their action would no longer match the
rent_days value. (Also, this new
rentbw model does not use Bancor.)
Proposal of setting
rental period =
resource regeneration period and need for over-provisioning of total CPU
rentbw is not). But the
rentbw system does allow the 30 day period of the rentals to be adjusted (at 1 day granularity) down to 1 day if desired.
That ratio of “double spend” goes down of course as
rent_days gets larger. For example with 30 days, they only get to spend approximately 1/30 more resources than they pay for assuming the expiration is processed very quickly after the expiration time. This “double spend” issue is the reason why a minimum of 1 day delay is needed on
I could be very wrong about this, but I think what this amounts to is a need for over-provisioning of total CPU (similar for NET) resources beyond the capacity that is determined by the
max_block_cpu_usage parameter. The over-provisioning ratio
r becomes a function of
r = 1 + 1/(rent_days) (assuming timely processing of expired loans). So with a
rent_days of 30, the ratio
r equals approximately 1.033, or a 3.3% overhead. But if rent_days drops to 1, then r is 2 which is a 100% overhead.
So what happens when that over-provisioning is not provided? I think this relates back to the question @michaelyeates asked in this channel. The system would be over-subscribed and I believe the fair queueing model that tries to provide low latencies for transactions (so they don't have to wait in a long queue) breaks down. Depending on how producer nodes are configured, that could already be the case. But it should in theory be possible to adjust the producer nodes and
max_block_cpu_usage in combination with the chosen
rent_days to account for the over-provisioning needs to ensure the system still operates smoothly.
The fraction overhead comes from the way this system interacts with the native EOSIO resource system. The way the native system works means that when an account uses all of its quota then waits 24 hours, it can then use all of its quota again (less black and white versions of that are also true, e.g. waiting 12 hours and using half of its quota all at once). That means twice its quota can be used in a period of 24 hours, even if that quota is pulled away from the user immediately after that 24 hour period. If that quota is then immediately re-lent to another user that can start the process of another 24 hour cycle (with potentially twice the quota use within that 24 hour cycle) all over again. So on average within a 24 hour window that quota is being utilized at a ratio of 2.
If you stretch out the period of this cycle from 24 hours to, for example, 72 hours, then the same process occurs except the user can use 4 times the quota over the 72 hour cycle. That means within a 24 hour window the average utilization of that quota is actually at a ratio of 4/3. So notice that if the regeneration period is
t_regen and the cycle period is
t_cycle = k * t_regen, then the ratio is
r = (k + 1)/k = 1 + 1/k. Certainly more thought (and of course experimentation) is needed along this front.
rent_days to reduce number of rosource replenish cycle in the given period of rentals, to make it harder for miner to optimize their resource usage when compared to other users.