There’s been a lot of emotional responses to the current situation with EOS RAM. It’s understandable. As humans we’re a complex mix of firing neurons and chemicals. It’s in our nature to become emotionally invested in things that we care about. On the flip side of the coin is our ability to push past or emotional urges and make decisions based on information rather than feelings.
While I have no doubt that most of the proposed solutions to the short supply of RAM on EOS are coming from a desire to see a better ecosystem, I think the majority of them are fundamentally flawed and are more of an emotional knee-jerk reaction than an actual solution. While there are plenty of speculators trying to build wealth through RAM trading at the moment, those individuals are not the only people who can or will be adversely affected by any rushed decisions.
Programming Languages and RAM
To better understand what the issues are, first we need to understand the function of RAM, and how development environments have evolved.
RAM is temporary storage designed to quickly transfer information. No matter whether you’re talking about a desktop computer or a massive blade cluster, the amount of RAM available to a system has always been limited. Early models of computers had an amount of RAM that’s trivial by today’s standards. When I first started to learn to program I had access to an Intel 80286 system which shipped with a whopping 1MB (or 1024 KB) of RAM. So not only did the operating system have to take less than 1MB, but you had to have enough memory left over for any programs that you needed to run.
Today home desktop computers top out at 512GB of RAM. Practically speaking, this enables developers to write code without worrying too much about how much RAM they use – most computers are shipping with at least 4 GB, so more often than not you have plenty of RAM to work with.
Unfortunately, this has also led to significant problems in the software development industry. Code written for the earlier generations of computers was frequently written in C or C++ which by necessity allowed for direct control over how things like memory are handled by the software being developed. That meant that there was a lot more complexity and understanding required to make software. If you didn’t understand how things worked under the hood mistakes could result in significant problems. Writing poor code could mean that an application crashes the entire system, or eats up every last bit of free RAM.
Over time higher level languages began to appear which abstract these more difficult aspects away from the developer, and make the code easier to read, write, and understand. This of course came with a cost. While these higher level languages are easier, they typically do not have the same level of performance. Often they take longer to process sets of commands and they require more resources, like RAM, in order to perform them. Developers stopped caring how well the software they wrote performed – all that matters was if it did what it was supposed to when you clicked run. If you ask how their software uses the stack you’d probably get a million answers about how their application uses web-based technologies, but you’d get very few that talk about how their information is stored in RAM. Few bother to learn all the ins and outs of the architecture when the framework manages resources for them in the background.
Resources on EOS
RAM is a finite resource. The largest capacity we’ve seen to date is a prototype created by HP which allows for up to 120 TB, but those machines aren’t common. Most servers are limited by both technological restraints on capacity of the RAM, and the ability for the underlying system to be able to support it. It certainly doesn’t help that RAM doesn’t improve at the same pace of other technologies. RAM speed only improves at a rate of less than 10% per year, so it’s safe to say that it’s much better to plan for what we have available to us currently than what the future could possibly hold.
Since the vast majority of developers have moved towards languages under frameworks like .Net, they aren’t used to having to optimize their code. They’re used to eating up however much RAM they eat up, and many don’t give it a second thought. This will have a direct impact on developers who actually need RAM to function, because ultimately RAM is a finite resource.
Ultimately the amount of RAM will only be able to increase so much on any one chain, whether it’s the main chain on EOS or one of the proposed side-chains. If wasteful development is encouraged, the end result will be fewer quality applications hosted on each chain, as well as a need for far more chains. Arguments for a massive reduction in price (which includes any drastic increases in quantity) will directly result in an ecosystem that is much worse off in the long run.
RAM and Economics
Most people are familiar with the concept of supply and demand, and RAM is no exception. The more plentiful it is, the cheaper it will be. Of course, the opposite is true as well. The more scarce it is, the more valuable (and costly) it will be.
Increasing the current capacity or setting artificial price limitations on RAM as many people have proposed would definitely provide some immediate relief and cause prices to drop. It absolutely would make it easier for more developers to obtain. However, there are two other effects – and not a single person arguing for those changes have addressed the side effects.
Significantly increased capacity would move the total capacity much closer to the technological limits of capacity. In other words, we would simply be punting the problem further into the future where there are even fewer solutions to the problem. If the maximum capacity is already near the technological limit we lose the possibility of increasing supply as needed. Any advancements which could provide relief (the HP prototype listed above for instance) will likely be so expensive that we bar any block producers who do not have significant amounts of capital. Ultimately we will see fewer producers, and will have fewer options available when we run into a capacity issue again.
Although increasing the capacity might seem like a solution, it’s more akin to taking a bottle of pain killers to treat a broken limb. Sure it might feel like you’ve no longer got a problem, but it’s still there when the pain killers wear off.
Likewise, artificially setting prices will have adverse effects. Cheap prices will encourage wasteful development. If it’s not necessary to optimize software to minimize RAM use, most people aren’t going to bother. Optimization takes time, and time is money. It would be completely rational to skip optimizing software if the extra RAM purchased is cheaper than the amount of time it would take to optimize. Although this amount is insignificant when looking at a single dApp, in aggregate the waste would add up, and would contribute to the exact same scenario we see now – too little RAM for every developer to deploy to the main chain.
Due to supply and demand the result of an increased supply would be a decreased price. Like a decrease in price, this would shift the equilibrium of supply and demand to a point where far more RAM is demanded (due to a price decrease). If RAM is cheap the main chain on EOS will be filled with wasteful applications using more than they need, trivial applications which serve no purpose, scam ICOs designed to extract wealth, and all sorts of other uses which could be far more damaging to the EOS ecosystem than a barrier to entry. If there’s any doubt, I would encourage you only to take a look at Geocities, the Google Play store, or anywhere else that has a low barrier to hosting content. While there are some skilled developers that benefit, there are many more unskilled or downright malicious developers that benefit from the lower barriers.
Do we really want to encourage the possibility of hundreds or thousands of memes or abandoned applications filling the chain at the expense of serious applications that could lead to mass adoption? Do we want the main chain to become filled with nothing but hatching shrim and trading fake drugs? Too low of a barrier to the main chain would make that a possibility.
Bancor proposes that in addition to interfering with pricing we should also charge RAM holders what amounts to “rent” to incentivize holding RAM only when you need to do so. Even if we were to ignore Banor’s failure to implement proper planning and security measures when they updated to a compromised wallet client, this is a short sighted solution which would have far more negative effects in the long term than it would solve.
Several things would happen with this proposal. First, developers would be affected by RAM increases which reduce the value of the RAM they’ve already invested in. Second, they would also see a reduction in value as a result of the RAM tax levied on them. Suppose a developer invests in 100MB of RAM at the current price of 0.42459136 EOS per KB, for a total of 241,173 EOS. Each month their investment in RAM is reduced by 10%. After one year of hosting their application, it becomes clear that it’s not really taking off so they would like to recoup their investment and go back to the drawing board. After 12 months their 241173 EOS investment is now worth 68,114 EOS. Worse yet, if we’ve decided to periodically double the amount of physical RAM available we could effectively have that number – and they could expect to recoup only 34057 EOS out of the initial 241,173 – which (again at current prices) would be a total loss of ~$1,520,000 USD.
Now one might think it would be better to recoup ~$250,000 and just accept the losses. Unfortunately, people aren’t always rational creatures – many times we let our emotions get the better of us and make sub-optimal decisions. It is more likely that the developers would fall into sunk cost fallacy when considering whether or not to sell the RAM or hold onto it for the possibility of future projects. They did invest $1,771,222 in RAM – so selling or replacing it could be argued to be a waste of nearly $1.5MM. Wouldn’t it be better to hang onto it in case you need it later, rather than potentially lose another $1.5MM in the future?
This concept isn’t new, and how it plays out is actually the foundation of many business models. World of Warcraft and Farmville are two blatant examples of exploiting this flaw in human psychology. The more time you have invested, the more likely it is you will continue playing because all the time (and money) you invested before will seem like it was wasted. After all, when you quit what do you have to show for it?
The effect on EOS should be easy to envision. Developers will begin to cease their development and abandon a project, but they will fail to release their RAM. Eventually they may want to return to development, and they already have millions invested. Whether they return with a new project or not doesn’t really matter – that RAM is still reserved which means there is less supply for other applications. Given enough time, and enough failed projects, it isn’t hard to conceive a situation where we have significant amounts of RAM taken up by applications which no longer serve any purpose, but still prevent entry onto the main chain.
The Free Market Solution
Many people have been arguing that Dan’s proposal for providing physical storage, side chains, and allowing the market to continue is flawed because it is not really a free market. They have a fundamental misunderstanding of the proposed solution because, as I hopefully have illustrated, they are only focused on the short term mitigation of effects.
If we put the current situation into economic terms, we have a single firm producing RAM – the current block producers. This results in a lower supply despite demand, and as a result a higher price. However as more side chains (competing firms) come online, we would see a downward pressure on the price of RAM on the main chain. We would also see a reduction in price in response to the introduction of substitutes (hard drive and SSD storage). Furthermore, if the price is still above where people think it should be, even more side chains and sources for alternative storage will be added to the network.
As more applications invest in their RAM requirements we would likely see a reduction in speculators. People are speculating on RAM due to the volatility. The current volatility allows for one to invest at lower amounts, sell as the price quickly rises, then reinvest once it drops again. As more applications lock up RAM the gaps caused by that cycle will likely decrease – and as a result of the decrease in profit we should see fewer speculators.
Developers Without Capital
The final concern which is left with a free market style approach is what about the developers who lack enough capital to purchase the RAM they need (before side chains). There are many potential solutions that I believe could help. Applications with promise could run crowdfunded campaigns – potentially even on the blockchain itself. BlockOne could dedicate a portion of the funds they have to ensure a healthy ecosystem to such projects to help ensure a diverse dApp ecosystem. Block producers could promise to reinvest a portion of the rewards remaining after expenses back into the community (like with projects without much in the way of capital). We could even come up with agreements written into the blockchain that require paying it forward. If you take money from the community and have the potential to earn money from your efforts, you contribute a portion of your earnings to other projects in need.
There are a ton of potential solutions out there for each of the individual problems. So far though, the majority of the solutions people champion, although coming from a good place, are short sighted and could potentially damage EOS and the community in the long term. Since there is the potential for creating even more problems than we solve it’s especially important that both block producers and the community have conversations about the problems we face, solutions, and approach them with a critical mindset.
It’s easy to get emotionally invested in the idea of “making speculators pay” for eating up resources, while ignoring developers are also investing in RAM early to get it while it’s cheap. Ideas thrown around focusing on what happens now, without discussing how it could impact us in the future, could end up being just as harmful as nothing but a network full of RAM speculators.
I think everyone needs to take a step back, take a deep breath, and be open to hearing each other’s opinions. There are tons of different perspectives in this community, and probably just as many suggestions on how to fix things. Problems like this need all those perspectives. It isn’t just a technology or economic problem. It’s both. This community is made up out of people speculating on the price of EOS, developers, companies, and people who simply believe this is the next step forward. All of those people should have a say, and we should be focusing on how we can accomplish things for the community as a whole. As long as we tune out the perspectives that do not align with our own that can never happen.