At Evolution, we’ve had the fortune of collaborating alongside the EOS community to propose unique approaches on how to decentralize voting and ensure fair block production. However, due to compute resource limitations and its future impediments on ownership rights as noted by Dan Larimer, we’ve begun the development of a scalable solution to RAM and property rights. RAM is a scarce resource in EOS and its limitations contributed to Dan’s implementation of 3 year limit on asset rights within the EOS constitution. The long term technical constraints of large RAM, CPU, and Bandwidth stakes being trapped within accounts should in no way lead to limits on user’s rights. Even with RAM upgrades by block producers there’s a likely scenario that hoarding accounts will need to be unstaked and auctioned off to free up RAM. Hoarding tactics are exacerbated further due to Bancor’s automatic pricing algorithm which allows for infinite price growth in scarce markets where hoarders exist at a low cost basis.
The technical and economic limitations of resource ownership should have signaled to core developers that the RAM market dynamics work contrary to basic long term ownership rights and required an overhaul. As other devs have noted it’s the responsibility of the core dev team to ensure the technical sustainability of long term asset rights before allowing the EOS chain to launch. Evolution is proposing system wide solutions to reassure EOS token holders of perpetual asset rights and to remove investor speculation entirely for RAM markets and fully reconstruct EOS Resource Management.
Core Issue around Resource Management
In the EOS ecosystem a token holder’s assets are tied to a user account that requires 4KB of RAM for the opportunity to commit actions and store data locally within their account. As a finite yet required resource for utilizing the EOS platform, we’ve seen market dynamics take hold of RAM prices as they’ve risen from $0.14 to $2.44 over 8 days. This brings an immense burden onto DApp developers looking to reserve rights for future resources they may need for their project. It now costs a developer around $10 in RAM per user they onboard onto their DApp.
Investor demand around RAM is quickly forming and has already reached 70% utilization without the existence of any DApps above 300 users. RAM’s surge in cost seems to be purely based on investors purchasing large stakes with expectations for profit instead of its original use case. To make matters worse, the ability to lease or rent RAM from other owners is not possible like with CPU and bandwidth. Evolution has a four tiered approach that will provide an alternative architecture to solve the above issues while additionally dismantling investor speculation and hoarding tactics that artificially drive RAM prices up.
Solution to EOS Resource Constraints
Evolution’s four tiered solution to RAM speculation aims to serve developers with a common structure found when purchasing instances from cloud or shared hosting services. This simplifies and bundles resources into various packages preventing specific resources from being directly abused by investor speculation. With the following set of solutions, Evolution is aiming to achieve 600MM active user accounts on a main chain architecture:
1. Removing RAM Speculation & Bancor Liquidity
In every market there exists a spread between a buyers bid and a sellers ask. EOS instead uses Bancor’s pricing protocol that aims to guarantee liquidity by setting price at higher rates as the asset reserve within the marketplace is depleted. Most digital assets are sold across exchanges which allow prices to find an equilibrium as buyers move to the exchange with the lowest Ask. However, in RAM there exists only one market maker operated by Bancor’s automated pricing algorithm. Bancor’s approach works best when multiple exchanges exist around a digital asset to increase price equilibrium, but in such a scarce siloed market such as RAM this presents opportunities for manipulation.
To solve this, Evolution is developing a grouped resource model similar to that of cloud hosting services that tie RAM to set CPU and Bandwidth. Since CPU and Bandwidth are infinitely scalable compared to RAM, these bundles will cut off investor demand that specifically targets RAM trading. Each base package will provide 2.5MB of RAM along with variations of CPU and Bandwidth. For additional resources, developers will be required to stake additional EVO tokens and select an upgraded resource bundle. This approach prevents direct RAM trading.
2. Staking for 30 days & Resource Bundle Tax
Unstaking EOS is a 3 day process which allows for traders to quickly sell RAM and gain liquidity. Evolution is proposing a 30 day lock up period for RAM to prevent short term traders from artificially pushing prices.
Additionally, we’re proposing a small tax every 30 days of the original RAM purchase date. The tax would be applied on a monthly basis to incentivize freeing up RAM that’s being hoarded and prioritize real development. All tokens generated from taxes will be burnt.
3. Restructuring EOS Main Chain Responsibilities
Limiting the main chain to account names, voting, and governance implementation limits each user account to the minimum KB usage and offloads non-critical usage to the DApps slot on the DApp side chain. The process for Developers to stake for compute resources will now fall into one side chain that allows developers to lock tokens for access to an open slot with bundled resources. The development slots on the initial side chain will be comprised of a shared instance that houses 10,000–20,000 DApps depending on their dev requirements and respective EVO token stake. Developers will be able to initiate their environment on the main chain through the community developed voting and staking portal.
Both the main governance and developer chain are powered by the same set of block producers to respect voter rights and decentralization. By handling all DApp and staked compute resources off the main chain, the data attached to accounts is now managed by a side chain where that user’s respective DApp usage history and data is stored instead of directly on main chain.
4. Limiting Main Chain RAM
We see the potential to reduce RAM usage by throttling active RAM on inactive accounts. By limiting RAM usage for only active user accounts there’s an opportunity to drastically increase total capacity to 600MM active accounts and around 300MM inactive accounts on main chain. We’re also looking at updating storage requests to SSD vs. RAM but with latency constraints in mind.
Ending Artificial price demand by Investors
RAM will eventually affect all user account creation based on the current management model. Evolution is preparing an implementation of these changes into Evolution’s blockchain but also developing a proposal to help implement these suggestions into the EOS infrastructure. Sharing multiple approaches to solve for the limitations of ownership rights only helps the entire ecosystem.
Look forward to your feedback. Join us on Telegram for the latest on Airdrop announcements.