EOS founder BM latest article: Refactoring EOSIO resource allocation

Source: MEET.ONE

Editor's note: The original title was "BM: Refactoring EOSIO Resource Allocation"

Today, BM published an article on "Refactoring EOSIO Resource Allocation" on Medium, and proposed a new solution to the CPU problem. The editor briefly summarizes the main points as follows:

Disadvantages of the original model:

• QKL123 market analysis | The trend starts to go bad, is it a good time to make a decision? !! (1127)
• Suddenly! 342,000 ETH transferred to unknown address, South Korean exchange Upbit suspected of being stolen
• Popular science | Ethereum Istanbul upgrade content interpretation

1. The current problem of REX is due to the gap between the design concept and the actual situation. For example, the redemption or purchase of REX is a 28-distribution instead of a normal distribution;
2. In the original mode, the amount of CPU time that can be allocated at a specific time in the future is uncertain and is affected by multiple factors;

Therefore, the resource allocation of the entire EOSIO needs to be restructured.

New model:

1. All those who want to use the CPU need to go to the new CPU lease market and cancel the mortgage to obtain the CPU allocation mechanism of EOS (but not immediately, but slowly transition)
2. CPU rental costs become predictable, and everyone can calculate the rent to be paid at different rental rates based on formulas
3. The income from CPU rental can even offset the EOS network inflation rate and replace the block reward of payment nodes;
4. The revenue of the new CPU rental market may still be transferred to the REX pool, but the function of REX will tend to attract user mortgages in the future, but it will not dominate the price of the CPU rental market;
5. Although it is costly for everyone to rent a CPU in the new market, since the rental income is transferred to the REX pool, it will be disguised and returned to the pockets of EOS holders. It costs more and costs less.

Editor's comment:

BM's article today is very long, and many people may think EOS is complicated at first, but in fact, it should be good for ordinary users:

First of all, because more and more people are trading with EOS, they are blocked. What should I do? Start to adopt more reasonable market control measures, that is, you only need to look at each transfer, you really need to make a unified "The CPU leasing market" can only be operated by buying a CPU, that is, a single transfer must be paid.

