译文/Translated：
EOSIO为在代币持有者之间配置可用CPU和网络带宽提供了广泛的选项。EOSIO的基本原理在于如果你拥有1%的代币，便可以使用1%的可用带宽。据此原理，我们创建了资源交易合约，名为REX，允许代币持有者以市场价出租自身带宽。
随着EOSIO1.8的问世，现在合约拥有者能够通过共同签署交易，支付自身用户的CPU及网络带宽。应用程序现今能够从REX租借资源，然后通过共同签署交易的方式将用户使用的带宽涵盖其内。在此模式下，用户不在需要担忧带宽资源。这一模式与公司选择买硬件还是从云服务租借一个道理，同时能让公司补贴自身用户的带宽需求。
除上述两种在EOSIO之上获得带宽的方式外，已分配但未使用的带宽能够被自身代币的其他持有比例自由使用。这如同一位拥有最低保证带宽的网络服务供应商，但却在网络不拥堵的时候许你更高的速度。
有关免费资源分配的争论
EOSIO公共区块链的部分用户，例如EOS，开始依赖“限制带宽”，如同某些人租借便宜的AWS实例。而最终，一些人高价哄抬实例，不期想，他们的“便宜”服务也被拦腰斩断。当有人从REX租用代币，然后利用可用的“免费额外容量”使“竞价型实例”的成本超出许多帐户已提供的金额时，就会发生这种情况。一个帐户每天只能保证1ms，但是在网络负载较低的情况下，通常每天只能依靠1000ms。如果使用量增加并且其“平均每日使用量”超过1ms，则帐户将被冻结，直到他们租用或购买更多代币。
必须指出的是，“拥堵的模式”仅表示“免费剩余带宽”的终结。及时处于“拥堵的模式”中，拥有1%代币的人只要保持自身平均消耗低于1%便可继续不受阻碍地交易。
网络闲置时，为努力降低终端用户的费用，持有有限带宽的人可能事实上消耗更大量的带宽。然而，一旦网络交通提升，用户将仍旧无阻断地进行操作，只要他们仅消耗自身分配的带宽比例。
如今，典型的传输消耗约188us CPU，而使用EOS VM，该数目可能会大幅度下降。例如在EOS上，这意味着我们可以预期，每月在REX上花费1 EOS可使某人每月进行100,000次传输。例如，如果每个EOS为3美元，则每次传输的结果为0.00003美元，即使遇到网络流量较大的情况，这个价格也相对非常便宜。注意，如果网络维持较高的利用率，并且每个人都通过租借的方式满足自身所需而非依赖限制带宽，那么租借EOS的费用很可能增加。
部分用户保留带宽却不使用，便会出现所提供的“免费”带宽浪费性消费的情况。这种行为强制网络降低自身向所有用户提供的“免费”带宽量，并且对依靠持续闲置资源的用户造成干扰。
EOSIO公共区块链上的带宽分配
EOSIO可以提供两种意义上的“免费”交易。其一是交易自身持有的未消费的代币。这类“免费”交易通过代币通胀来支付。第二种是网络资源的盈余，这部分资源长久以来免费提供给公众，超过最低保障量。我们认为，第二种免费交易应该逐步取消。
就EOS而言，我们相信现在正是时候操作网络，似乎它的流量一直很高。这在REX之前无法实现，因为“免费”交易的资金成本太高，但有了REX以及EOSIO1.8，现在租借网络资源的价格足够便宜，并且在低流量时期提供免费带宽不再必要，而这也不会对最佳网络操作带来益处。
最近发生的事件表明，“有时免费”带宽的存在对不完全了解EOSIO设计细节的开发人员和用户造成了不切实际的期望。删除此功能将确保每个人都适应通过租用或抵押代币来保护网络资源、改善用户体验，并使每个用户都能得到自身期望的东西。
为REX带来的益处
消除“免费剩余带宽”将使网络价格更加可预测。 当前，免费带宽正在“削弱” REX市场，并且通过消除免费使用以及对此类资源的无限供应的不切实际的期望，人们将需要为使用的带宽付费，所有带宽将分配给应用程序和已获得保障的用户。对于那些向REX租用资源的人来说，最终的结果将是一个更加公平的结果，更多的价值将回流至代币持有者，最重要的是，网络状态将更加稳定和可预测。
作为临时方案的灰色名单
EOSIO当前支持块生产者通过限制可用带宽分配来限制免费带宽功能的帐户“灰名单”选项。此灰名单功能是在EOSIO的早期版本中添加的，目的是限制那些滥用系统而完全不阻止它们的用户。此项功能是一项主观功能，意味着它并非是一个硬分叉，并且区块制作者的采纳将按其比例对规则产生影响；Block.one建议区块制作者使用此功能。
结论
EOS网络是公共区块链的一个示例，该公共区块链继续根据EOSIO的设计而顺利运行，每个人都在公平地分享自己的可用网络资源份额。如今，REX和EOSIO 1.8的出现消除了在非拥堵模式下提供免费带宽的需求，从而保持极低的带宽成本。在EOSIO上运行的公共区块链的成熟（仅将网络资源分配给“下注的”参与者的公共区块链）将引入稳定性和可预测性，这与经过验证的网络和托管资源分配的最佳实践模型一致。
重要提示：此间所有材料都受此重要通知约束，请自行熟悉条款内容。通知涵盖与我们软件、发行物、商标、第三方资源及前瞻性声明相关的重要信息、限制和制约因素。通过访问我们的材料，您接收并同意此通知中的条款。
原文/Original：
EOSIO provides a wide range of options for allocating the available CPU and network bandwidth among token holders. The underlying principle of EOSIO is that if you own 1% of the tokens you may utilize 1% of the available bandwidth. Following this principle we created the resource exchange contract, known as REX, which allows token owners to rent their bandwidth to others at a market rate.
With the advent of EOSIO 1.8, it is now possible for a contract owner to pay for the CPU and network bandwidth of their users by co-signing the transaction. Applications are now able to rent resources from REX and then cover bandwidth for users by cosigning their transactions. Under this model users no longer have to worry about bandwidth resources. This model is similar to how companies can choose to either buy hardware or lease it from cloud services, while simultaneously enabling companies to subsidize the bandwidth requirements of their customers.
In addition to the above two ways to gain access to bandwidth on EOSIO networks, allocated, but unused, bandwidth can be freely used by others proportional to their tokens. This is like an internet service provider having a minimum guaranteed bandwidth, but allowing you higher speeds when the network is not congested.
The Debate over Allocation of Free Resources
Some users of EOSIO public blockchains, such as EOS, have come to count on “free bandwidth” like someone renting cheap AWS spot instances. Eventually, someone bids up the spot instances and their “cheap” service is cut off unexpectedly. This is what happens when someone rents tokens from the REX and then utilizes the available “free extra capacity” to bring the cost of “spot instances” beyond what many accounts have provisioned. An account may only have a guarantee of 1ms per day, but be relying upon 1000ms per day typically available while the network load is low. If usage increases and their “average daily use” is over 1ms then the account is frozen until they rent or buy more tokens.
It is critical to point out that “congested mode” simply means the end of “free surplus bandwidth”. Even while in “congested mode”, someone with 1% of the tokens can continue to transact uninterrupted so long as their average consumption remains below 1%.
In an effort to reduce costs for end users, while the network is idle, someone with a limited amount of bandwidth, could in fact consume a greater amount of bandwidth. However, once traffic on the network picks up, users will still operate without interruption as long they only consume the percentage of bandwidth they’re allocated for.
A typical transfer consumes about 188us of CPU today, and with EOS VM that number could fall substantially. On EOS for instance, this means that we can expect spending 1 EOS/month on REX enables someone to perform 100,000 transfers per month. For example, at $3 per EOS the result is $0.00003 per transfer which is relatively very inexpensive even when the network is experiencing high volumes of traffic. Note that the cost to rent EOS would likely increase if the network remains highly utilized and everyone rented what they needed instead of relying on free bandwidth.
Some users have taken it upon themselves to wastefully consume the “free” bandwidth offered when those who have reserved bandwidth don’t utilize it. This behavior forces the network to reduce the amount of “free” bandwidth it offers to all users, and disrupts those that have come to rely on a consistency of free resources.
Bandwidth Allocation on EOSIO Public Blockchains
EOSIO can offer “free” transactions in two senses. Firstly, when you own tokens you don’t consume tokens while transacting. This kind of “free” transacting is paid for through token inflation. The second is the surplus of network resources that have historically been offered to the public for free, beyond the minimum guarantee. It is this second kind of free transaction that can, and we believe should be phased out.
In EOS’s case, we believe it’s now time to operate the network as if it is experiencing high volumes all the time. This wasn’t possible before the REX because capital costs to transact “for free” would have been too high, but with the existence of the REX and EOSIO 1.8, it is now cheap enough to rent network resources, and giving free bandwidth during low volume times is no longer necessary or beneficial for optimal network operation.
Recent events have evidenced that the existence of “sometimes free” bandwidth creates unrealistic expectations in both developers and users who don’t fully understand the specifics of EOSIO design. Removing this feature will ensure everyone adapts to securing network resources through renting or staking tokens, and will result in an improved user experience where every user always gets what they expect.
Benefits to REX
Elimination of “free surplus bandwidth” will result in more predictable network pricing. Currently free bandwidth is “undercutting” the REX market, and by eliminating free usage, and the unrealistic expectation of an infinite supply of such, people will be required to pay for the bandwidth they are using, and all bandwidth will be allocated to applications and users that have secured it. The net result will be a more fair outcome for those renting resources to REX, more value driven back to token holders, and most importantly, a more stable and predictable network state.
Grey Listing as an Interim Solution
EOSIO currently supports an option for block producers to “grey list” accounts that abuse the free bandwidth feature by restricting them to their guaranteed bandwidth allocation. This greylist feature was added in the early versions of EOSIO to limit those who would abuse the system without blocking them entirely. This is a subjective feature, which means that it is not a hard fork and block producer adoption will effect the rule on a pro-rata basis; Block.one recommends that block producers leverage this feature.
In the meantime, and as an additional measure, Block.one is working on a new feature for EOSIO that will allow block producers to specify a grey list value which would apply the grey list to all accounts by adjusting the maximum “free bandwidth multiple” to a value between 1000x and 1x. The goal is to provide a way for block producers to gradually reduce the free bandwidth multiple, as the network moves to a more more modern resource allocation patterns. Block.one believes that a hard fork could be used as another effective measure to make the shade of grey listing a global consensus parameter, rather than a setting individually implemented by each block producer.
Conclusion
The EOS network is an example of a public blockchain that continues to successfully operate according to EOSIO’s design, and everyone is fairly getting their share of available network resources. The advent of REX and EOSIO 1.8 now eliminates the need to offer free bandwidth during uncongested mode in order to keep bandwidth costs extremely low. The maturation of public blockchains running on EOSIO to allocate network resources solely to “staked” participants will introduce stability and predictability in line with proven best-practice models for network and hosting resource allocation.
. . .
Important Note: All material is provided subject to this important notice and you must familiarize yourself with its terms. The notice contains important information, limitations and restrictions relating to our software, publications, trademarks, third-party resources and forward-looking statements. By accessing any of our material, you accept and agree to the terms of the notice.
原文链接/Original URL:
