译文/Translated：
EOSIO的第一个用例EOS公网是吸引各类用户的最常用的公共区块链，最近，它利用自身部分技术能力，实现交易处理速度稳定保持每秒800笔。由于转账的需求一直很高，所以资源交易所REX已经没有额外的EOS代币一共租赁。本文探讨REX没有EOS可供租赁的原因，并提出了解决方法，保证用户能以合理的市场价格获得需要的CPU资源。
质押EOS代币可以提供CPU带宽。CPU功能的资金成本已经被市场高估了，换言之，大多数人需要租赁EOS来获得可承受价格内所需的CPU，从而减少因为EOS价格波动带来的资金损失。
REX（资源交易所）设计的目的是在拥有EOS CPU功能的人和需要利用CPU时间却没有EOS的人之间自动形成市场。现在的问题就是如何为租赁EOS设置合理的价格，同时还要为EOS所有人保持功能价值：如果定价太高，没有人愿意租赁，整个网络使用率就低；如果定价太低，EOS供给量就远远不够，结果导致不管价格如何都没有CPU可用。
我们设计REX的时候利用的算法是这样的：如果可用来租赁的EOS供给趋近于0，那么价格就会趋于无穷大。最近，REX的问题是，现在不管开怎样的价格，都没有EOS可以租赁，因为提供EOS租赁的租赁方可能租出EOS之后又任性地召回代币。设计的时候，我们考虑的是投资人会有赚钱的需求，所以我们并没有预料到他们会从REX中召回这么大量的EOS。
好消息是REX的运行如常，按照代码要求，30天内租赁方可以召回放在REX中的EOS。而由于短时间内突然召回的EOS的量高于借出的量，对此，定价算法就把价格推向无穷大。
发生这种情况是因为我们设计REX的时候，初始构想是这样的：
- 大量账户的租金需求呈正态分布
- 对REX的租赁需求呈正态分布
- 租金提高，用户供给REX的需求会增加，可租赁的EOS数量就会上升
- 存入REX的代币量能抵消召回的数量，租赁供应总量相对稳定
而现实是：
- 存入REX的代币呈帕累托分布
- 召回量也呈现帕累托分布
- 从REX租赁的需求也呈帕累托分布
- 租赁期结束30天之前召回代币可以提前获得租金收入
我们初始构想和REX使用的现实之间存在的这一差异导致了租赁资源价格波动，也导致了市场上没有EOS可供出租。
CPU分配的全新设计
导致REX现在这个状态的原因是EOSIO公网资源分配策略在不断升级。我们想尽量提高构建解决方案时的灵活性，所以我们想的是如果我们不受先前设计的任何限制，那么我们就可以做些不一样的东西。如果我们能够创捷一个更好的、更理想的解决方案，那么我们就可以实现向后设计，实现以现在的EOS网络和REX为基础进行升级。
而唯一一个最大的问题就是“CPU”太贵了，其次则是你无法预测你在任何一个给定的时间会获得多少CPU带宽。这些问题的原因可能是先前因为高资金成本和低利用率，所以我们尝试降低CPU价格。我们的构想是EOSIO利用代币代表这么一个所有权模型：支付1%的EOS来利用1%的CPU，无限时间，无附加费用。这个资源模型就好比你买了一套有永久居住权的房子。
CPU所有权模式让EOS获得极大的利用率，但是同时也导致用户想利用网络就必须拥有大量的EOS。但因为市场上充斥着各种可转换的加密资产，其投机价值高于预想的实用价值，结果获得EOS CPU时间所需要的资金就高于大多数用户能承受的范围了。此外，价格波动风险意味着CPU真正的价格就和任何极端波动市场的资本损益捆绑在一起，变得无法预测。
为了减少CPU成本，EOSIO引入了“部分备用CPU”这个概念，向活跃用户分配未使用的CPU循环。这样，网络利用率低的时候，CPU的感知成本最多就可以下降1000倍；但是，如果使用率飙升，但用户因为已经消耗了超过最低保证CPU时，其账户会被锁定，因此，这种情况下的结果也时不可预见的。
上个月，我们把所有账户列入灰名单，解除了免费CPU 1000倍的提升，从而鼓励用户使用REX，因为相比购买EOS然后自己质押，这么做他们的风险和成本都小得多。同时，一些EOS用户从REX中租出大量得EOS，开始名正言顺地利用自己的CPU预算。哪怕我们去掉了1000倍的免费CPU福利，每个EOS对应的CPU时间的稳定性还是依靠质押在CPU中的全部EOS的比例。
假设你是唯一一个向CPU质押EOS的用户，你就会获得100%的CPU。但现在假设另外一个用户质押了你的100倍，那么你现在CPU预算只剩下原来的1%。这就是当某人从REX中租赁了大量的EOS然后用来租用CUP产生的后果。
我们的底线：除了1000倍的福利，我们还会给尚未质押，但可随时质押的EOS提供额外3-5倍的福利。这些因素都导致了CPU分配对所有人都不可预测，不管是对出租方，还是对于租借方。
理想算法
在理想算法中，CPU就不会有投机价值了，你保留的CPU时间是固定且可预测的。此外，你无需利用投入太多（EOS代币形式的）资金、继而承担资本损益，你就可以使用CPU。最后，我们会保证利用某个价格你一定能获得CPU，因此，长期来看，CPU价格会保持相对稳定。
为了实现该目标，所有的CPU时间必须100%从系统合约租赁出去，而对应的EOS价格应该是随着租赁的CPU比例增长而指数上升。租赁这些CPU时间的EOS将被分配到质押的EOS代币中（如REX库中）。这个模型抵消了质押收入和出租CPU的费用，从而把CPU分配保留给质押了EOS的持有人。假设你质押的EOS每个月产生了1EOS的增长利润，你就可以把这个EOS花在租赁市场，获得一些CPU。CPU的数量会根据实时价格动态变化。显然，根据你质押代币的比例，一些CPU租赁费用就会直接返回给你。
当100%的CPU都通过租赁分配出去以后，就不会再有任何质押获得CPU的代币动态供应，人们也不用担心租赁方从REX中召回EOS冲击CPU租赁市场和价格算法。
此外，CPU时间会变成无法转换的，因为所有的CPU时间都是通过从系统合约租赁分配，而不是通过质押EOS获得。这样就解决了投机影响CPU定价的因素，保证每个人都能在同样的资源模型下运行。
我们可以用一个简单的公式算出租赁一个固定比例的CPU时间30天所需要的花费。
下图显示了本次租赁收取 “1亿EOS*使用百分比”。在公式中，当网络租赁了大约10%效用的时候，租金收入会超过EOS增长。很可能，未来EOSIO治理的模式会选择支付超级节点一定比例的租金收入，这也符合他们让网络功能价值最大化的利益所在。原则上，社区可以利用任何常数指数来决定价格曲线。指数越高，能够被便宜利用的网络比例越大，但是当功能接近100%的时候，它也会更快地增加价格。理想指数能够平衡供给和需求，实现总租金收入扣除区块链运营成本的差值最大化。
因为租赁CPU的人呈帕累托分布，所以我们预计到时候会有大量用户同时租借和/或续租。这就会导致租金在上升之后突然下跌。如果没有“订单簿”捕捉下调的租金，这就会导致大租户获得过高的价格优势，这是我们不愿意看到的。因此，我们建议，租金下调的速度应该低于上升的速度。我们可以创建一个定价函数，设P(Total Usage)为新CPU租赁价格，该价格最大值为MAX( P(CurrentUsage), P(DailyAvgTotalUsage) )。如果价格过高，CurrentTotalUsage下降，随着时间的发展DailyAvgTotalUsage也会下降。如果CurrentTotalUsage突然上升，价格也会急剧攀爬，防止CPU供给被消耗完。
我们会考虑这个算法的变化，比如当CurrentTotalUsage大于DailyAvgTotalUsage的时候，把DailyAvgTotalUsage重置为CurrentTotalUsage。这样就能让平均算法对需求增长反应速度加快，同时如果没有新的需求，在24小时候还能逐步降低价格。
用户想购买1%的CPU供给30天，他需要支付MAX(P(CurrentTotalUsage+1%),P(DailyAvgTotalUsage+1%))) — MAX(P(CurrentTotalUsage),P(DailyAvgTotalUsage)))，或者简单来说，他们需要支付按照当前利用率算的租赁收入总和与新利用率水平下的预期租金收入的差值。
从REX中转移出来
新的模型之所以可行是因为，和REX不同，这个模型下“CPU”不能从租赁市场撤回。REX算法必须平衡出租方和租借方的需求。这个流程中，出租方要等待30天租赁才算完成，或者，潜在的租借方就会因为出租方撤回EOS而不能获得任何EOS。在现行REX模式下，没有任何简单的解决方案，能给出租方和租借方提供理想的方案。
解决该问题最直接的方法是慢慢把现在的CPU分配百分比模型转移到新的通过逐渐“增加CPU供给”的新模型。我们可以在系统合约中加入一个新动作，允许CPU分配被租用，接着分配“虚拟cpu-质押”，从而把全部质押的CPU（不管是拥有的还是租用的）稀释到现有的CPU中。这样不单单增加了EOS的供给，而且我们只是调整了分配到每个账户的CPU比例的参数。现在，系统合约是以1：1的比例把EOS质押到CPU中，但是基础EOSIO协议只知道相对CPU权重（分配到你账户的权重除以分配到所有账户的所有权重总和）。
如果新的资源市场创造的CPU供给慢慢增长到质押到CPU的EOS供给的100倍以上的时候，那么新的租赁市场就有效地控制99%的EOS CPU时间。最终，把EOS质押到CPU和NET的做法就会被弃用，因为每个人都转移到了CPU/NET租赁市场。
新的CPU租赁市场产生的收益就会转移到质押在REX的用户身上，就想域名排名和RAM市场费用一样。这个解决方案可以让用户马上可以通过合适的价格获得CPU。慢慢地，REX市场的使用率会下降，新的CPU市场会占据主导。
如果社区采用我的方案，拥有EOS并质押的用户就要转到新市场租借CPU，因为他们现在质押的EOS在整个CPU市场上的比重减少了。我建议用过一年的时间把CPU转移到新的市场中，让用户能有机会转移自己的CPU资源策略。
最终，质押EOS获得CPU和从REX中租借EOS都会因为新推出的CPU市场而停用。
适用于CPU的所有内容都适用于NET市场，它和CPU市场的模式相同。
对于终端用户的可用性
很多应用和钱包已经采用了“先付费先授权”的CPU模式，也就减少了终端用户考虑租赁或质押获得CPU带宽的问题。这个新的提议会模仿相似的平台：应用提供方已经从云提供商那里租赁了服务，他们就会继续通过一系列金融策略承担成本，如订阅、广告、产品销售等。
结论
我提议的CPU租赁市场会稳定CPU价格、减少租赁CPU的成本、增加访问CPU的可预见性。从CPU和NET租赁上获得的收益还是可以分配给质押在REX上的用户。但是最大的变化是通过质押EOS获得一定比例的CPU从而永远“拥有CPU”的能力会慢慢减少。同时，因为服务提供方可以以每次交易为基础向用户覆盖其CPU成本，综上所述，我们可以说，这个提议会让基于EOSIO的网络成为市场上使用最简单、成本最低的解决方案。
原文/Original：
The EOS public network, the first implementation of EOSIO, is the most used public blockchain by a wide margin and has recently been processing a sustained 800 transfers per second utilizing a fraction of its technical capacity. The demand for transfers has been so high that the resource exchange, REX, has run out of EOS tokens to lease. This post explores the reasons why REX ran out of EOS to lend and proposes a solution that ensures that CPU resources are always available at a reasonable market price.
EOS tokens provide the utility of CPU bandwidth when they are staked. The capital cost of CPU utility has been priced highly by the market, which means that most people need to rent EOS to get the CPU they need at an affordable price with minimal exposure to capital loss as a result of the volatility in the price of EOS.
The REX (Resource Exchange) is designed to automate a market between those who own the EOS CPU utility and those who wish to use the CPU time without owning EOS. The challenge has become establishing a price for renting EOS, while maintaining the value of utility for EOS owners: if priced too high, then no one will be willing to rent and the network will therefore be under-utilized, and if priced too low, then the available supply of EOS will be over extended, leaving no CPU available at any price.
We designed the REX to use an algorithm that raises the price toward infinity as the remaining supply of EOS available to rent approaches zero. Recently the REX got into a situation where there was no EOS available to rent at any price, because it is possible for those providing EOS for others to rent to recall them at will. We did not anticipate that such a large amount of EOS would be withdrawn from the REX given the expected demand to earn.
The good news is that REX is working as designed and that it will deliver on the promises the code made to allow EOS put into REX to be returned to the lender within 30 days. The pricing algorithm response to a sudden withdraw request of more EOS than there was to lend out was to push the price to infinity.
This happened because of initial assumptions made during the design of REX:
- There would be a normal distribution of rental demand across a large number of accounts
- There would be a normal distribution of lending demand to the REX
- Rising rental rates would drive new demand to supply REX with additional EOS to rent
- Withdraws from REX would be offset by deposits with the total rental supply being relatively stable
Reality:
- Deposits into REX are governed by Pareto distribution
- Withdraws from REX are distributed on Pareto
- Demand for borrowing from REX is governed by Pareto distribution
- Rental income that is earned up front can be claimed by withdrawing before the 30 day rental period has expired
The result of the mismatch between initial assumptions and the reality of REX usage has been a volatile price for renting resources and the unavailability of EOS for rent.
Clean Slate Design for CPU Allocation
The current state of the REX is the result of a gradual evolution in resource allocation strategies for public EOSIO networks. In order to maximize our flexibility in imagining solutions, we like to consider what could be done differently if we had no restrictions from past designs. If a better ideal solution can be conceived, then we can work backwards to a design that can be evolved from the current state of the EOS network and its REX.
The single biggest complaint is that “CPU” is too expensive, followed closely by the complaint that it is too unpredictable in terms of how much CPU bandwidth you get at any given time. The source of these complaints can be tied to prior attempts at making CPU cheaper given the high capital cost and the low utilization. EOSIO was conceived to use a token to represent an ownership model where 1% of the EOS allowed you to consume 1% of the CPU, forever, free of charge. This resource model is similar to buying a house in which you can live forever.
The CPU ownership model gave EOS great utility, but also resulted in users having to own a large amount of EOS in order to use the network. Because the market has imbued all transferable crypto assets with speculative value beyond the intended utility value, the capital required to gain the utility of the EOS CPU time is more than most users can commit. Furthermore, the risk associated with volatility means that the true cost of CPU is unpredictably tied to capital gains or losses in an extremely volatile market.
To reduce the cost of CPU, EOSIO introduced “fractional reserve CPU”, which allocated unused CPU cycles to active users. This lowered the perceived cost of CPU by up to 1000x when the network was under utilized; however, it simultaneously gave unpredictable results when usage surged and people were locked out of their accounts because they had already consumed more than their minimum guaranteed CPU.
Last month we introduced the option to greylist all accounts and remove the 1000x boost in free CPU and subsequently encouraging people to use the REX; where they could rent EOS at a much lower risk and cost than buying EOS to stake themselves. At the same time some EOS users leased most of the EOS from the REX and started utilizing their rightful CPU budget. Even with the elimination of the 1000x free CPU bonus, the predictability of CPU time per EOS was dependent upon the percentage of total EOS staked to CPU.
Imagine that you are the only user staking EOS to CPU, you would be allocated 100% of the CPU. Now imagine that another user stakes 100x the amount of EOS you staked to the CPU, bringing your CPU budget down to 1% of what it was originally. This is what happens when someone rents a large quantity of EOS from the REX and stakes it for CPU.
Bottom line: in addition to the 1000x bonus, there was an additional 3–5x bonus based upon unstaked EOS that could be staked at any time. These factors have made CPU allocation unpredictable for people who have staked EOS, whether they rented it or owned it.
The Ideal Algorithm
In the ideal algorithm, CPU would have no speculative value and the amount of CPU time you had reserved would be fixed and predictable. Furthermore, you could use CPU without tying up large amounts of capital (in the form of EOS tokens) and exposing it to capital gains or losses. Finally, there would always be CPU available at some price and therefore, the price of CPU would be relatively stable across time.
To achieve this 100% of all CPU time should be leased from the system contract at an EOS price that grows exponentially as the percentage of CPU leased increases. The EOS paid to lease the CPU time would be distributed to staked EOS tokens (e.g. the REX pool). This model preserves the allocation of CPU to staked EOS holders via offsetting income from staking and expenses from leasing CPU. Assume your staked EOS generates 1 EOS per month in growth, you could spend that 1 EOS in the rental markets and get some amount of CPU. The amount of CPU will be dynamic based upon the current prices. Obviously, some of the CPU rental costs would be directed back to you based upon your percentage of staked tokens.
By having 100% of all CPU allocated by leasing, there is no longer a dynamic supply of tokens staked to CPU, nor is there any need to worry about people withdrawing EOS from REX causing shocks to the CPU rental market and its pricing algorithm.
Furthermore, CPU time becomes non-transferrable because all CPU time is allocated via leasing from the system contract rather than by staking EOS. This eliminates the speculative component to CPU pricing and ensures everyone is operating under the same resource model.
A simple equation could be used to determine the amount paid to lease a fixed percentage of the total CPU time for 30 days.
The chart below shows charging 100M EOS * PercentUsage2 for the rent. With this equation, the rental income would exceed EOS inflation once the network leased about 10% capacity. It is possible that future versions of EOSIO governance may choose to pay block producers a percentage of the rental income, which would align their interests in maximizing the utility value of the network. In principle, the community could use any constant exponent to determine the price curve. Higher exponents will allow a larger percentage of the network to be utilized cheaply, but will increase prices faster as utilization approaches 100%. The ideal exponent would balance supply and demand to maximize the difference between total rental income minus blockchain operating costs.
Because those who would rent CPU are distributed in a Pareto distribution, we would expect there to be a number of large renters who rent and/or renew at the same time. This could result in sudden drops in rental rates followed by increases. Absent an “order book” to catch falling rental rates it could create an undesirable pricing advantage to larger renters. Therefore, we propose that rental prices fall slower than they rise. Given a pricing function, P(TotalUsage), the price that a new CPU rental would be issued at would be MAX( P(CurrentUsage), P(DailyAvgTotalUsage) ). If prices get too high, then the CurrentTotalUsage will drop and over time so will DailyAvgTotalUsage. If there is a sudden increase in CurrentTotalUsage then prices will climb rapidly to prevent supply of CPU from being consumed.
We could consider variations on this algorithm, such as resetting DailyAvgTotalUsage to CurrentTotalUsage anytime CurrentTotalUsage is greater than DailyAvgTotalUsage. This would cause the averaging algorithm to respond quickly to increases in demand while still gradually lowering the price over 24 hours if there is no new demand.
A user looking to acquire 1% of the CPU supply for 30 days would pay a price equal to: MAX(P(CurrentTotalUsage+1%),P(DailyAvgTotalUsage+1%))) — MAX(P(CurrentTotalUsage),P(DailyAvgTotalUsage)))or more simply put, they would need to pay the delta between the total amount of rental revenue collected at the current utilization and the total amount of rental revenue expected to be collected at the new utilization level.
Migrating from REX
The new design is made possible because, unlike in REX, it isn’t possible for the “CPU” to be withdrawn from the rental market. The REX algorithm must balance the needs of both borrowers and lenders. In the process lenders end up waiting 30 days for leases to expire or potential renters end up without any EOS for rent because lenders have asked for their EOS back. There is no simple solution that creates ideal simplicity for both renters and lenders under the current REX model.
The most direct way to resolve this is to gradually shift the percentage of CPU allocated under the current model to the new model via “inflating the CPU supply” over time. This can be achieved by implementing a new action in the system contract that allows CPU allocation to be rented and then allocates “virtual cpu-stake” which dilutes the total CPU staked (whether owned or rented) to existing CPU. This does not increase the EOS supply, instead it merely adjusts the parameters that determine the ratio of CPU allocated to each account. Currently, the system contract connects this 1:1 to EOS staked to CPU, but the underlying EOSIO protocol only knows about relative CPU weight (the weight assigned to your account divided by the sum of all weights assigned to all accounts).
If the supply of “CPU” created by the new resource market gradually grows to 100x the supply of EOS staked to CPU, then the new rental market would effectively control 99% of EOS CPU time. Eventually staking EOS to CPU and NET could be deprecated and removed as everyone moves to the CPU/NET rental markets.
The proceeds from the new CPU rental market could then be directed to people staked in REX just like name auctions and RAM market fees. This solution could make CPU available immediately and at reasonable prices. Over time utilization of the REX market will decrease and the new CPU market will take over.
If adopted by the community, those who own EOS and stake for themselves would have to shift to renting CPU from the new market as their existing staked EOS would have a decreasing share of the total CPU market. I would propose the CPU be phased into the new market over a one year time period to give people a chance to migrate their CPU resource strategy.
Ultimately, the ability to stake EOS for CPU and rent EOS from REX could be deprecated in favor of the new proposed CPU market.
Everything that applies to CPU can also apply to the NET market which has the same dynamics as the CPU market.
Usability for End Users
Many applications and wallets have already adopted the first-authorizer-pays model for CPU, eliminating the headache for the end user having to consider renting or staking for CPU bandwidth. This new proposal would mirror similar platforms where the application providers, that are renting services from cloud providers, cover their costs via a number of monetization strategies such as subscriptions, advertising, or product sales.
Conclusion
The proposed CPU rental market will stabilize CPU prices, reduce rental CPU costs, and increase predictability of CPU access. The proceeds from CPU and NET rentals can still be distributed to those staked in REX. However, the biggest change would be the gradual loss of the ability “own CPU” forever via staking EOS for a share of CPU. Combined with the ability of service providers to cover CPU costs on a per-transaction basis for their users, this will make EOSIO based networks the easiest to use and most cost effective solution on the market.
原文链接/Original URL:
