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.
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.
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.
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.
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.
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.
Originally published at https://eos.io.
Maturing EOSIO Resource Allocation for Public Blockchain Usage was originally published in eosio on Medium, where people are continuing the conversation by highlighting and responding to this story.
Write a post
Are you sure you want to delete this post?
Are you sure you want to delete this comment?
Purchase has been completed.
닉네임을 설정 후 작성해주세요.