Configurability of rental period to a less than that of 30 days

• Yves from EOS Nation and a few others: They'd prefer if the period of rental can be adjusted to a shorter period time, even down to 12 hours at the lowest.
• Aarin from B1: It is already configurable: 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).
• Deck from B1 PBE also pointed that the rental period is changeable variable in the code and can be adjusted not just during initiallization but any time after.

Potential issues with reducing rent_days

• Granulity of rent_days is by days, not by hours or minutes.

  • Aarin: The configuration is 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.

  • Aaron from Greymass: If the cycle can be changed, there would be potential issue at the point where BPs to make that adjustment. i.e. The system had a 7 day rental for a month, but then that parameter was switched to 3.5 days. In this case the moving price that was established for 7 days now somehow needs to shift to account for the fact that it's now only 3.5 days. In practice you'd expect the price to be about 50% less than it was before the parameter was changed, but I don't know if the system would account for that. People renting immediately after the switch would essentially be paying 2x the price, if the price didn't adjust downwards somehow. Eventually it'd even out, as people refuse to pay that higher price (or maybe they accept it), and the market would discover itself again. But the swapping of that value might cause a bit of short term havoc.
  • Aarin: responded that the system with the exponential decay of adjusted utilization towards instantaneous utilization is pretty simple and does not depend on the history of prices. So the price curve can be radically adjusted at any time and not mess up the time evolution of the utilization state parameters. However, that would in general cause a discontinuous shock to the resulting price (i.e. of the fee to rent an infinitesimal amount of resources) and one that can be quite large if the operators weren’t careful in selecting the parameters in a way that kept in mind what the price was prior to the change. And people can protect themselves from such sudden shifts in price (whether that is due to a 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

  • Dexaran: 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.
  • Aarin: The resource regeneration period is still 24 hours and that is baked into the EOSIO protocol and can only be change by a consensus upgrade (which this proposed system contract upgrade introducing 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.

  • Thiago from EOS Rio: Reduce 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.