Reaction to Dan's EOSIO Resource Allocations Reimagined
Introduction
EOSIO has grown to be one of the premier blockchains in the crypto space being consistently in the top 8 cryptocurrency ranking by market capitalization. It was uniquely positioned to overtake Ethereum as the leading Smart Contract platform as a more scalable, energy-efficient and cost-effective alternative. The difficulty of Ethereum to scale, high transaction fees when it’s network is congested and the migration of many of its dApps into EOSIO made it seem that it is bound to happen. However, concerns of centralization and resource volatility have crept up and have been a source of much drama within its ecosystem.
We will not delve too much into centralization issues as it is a highly subjective matter. In reality, there are degrees of centralization in both platforms. EOSIO has a limited number of Block Producers (21) that seldom changes. On the other hand, Ethereum uses PoW with hash power gravitating into a few big mining pools; its future iteration will see it having 111 validators which will be randomly selected among those who exactly staked 32 ETH. In general, the situation is the same, those who have more resources (money, resource allocation) will have more chances of controlling the network whether it be EOSIO or Ethereum.
Resource Allocation Model
The bigger problem of EOSIO stems from the very design of its resource allocation model which was introduced to eliminate transaction fees. EOS was designed to be a Transaction Fee-Less blockchain by introducing an Operating System-like resource allocation model constituted by these three EOSIO resources: CPU, Network, and RAM. The idea is to allocate a proportional amount of EOSIO to holders of EOS depending on the amount of EOS they Stake. This means if you hold 1% of the total staked EOS then you are allocated with 1% of the total resource in the network.
The Problem of EOS Resource Allocation
The problem with this model is the possibility of a few big EOS holders to stake an enormous amount of EOS and hog the vast majority of resource allocations. This would have created a deficit in resources that could drastically affect the utilization of the EOSIO network. This was supposed to be addressed by the Resource Exchange (REX), a venue where those with limited EOS can rent extra resources to interact with the EOSIO network, and those with excess resources can earn from renting out theirs.
Resource Exchange (REX)
REX did not address this problem but actually empowered those who want to hog EOS resources for themselves. This resulted in a situation where CPU prices are so unreasonably high and the depletion of available CPU resources to rent. This situation reached its boiling point when a project called EIDOS started unlimited free airdrops of its tokens. The gist of the free distribution is quite simple, send any amount of EOS to a specified address then you will be refunded the same amount of EOS you sent plus, a random amount of EIDOS tokens.
Simultaneous to its release is its listings in several exchanges, making it a very attractive airdrop for EOS account holders to earn some free cryptocurrencies. This sends the EOS community into a renting Frenzy for CPU resources as it is the primary resource requirement to be able to claim more EIDOS. The demand for rented CPU was so high that it has triggered the limit of allowable CPU resources to be rented out. The sudden influx of rented CPU into the EOSIO Network disrupted the entire allocations of CPU resources with many finding themselves not having enough resources to interact with the EOSIO Network.
A major pain point for small EOS holders, Developers, and New Users
Image Source
EOS account owners suddenly found themselves having not enough CPU resources to do even the most basic transactions in EOS. In essence, their accounts have been frozen since CPU time per EOS allocation shifted due to the influx of EOS staked to CPU, effectively lowering guaranteed CPU time of all accounts. With CPU renting limits in full effect and much higher EOS per CPU time requirement, EOS account holders are thrust in a situation that only those with a huge amount of rented CPU or staked EOS in CPU are the only ones that can interact with the network.
This also created major headaches for developers who have been subsidizing EOS CPU time expenses for their dApp users with their resource allocation maxing out. New users were also not spared as it has become a never-ending cost center topping up their EOS wallets and stake them to CPU to get those precious EOS CPU Time. This resulted in disappointed developers who are now looking for alternative blockchains to migrate to and new users beginning to think the supposedly fee-less blockchain becoming is costlier alternative.
How did this happen?
Despite all the problems the situation has created within the EOSIO community, Daniel Larimer, declared that the EOSIO network is working exactly how it was designed to do without acknowledging that there might be some pressing design challenges that needed to be addressed. Fortunately, after several weeks, Dan posted a blog in Medium to address EOS’ resource allocation quandary. For the first time, he has acknowledged there is a design flaw in the current REX design and presented some possible actions that can be taken.
REX was designed for EOSIO CPU utility owners and those seeking CPU time a common market place where they can rent and rent-out CPU resources. According to Dan’s post, they designed REX to increase the price of CPU rent infinitely as the supply approaches zero. They were hoping that this model will entice more people to lend out their CPU resources since there is money to be made, however, this did not happen. Instead, a large number of CPU utility owners withdrew their EOS for rent, perhaps with the intent of joining the aforementioned EIDOS airdrop.
By allowing CPU utility owners to withdraw before the expiry of the 30-day rental period upsets the stability of the price of CPU rental. The sudden change in the supply of available CPU for rent introduced more volatility in the REX market prices with prices of CPU time rent skyrocketing. According to Dan CPU price and resource volatility, these are the two prevailing complaints of the current REX model.
Proposed Solution
Dan’s solution is the gradual and complete removal of CPU utility ownership and instead, 100% of all CPU time should be leased from the system contract at an EOS price that grows exponentially as the percentage of CPU lease increases. In doing so it removes the dynamic supply of tokens staked, removes the risk of people withdrawing EOS from REX and most important of all provides a more stable and predictable CPU rent cost. In effect, CPU Time becomes a non-transferrable resource and which effectively removes the speculative nature of that EOSIO resource.
Smoother curve for CPU time prices
To gradually migrate to the new market system Dan’s proposes the creation of a new REX market that will operate concurrently with the old REX market. To wrestle control of the market from the old REX the new REX will have the capability to allocate Virtual CPU-stake. This is an inflation mechanism to dilute the percentage of CPU time allocation of the old REX. Once the new market has 100x the supply of EOS staked to CPU, effectively controlling 99% of EOS CPU. He assumes that doing so will lead to the deprecation and removal of the old model.
Analysis of Dan’s proposal
I can describe Dan’s solution as an elegant way of addressing the problem without disrupting too quickly the status quo. His proposal seems to address some of the main problems of the current EOSIO resource model such as the price volatility and the consistent availability of these resources. However, his proposed solution seems too slow, too complicated and does not address the heart of the problem. This means even if the proposal is adopted it will not address the current, pressing and immediate needs of the community.
We need an immediate solution that will address the high cost of CPU time and ensure its stable price. While it is true that the new REX model removes some of the factors that affect the price volatility of EOS resources, when can we expect it to have a meaningful impact on the current prices and supply? Furthermore, are EOS account users and developers willing to wait that long? In an industry where there are many competing blockchains that offers the same level of scalability, security, and features, I think not.
Moreover, It also introduces another factor to be considered in the already convoluted existing system. Dan’s proposal will see a gradual transition phase where we will find ourselves having to contend with two REX models with the same function but different algorithms. Such a scenario should be avoided as it will just add more volatility in the REX and more confusion to EOS users. This is on top of the fact we are not sure how long the transition phase will be or if it will succeed since it entails giving up ownership of EOS resources.
More importantly, it does not address the fact that too much power rests on the hands of the few people who hold more EOS. The new REX will still be an exchange where those EOS holders with more EOS will surely hold more control, power, and influence over the resources and its price action. This is the heart of the problem. Dan and his team should propose a fairer resource allocation model that does not only favor those with higher EOS or at lease propose a countermeasure to quell too much influence of big holders.
dApps operator Countermeasures: e.g. Newdex Free CPU
To address the pressing issue of CPU-time deficit several EOS-based dApps have created brilliant solutions that will enable their users to side-step this predicament. Most of them are taking the firs-authorizer-pay model for CPU which basically means dApps operators subsidize CPU time resource usage for their customers. A prime example of this is Newdex's Free CPU for Place Order. The concept is quite simple, it allows users to open orders without having to spend their CPU time resource. Instead, dApps will be able to pay for their CPU time.
Image Source
To help ease the current CPU problem Newdex has also increase the number of free CPU usage from its platform, increasing its number three times its original count.
Counter Proposal
Throughout the article, we have been tackling only one component of the EOS resource model, CPU time but there are two other EOS resources that problems might originate from in the future. These are the NET and RAM EOSIO resources. The former is the Network data bandwidth resource measured in kilobytes while the latter is the storage resources also measured in kilobytes. NET follows the dynamics as the CPU market while RAM is based on the Bancor algorithm which does not experience the same price swings of CPU.
Dan’s proposes the same new REX algorithm and transition strategy in dealing with NET. This means we will contend with another new REX algorithm and like CPU time we will have to give up ownership of it. If approved EOS accounts users will now have to juggle between 4 differing REX algorithms for CPU and NET. While Dan’s intent is well-meaning further volatility and confusion will surely ensue after. Even tech-savvy people will surely have difficulty, so much so the great majority that are not as technologically sophisticated.
To avoid such a scenario I propose to simplify Resource allocation units. Since CPU and NET always go hand and hand and have the same market dynamics, why not just fuse them together as one resource. We can call them Transaction Resource (TR), the combined CPU time and NET bandwidth resource. If implemented we only have to deal with two resource allocations the combined CPU-NET resource or Transaction Resource (TR) and RAM which we can then call Storage Resource (SR).
I proposed a change name for these resources just to have a more cohesive and descriptive naming convention. By having only two resource elements greatly simplifies the EOSIO resource model and lowered the complexity of its use. This does not directly address the problem identified above but a way of preparing them for a more efficient solution for the problem. On a side note, RAM is not the focus of this blog-post but affects a lot of dApps developers. I found an interesting solution from LiquidApps’s vRAM that might prove to be a viable alternative. Those who are interested in the topic can follow the link I have provided.
Now we can focus on my ideal solution for the CPU-time supply problem. From my understanding, the main problem of the recent quandary is the inability of EOS account owners and developers to get CPU time resources they need to interact with the ESIO blockchain. To address this problem with the least amount of time, I propose the creation of a mechanism that will enable EOS account users to buy ad hoc one-time use CPU-time for transactions. Some DApps developers have already taken this approach by selling their CPU-time for a fixed number of transactions.
The challenge will be determining the price of each of these ad hoc CPU-time. There are several ways how to go about it. First, we can determine the average fiat cost of EOS transactions and assign that as baseline transaction fees. Second, we can agree on a standard and fix transaction fees that the EOS community will decide, these fees can increase depending on the complexity and resource requirements of transactions. Finally, If we want a more fluid and free-market approach of determining the price per transaction we can issue a new EOS-based token with each token representing 1 transaction and have it listed on a DEX.
I further suggest that this tokenize ad hoc CPU-time will constitute the combined EOSIO resource CPU-time and NET bandwidth as we have described earlier (TR). This will increase the utility of the token and at the same time simplify resource management. Some dApps already implemented the first-authorizer-pay model for CPU. But remember CPU-time and NET almost always go hand and hand without the other, transaction might not push through even if your CPU is subsidized. If the powers that be choose to continue with Dan’s proposal then my proposal might be an interesting alternative during the transition period.
However, if by chance my proposal is taken seriously and is implemented then we would have a solution that will not require us to give up our ownership of CPU-net and NET. There will also be no situation that users will not be able to interact with the EOS blockchain or effectively get locked out due to the unavailability of resources.