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
Granulity of 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 rent_days
.
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 max_payment
constraint.
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 undelegatebw
.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 rent_days
: 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.