EOSIO offers token holders numerous options for allocating CPU and network bandwidth. EOSIO operates on the principle that if you own 1% of the tokens you can use 1% of the available bandwidth. Using the REX contract, we let token holders rent their bandwidth to others at a market rate.
EOSIO 1.8 allows a contract owner to pay for the CPU and network bandwidth of their users by co-signing the transaction. By cosigning transactions, applications can now rent resources from REX and cover bandwidth for users. Users no longer have to worry about bandwidth resources under this model. The model is similar to how companies can purchase or lease hardware from cloud services, while simultaneously enabling companies to subsidize the bandwidth requirements of their customers.
Aside from the two ways above to gain access to EOSIO networks, allocated, but unused, bandwidth can be freely used by others proportional to their tokens. This is similar to an internet service provider guaranteeing a minimum bandwidth, but offering higher speeds when the network is not congested.
The Free Resource Allocation Debate
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’s Free Transactions
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 Block Producers – 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.
Stability and Predictability On EOS Network
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.
Via This Site