However, if you hold EOS and mortgage it to REX's pool, you can get the entire network's commission based on the proportion of EOS that is mortgaged. This is different from Ethereum, where everyone is a miner, and EOS is a token holder that also makes a profit. And the more prosperous the EOS network is, the more transactions there are, the more ordinary holders (they don't need high-frequency transfer transactions) should blossom with laughter, and the rental income will increase exponentially. Even the node income can be covered. If the node income is more and more, then the node will focus more on contributing.

And now the EOS wallet function is upgraded so fast, the underlying wallet function will be changed quickly to keep up, there is not much learning threshold.

Then the following is the original translation. In order to help you read, I appropriately added the title and vernacular explanation.

The original text is as follows:

EOS is the first widely adopted public chain. Its recent data is processing 800 transfer transactions per second. People's demand for transactions is so high that the CPU that can be leased in REX is exhausted. The purpose of this article is to explore why the REX cannot lend CPU, and propose a new solution to ensure that the CPU is allocated at a reasonable market price.

Original CPU mechanism 1-Mortgage EOS to obtain the corresponding CPU

After the user pledges EOS, it can be allocated to the corresponding proportion of CPU. However, the current CPU usage price has been overestimated by the market, which means that most people need to use EOS to lease the required CPU. If you collateralize EOS to obtain CPU, you need a lot of EOS, and you need to bear the risks caused by EOS price fluctuations.

Original CPU Mechanism 2-REX Leasing Market

The purpose of REX is to design a market that automatically allocates CPU usage rights so that those who don't have much EOS but want to use the CPU can use the entire network. This brings new challenges-not only to ensure a reasonable CPU lease price, but also to safeguard the rights and interests of EOS holders. If the price is too high, then no one is willing to lease, so the network resource utilization is not high, and if the pricing is too low, the resources available on EOS will be over-consumed, and eventually the CPU will be unavailable.

The algorithm we use when designing REX is to increase the lease price to infinity when the remaining supply of EOS available for rent approaches zero. However, REX has recently fallen into a situation where there is no surplus grain to rent regardless of the price. This is because those who provide rentable EOS can redeem EOS at any time. We have not considered that in reality REX will have such a huge redemption.

But don't worry, REX is currently running normally. Although everyone is currently waiting in line for redemption, when the CPU rented out in REX (after 30 days expires), users can redeem their EOS (the principal will not be at risk of loss).

Why is REX current?

The reason why this happens in REX is because the original design algorithm was considered like this:

1. User demand for EOS rents is normally distributed;
2. REX borrowing demand is normally distributed;
3. Rising rents will spur more people to provide REX with new EOS, that is, to supply more CPUs;
4. REX redemption expenses can be offset by the rental income generated, maintaining a stable supply overall.

but in fact:

1. The amount deposited in REX is subject to the 28 rule;
2. The redemption of REX funds is also affected by the 28 rule;
3. The demand for renting CPUs from REX is also two or eight.
4. Lessors can withdraw the rental income they have earned before the 30-day lease period expires;

Because of the difference between theory and reality, it causes the current problems of REX.

Newly designed CPU allocation

The current status of REX is the result of the evolution of the EOS public chain network resource allocation strategy. In order to maximize the flexibility of the design solution, we hope to consider what different measures can be taken if it is not restricted by the past design. If a better solution can be conceived, we can further design it, which is based on the existing REX to derive a better solution.

At present we see that the biggest complaint from the community is that the CPU is too expensive, and the second is that the bandwidth time that can be allocated at a certain time is unpredictable (increasing too many unknown variables). Given high holding costs and low utilization rates, the root cause of these complaints may be related to previous attempts to reduce CPU prices. EOSIO wants to use tokens to achieve resource pricing. For example, if you have 1% EOS, you can permanently own 1% of the CPU resource usage rights, similar to buying a permanent residence.

It is undeniable that the existing CPU ownership model brings great practicality to EOS, but it also inevitably causes users to have a lot of EOS in order to use the network. In today's market environment, all tradable crypto assets are given a "speculative value" that exceeds the "expected use value", which means that for a developer, if he just wants to use the CPU, but to use it The CPU buys a lot of EOS, and he bears the huge risk of sharp price fluctuations in EOS. And when EOS prices fluctuate sharply, the true cost of the CPU will fluctuate unpredictably.

Therefore, under the original model, in order to reduce the CPU cost, we also introduced the concept of "partial spare CPU". (The editor's remarks actually mean that the CPU allocation mechanism of Fenggudian is similar. When the network is idle, the available CPU of the user is enlarged by 1000 times, and when it is busy, the normal allocation is resumed). But this also inevitably adds unpredictability to CPU allocation.

Last month, we introduced the option to greylist any account, and cancelled the 1000x zoom-in allocation mechanism to encourage users to use REX. Because it is cheaper to go directly to REX to rent CPUs than to mortgage EOS to own CPU . But even so, the predictability of the CPU time for each EOS still depends on the percentage of EOS on the CPU.

What does it mean? You can imagine that you are the only user who pledged EOS to obtain CPU, then you have 100% CPU allocation. Assuming that the amount of EOS collateraled by another user is 100 times yours, the CPU allocated by you will be immediately available. It became 1%. This is the contradiction between the current CPU allocation in REX and the CPU original mortgage allocation mechanism.

In addition, in addition to the 1000x magnification mechanism, unsecured EOS can also be mortgaged into the pool at any time. All of these variables lead to uncertainty and unpredictability of CPU allocation.

Ideal algorithm

Under ideal algorithms, the CPU has no speculative value, and the CPU time you reserve will be fixed and predictable. In addition, you can still lease CPU without spending a lot of EOS acquisition, reducing the risk of secondary market fluctuations.

In the end, there will always be CPUs available in the market, but the prices are different, so the rental price of CPUs will stabilize over a period of time.

So, what should we do to achieve this goal?

All CPU resources should be leased from the system contract. The rent is priced at EOS, and this price increases exponentially as the percentage of CPU leased out increases.

The revenue from the CPU lease will be distributed to the EOS mortgage pool (such as REX). This model retains the idea of ​​CPU allocation to mortgage EOS users by offsetting the benefits of mortgage EOS and CPU rental expenses .

For example, your pledged EOS can earn 1 EOS per month, and you can use this 1 EOS to lease the market to get the corresponding CPU. The number of CPUs you can get is based on market prices. Obviously, in this case, part of the CPU rental income will be returned to you based on the percentage of EOS you pledged (that is, you will earn a profit from pledged EOS).

By allocating 100% CPU to the leasing market, you don't need to mortgage your EOS to obtain CPU, and you don't need to worry about someone's redemption from REX causing the CPU pricing mechanism to fluctuate.

In addition, the CPU becomes non-transferable because the CPU time you get is leased out of the system contract and is not allocated through mortgage EOS. This eliminates the speculative cost of CPU pricing and ensures that everyone runs under the same resource model.

In this way, what percentage of the CPU time you want to lease can be quickly calculated according to a certain formula (every predictable).

The following figure shows the CPU price under the total pool of 100 million EOS under different rental ratios. If this algorithm is used, that is, when 10% of the CPU is leased out, the rental income will start to exceed the inflation rate of EOS. In other words, the future EOSIO governance model may choose to pay a certain percentage of the rental income to the nodes, which will make them consistent in their interests and try their best to increase the value of the network utility.

In theory, the community can use arbitrary parameters to determine the index shape of the CPU lease price curve. A higher index will allow low-cost utilization of a large number of network resources, but as the utilization rate approaches 100%, the price will increase significantly. The Ideal Index will balance supply and demand to maximize the difference between total rent and blockchain operating costs.

Because the people who rent CPUs are distributed in two or eight, we expect that there will be a large number of large tenants who rent and / or renew at the same time. This could lead to a sudden drop in rents and then a sudden rise. Without an “order book” to capture the downward trend in rents, this could give undesired pricing advantages to large tenants.

Therefore, we recommend that rents fall more slowly than rents rise. Given the pricing function P (TotalUsage), the lease price at a new CPU lease rate is MAX (P (CurrentUsage), P (DailyAvgTotalUsage)). That is, the maximum value between the pricing under the current usage (CurrentUsage) and the pricing for the daily average usage (DailyAvgTotalUsage) is taken respectively.

If the rental price is too high, the current usage will decrease, and the average usage will decrease over time. If the current usage suddenly increases, the price will rise rapidly to prevent excessive consumption.

We can also consider variants of this algorithm, such as resetting DailyAvgTotalUsage to CurrentTotalUsage when CurrentTotalUsage is greater than DailyAvgTotalUsage. If there is no new demand, this will cause the average algorithm to respond quickly to the increase in demand, while still gradually reducing the price within 24 hours.

If you want to get 1% of CPU resources in 30 days, the price you pay is equal to: MAX (P (CurrentTotalUsage + 1%), P (DailyAvgTotalUsage + 1%))) — MAX (P (P (P (CurrentTotalUsage)) , P (DailyAvgTotalUsage))

Or more simply, they will need to pay the expected EOS = total rental income collected at the new usage level-total rental income received at the current usage rate. For example, the current network rental rate is 20%, and you want to rent 1% of the CPU, the rate is 21% of the total rental income -20% of the total rental income.

Migration from REX

The reason for this design is because the entire pricing model is different from REX. The lessor cannot redeem the "CPU" from the REX market. REX must balance the needs of the lessor and the lessor. In REX, the tenant has to wait for 30 After the lease expires, or because of the huge redemption, people who want to rent cannot rent EOS. Therefore, REX did not achieve the imagination and brought convenience to tenants and lenders.

The most direct solution is to gradually increase the CPU supply over time and smoothly transition the CPU algorithm from the old mode to the new mode. This can be achieved by adding a new operation to the system contract, which allows leased CPU allocation and subsequent allocation of "virtual mortgaged CPU" to dilute the total CPU (whether owned or leased) into the existing CPU.

This does not increase the supply of EOS, but merely adjusts the parameters that determine the CPU ratio allocated to each account. At present, the system contract only knows the relative CPU weight (the weight assigned to your account ÷ the sum of the weight assigned to all accounts), and the CPU ratio is allocated 1: 1 according to your mortgage EOS ratio.

If the supply of the "CPU" created by the new resource market gradually increases to 100 times the CPU acquired by the mortgage EOS, the new lease market will effectively control 99% of the CPU resources. As everyone adopts this new market, then the original mode of staking EOS to acquire CPU / NET can be abandoned or deleted.

Immediately afterwards, the revenue from the new CPU rental market can be transferred to REX-related people, just like the short account auction and RAM market. This solution will make the CPU price reasonable, and over time, the utilization of CPU resources in REX will continue to decline, replaced by the new CPU resource market.

If this new solution is adopted by the community, people with EOS will have to turn around and rent CPUs in this new market, because they can rent CPUs from the new market to a more reasonable price. I suggest gradually introducing CPUs to the new market and changing the old mechanism within one year.

This method is not only applicable to the CPU market, but also applicable to the allocation of NET resources.

End-user availability

Many applications and wallets have adopted the "the first-authorizer-pays" CPU mode, which solves the problem of users having to rent a CPU. My proposal for a new resource allocation method reflects a similar approach, where application developers can rent services from cloud service providers and cover their costs through multiple strategies such as subscriptions, advertising, and product sales.

in conclusion

The proposed new CPU leasing market will help stabilize CPU prices, reduce CPU leasing costs, and increase the certainty of using CPU payment costs. The rental income obtained by CPU and NET resources will still be distributed to REX holders, but the biggest change is that EOS token is a tool that shares the entire EOSIO network CPU and other resources, and users no longer mortgage EOS to obtain their own CPU. Combined with the ability of service providers to pay CPU costs for users on a per transaction basis, this will make EOSIO's network the easiest to use and most efficient solution on the market.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!