A Thought on RAM Squatting Problem

in eos •  7 years ago  (edited)

A Thought on RAM Squatting Problem



This article was written by Loum from EOS NodeOne and translated by Leo.

1. Introduction

After reading ‘jem’s opinion on RAM squatting issues, I decided to write this. The ‘jem’s comment in EOS Gov is in the bottom of this article.

In Dawn 4.0, RAM allocation model is switched to a market-based supply approach from a stake-based. While a stake-based approach ensures that you get all staked-tokens back, in a market-based, the amount of tokens returned depends on market price.

2. Introducing jem’s idea

The illustration below shows Block.one and jem’s solutions to the RAM squatting problem.

1.png

In both approaches, there is a 1% trading fee. However, while Dawn 4.0 chose the EOSIO RAM market, jem’s solution is a stake-based.

In other words, jem applied only the trading fee policy on the previous stake-based approach. By burning the fees or covering BP rewards with them, it can be beneficial for long-term holders as the amount of inflation is reduced. The result of this fee is to offset the inflation of tokens by taking them out of the market.

3. Drawback to market-based RAM allocation in Dawn 4.0

New market-based approach is to resolve RAM squatting by RAM trading. However, one defect of this is that users who are able to predict the RAM supply can speculate with it.

2.png

Daniel Larimer, CTO of Block.one, stated how to manage the RAM supply is determined by ⅔ +1 block producers. Therefore, they might supply only a certain amount of RAM of total available capacity, for example, 200GB of 1TB. Importantly, the producing BPs are able to predict the total capacity of RAM to be supplied to the market.

For another example, dApp developers who need a lot of RAM can make a profit by predicting RAM demand when launching their dApp on the EOS platform.

In other words, whoever predicts available RAM capacity can speculate with it in a market-based RAM allocation model.

4. Drawback to the previous staked-based RAM allocation

The graph below shows the price per RAM by Bancor algorithm in a staked-based approach suggested previously by Block.One.

The previous stake-based RAM model has no fee policy, but users should stake the amount of token set by the Bancor pricing algorithm and can get them back after use.

3.png

Reference : https://steemit.com/cryptocurrency/@eosgo/breakdown-of-eos-resource-allocation-video-w-dan-larimer

This RAM pricing algorithm creates barriers to entry that limit demand by raising prices as available RAM capacity is reduced. The less amount of RAM is available, the more EOS coins must be staked for the same amount of RAM. Critically, however, Block.One has never provided any suggestion to recover the squatted RAM. In other words, they have never suggested how to kick off the RAM squatters.

When the EOS Mainnet launched, developers would apparently try to squat at a cheap price in advance. Since RAM is not transferable, developers can not profit from trading, but they can squat for the preoccupancy of RAM. Therefore, it is necessary to take preventive measures against RAM squatting.

5. Our suggestion on RAM squatting problem

We agree with the jem’s proposal. In addition to this, we propose a method to recover the squatted RAM, which is a disadvantage of the existing RAM stake-based RAM allocation.

5.1 Preposition :

We first assume that we can distinguish between RAM squatters and real users by monitoring RAM usage. There are many ways to do this. For example, we can build a RAM usage monitoring tool, or ask potential RAM squatters if they are actually using it.

So in conclusion, if it is possible to distinguish RAM squatters, we can prevent the RAM squatting problem by giving a financial disadvantage to them through the voting of BPs, etc.

5.2 Financial Disadvantage to RAM squatters

We are thinking of two ways to put RAM squatters at a financial disadvantage.

First, we programmatically invalidate the squatted RAM. Then, RAM squatters will not be able to use their own RAM, which will be recovered and made available for other users. They may get back their staked coins at any time.

Second, we freeze the staked coins by RAM squatters. In other words, we give them a freezing period.
If RAM squatters apply for termination of RAM use. The corresponding RAM is recovered immediately and can be used by other users, but the staked coins by squatters is returned after being frozen for a certain period of time, 2 weeks or 1 month, for example.

6. Conclusion

Hence, we have confirmed the main drawback to market-based RAM allocation model in Dawn 4.0 and support jem’s staked-based RAM allocation model with 1% fee. In addition, as mentioned above, we propose two methods that slap economic sanctions on RAM squatting in order to recover squatted RAM.

Reference

Jem’s comment in the Telegram chatroom, EOSIO Gov.
Link : https://t.me/EOSGov/37814

4.png

nodeon_1.png

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  

I gave you an upvote but I really dislike your solution. Punish users for using the system as it was designed? Really poor...

Make it like that: the higher the price of ram, the more money goes to BPs with a clause it's strictly for hardware upgrade, so when the RAM price increase, BPs simply add more RAM and the market gets fluid and stabilizes.

Punishing people for buying resources - really bad idea. And who would be the judge to decide is the ram bought for speculation, or a new dapp developer is just reserving the resources for a future launch? The system can't judge on that and human arbitration will be a failure (will punish some, leaving others unpunished).

Incorrect. The BPs have no increased income from higher RAM prices. These fees go into a system account, and are held there ad infinitum to cover the costs when/if the user sells the RAM. No proceeds from RAM sales ever go to the BPs.

I said: make it like that. I know this isn't the current state. The other option would be to oversubscribe: keep selling ram until the real usage goes above 60-70 percent and then just add ram to the system. Having 64GB available and 1GB really used, the system could sell even 360GB or more. A virtual ram. Like in vms

I agree, we need to let the system work, anyone squatting on ram may get rekt if a sidechain is created, and when the BPs add more RAM because of the squatting, i just want to know if a BP is squatting on RAM.
After Squatters get rekt a few times the market for ram should stabilize

Squatters may purchase the RAM, but mostly they do not use it. Now, maybe 40GB is purchased, but less that 1GB is actually used. The BPs have no technical incentive whatsoever to upgrade. Also, as the BP revenue is unaffected by RAM buy or sale, there is no financial incentive for BPs to upgrade.