-
Notifications
You must be signed in to change notification settings - Fork 495
Conversation
…lect the change in rentbw_config_resource
rentbw changes
…dvantage to very small rentals under particular situations (but still under the condition of utilization >= adjusted_utilization) Also add calculated fee to the error message when it exceeds max_payment.
rentbw additional changes
… are resonable dependent heavily on the attributes of the core token
…en under the scenario of utilization <= adjusted_utilization
…hould preserve the existing value (or use default when appropriate)
…pricing model to now also include a min_price Note: Assuming min_price is 0, this new price model can be directly compared to the prior one. In fact, under that condition, max_price can be thought of as target_price * exponent.
rentbw even more changes
How about adding a threshold in I'm an advocate for using private sidechains to mitigate these sorts of risks and costs, but I do think the proposed rental model will provide some needed flexibilities when scaling Dapps :) |
Change Description
This PR creates a new optional NET and CPU rental market which displaces (over time)
the existing staking system and REX market. Under the old model, system token holders
own NET and CPU and may choose to use it themselves, delegate it to others, or make
it available for others to rent using the REX market. Under this new model, the chain
owns almost all NET and CPU resources and the only way to access these resources is
through the new
rentbw
action. It channels fees to the REX pool to enable token holdersto profit off the new market.
Renting resources
Users may use the
rentbw
action to rent resources:After the phase-in period,
net_frac
andcpu_frac
will approximately represent thefraction of total network resources. This should simplify resource planning since
the fraction will no longer depend on how much other accounts have staked or rented
from REX.
During the phase-in period,
net_frac
andcpu_frac
represent the fraction managedby the market at the time the action is called. Since the amount managed by the market
grows during phase-in, the percentage of total resources drops over the rental period.
Processing Expired Loans
The resources in loans that expire do not automatically get reclaimed by the system. The expired loans sit in a queue that must be processed. Anyone calling the
rentbw
action will help with processing this queue (limited to processing at most two expired loans at a time) so that normally the expired loans will be automatically processed in a timely manner. However, in some cases it may be necessary to manual process expired loans in the queue to make resources available to the system again and thus make rental prices cheaper. In such a scenario, any account may process up to an arbitrary number of expired loans by calling therentbwexec
action.Configuration
Operators of the blockchain can use the
configrentbw
to start the new resource system and tune its various parameters. It is possible to callconfigrentbw
to change certain parameters even after the new resource system has already started. Chain operators can configure the new resource system to take over the old system immediately or they can configure it to gradually phase out the old system over a long period of time.Definitions useful to help understand the above, including defaults:
Deployment Changes
A new account
eosio.reserv
must be created before starting the new resource system (i.e. before calling theconfigrentbw
action). Theeosio.reserv
account should not be used as the authorizer of any actions because increasing the CPU/NET usage of that account could interfere with the proper functioning of theconfigrentbw
andrentbw
actions.API Changes
New actions:
configrentbw
,rentbwexec
,rentbw
Documentation Additions
See the description above.