RAM costs for new accounts (i.e. incremental costs for dApp user acquisitions) are too high

[7-of-9]

If one of the goals of EOS is to be able to very large platforms (e.g. social network), then how can 4kb * 0.015 EOS RAM cost per account be within the desirable tolerances?

0.5-1.0 USD per account simply can't work if your target is to create tens or hundreds of million user accounts for your dApp!

Am I missing something, e.g. is there any way for a dApp creator to somehow reclaim RAM costs for dormant or inactive user accounts that it has created?

[fundurian]

Yeah, if we want to open account for 10k user you cant simply fork out USD10k right? that would be insane

[BreakingSiam]

I am investigating EOS for an application where we plan on having several million accounts with our own currency. Each wallet will have a small number of tokens, and most of them will be inactive. After reading this, do I understand correctly that we will have to stake several million dollars worth of EOS just to give everyone a wallet?

If this is correct, this is a serious issue that needs to be corrected if EOS wants to be a realistic choice for new token launches. It makes no sense that every account needs to be kept in RAM at all times. Can the guys at Blockone please clarify this, and if the problem is as stated in this ticket, come up with a workaround for this problem?

[7-of-9]

@BreakingSiam - completely agree. This is a show-stopper and huge limitation factor. Not only this, but the problem only gets worse as EOS/USD increases.

One idea I'm toying with: creating new accounts on a private EOS net (i.e. SYS-denominated nodeos BP instance), and only "migrating" the accounts' keypairs to mainnet for "paying" user accounts. But it's clearly a disgusting hack.

[sportsminer]

ram is really expensive now

[7-of-9]

I believe it's a more existential problem than current RAM prices. Clearly, meaningful storage needs to be paid for, but in commercial terms the storage costs of a new "empty" account need to be zero, for the same reasons that transaction fees need to be zero.

[PeterGaivoronski]

Build a SQL table of all your user's accounts, and only use the chain for recording transfers between them (e.g. transaction type "myapp_transfer" with data {"from": "myuser1", "to": "myuser2", "amount": "0.2 mytokens"}). Then you have a chain-certified transfer for every real transaction that happens in your app, and anyone can just sum all the transfers to verify who has what balance. You'll only need one eos account (your app) and some cpu/bandwidth for executing the transactions. Obviously not the best solution, but it works. If you want to use EOS's user system and don't want to pay for accounts then ask that people register their own EOS account before connecting it to your app. You can offer a "registration service" where someone pays you ETH and you use an equivalent amount of EOS to make an account for them, then send them the private key and have them do an updateauth on it to replace its owner and active keys with their own generated keys.

[BreakingSiam]

Certainly we can come up with off chain solutions. In fact, why even use the chain at all?

I always assumed the contract would be the party responsible for allocating RAM, not the individual's account. That makes so much more sense. Then, the necessary RAM is limited to the number of simultaneous transactions for any smart contract, which is very small.

I just can't understand why Blockone would choose such an obviously broken model. Whatever problem it solved for them surely couldn't have justified the downsides. It is absurd for millions of user accounts to have dedicated RAM. At any given time only a tiny fraction of a percent of them are actually executing transactions. This model makes the entire system unacceptably expensive for all but the most trivial real world applications.

If the understanding of operation presented in this ticket is correct, then Dan needs to step up and do something about it. Because if he doesn't, someone will fork the project and do it the right way, leaving EOS to wonder why it failed, and leaving investors unwilling to trust Dan on his next ICO.

[7-of-9]

@PeterGaivoronski thanks - all reasonable workarounds. However, the target is to make signup as user friendly as Facebook, i.e. users shouldn't need to know about wallets, private keys, or create accounts elsewhere and then import them.

And us (the dApp owner) ever seeing, receiving or storing our users' privkeys is completely outside of acceptable scope for our project: we need to be truly decentralized, with privkeys only ever living in the user's browser session.

If I understand correctly, previous beta versions of EOS didn't have the RAM cost tied to accounts. I agree with @BreakingSiam -- this is an enormous barrier to dApp development. I was (still am) very impressed with EOS technical fundamentals, but such a glaringly obvious (deliberate??) limitation does make me question the motivation: this seems to effectively price out startups from the EOS platform.

[BreakingSiam]

Another consideration is that, based on Dan's video, 2 TB is the practical limit on RAM they are considering. Since the recommended figure for RAM per user account is 4KB, and because this must be guaranteed, it puts a limit of less than 500 million total EOS users. This system means that for our application to work, which envisions installing software on the phones at the factory, we would need to own 20% of all EOS tokens.

Seriously? We have to purchase a fifth of the network in order to process a few hundred thousand transactions a month? TWO BILLION dollars??? Yes, there are registration workarounds that we could do (which would make it more difficult for the user), but the easiest workaround is actually to do our own POA side chain on Ethereum and ignore EOS altogether.

It is too bad, because I really do like the technology. I had great hopes for EOS. But if this is correct, it seems that nobody at Blockone has actually considered the needs of stakeholders.

[andr11111]

What do you think about the following solution. Assuming that users interact with a EOS-based services not directly, but through a custom UI / middleware solution. The service can dynamically delegate resources before each user request in a separate action that is signed by the owner of the service and broadcasted by the user(the custom UI in fact) together with the main action in a single transaction. And later undelegate resources from inactive accounts. That way we don't have to pre-delegate resources before user actually needs to interact with the service.

For example, let's say a user wants to send a friend request in a decentralized social network (friendRequest action). Let's assume that initially the user account has no delegated network resources. When pressing the 'Add Friend' button in the UI the following happens:

1. The UI sends request to a backend service to receive the JSON of the delegatebw action and its signature. The staked amounts are calculated based on the action that needs to be performed by the user.
2. The UI constructs the friendRequest action and signs it with the user's private key.
3. Both actions are packed in the same transaction with 2 signatures one for each action.
4. The transaction is sent to the network.

I'm not too familiar with how signatures work in case of a multi-action/multi-party transaction, but am wondering if this is the right direction.

[7-of-9]

@andrei-anisimov Interesting scenario, but I don't think it addresses the user RAM cost issue, e.g. in your example, consider the user who wants to send the friendRequest action.

How does that user's EOS account get created initially, and who pays for the minimum RAM requirement of that new account?

[red-butterfly]

completely agree! Our company also have this problem. We have to prepare a lot of EOS for the user register. If BlockOne didn't solve this problem, I don't think there will have a lot of Dapp on EOS. Unless every ordinary people have his own EOS account.

[walnutown]

Also get an issue about RAM Fee. Today, I issued a token on EOS called XToken, and then I transferred XToken to another EOS account. I found that I was charged RAM fee for the transaction. I'm wondering what's the reasons behind this design? EOS transfer is free, while new token is charged. This will prevent developers to issue tokens on EOS. Remember that ETH grows because lots of people use it to issue tokens.

[BreakingSiam]

After studying this issue in depth, I believe Github is the wrong forum to correct this problem. This is a fundamental problem with the vision of what EOS is supposed to be. I have started a thread on EOS Go to ask everyone to delay launch of the mainnet until this issue is corrected.

If you have thoughts you would like to share, please express them politely over there. This issue is big enough and ubiquitous enough that it needs to be thoroughly discussed and we need to get Dan involved to explain the thought process. Only by delaying the mainnet launch can we expect this to happen.

https://forums.eosgo.io/discussion/1459/please-vote-no-on-eos-mainnet-launch-until-ram-issue-is-properly-addressed

[BreakingSiam]

I sent a tweet to Dan about this. Let's see if he can make a statement.

[btsfav]

0.5-1.0 USD per account simply can't work if your target is to create tens or hundreds of million user accounts for your dApp!

why would you go through the hassle and create a DApp for millions of users without a solid revenue stream?

other than that, yep, what happens if the limit is reached? no new users?

[marketstack]

it would appear that the price of ram can be regulated. there is a function called setram in the eosio.system contract which can be used to expand the current ram supply which leads to a mechanical decrease in the price of ram (due to the bancor algo)

who has the authority to call setram?

whoever has the auth is basically the FOMC / central bank of RAM on EOS

[dskvr]

whoever has the auth is basically the FOMC / central bank of RAM on EOS

setram is a system action that is privileged, and so can be adjusted by consensus. There's no one party that can unilaterally adjust supply.

[dskvr]

I found that I was charged RAM fee for the transaction.

@walnutown Did you publish your own eosio.token contract or did you create/issue with the network's eosio.token contract?

[BreakingSiam]

The issue under consideration isn't actually the price of RAM or who can set the value.

The issue is that the current RAM model requires user accounts to have dedicated RAM. This is not a credible way to allocate RAM. It is hostile to the dApp developer community, who need to be able to create thousands to millions of user accounts, many of which will not be used. This is done to improve the user experience. Forcing the end user to know anything at all about EOS acts as an obstacle to user acceptance of the dApp.

The problem here is the very nature of what EOS is. Is it a tool for dApps, or is it some kind of operating system for end users? Block One seems to have designed it as the latter, which is a huge mistake, because this does not service the dApp community.

Failure to correct this model and make the RAM allocation a function of the contract, and not of the user, will lead to a fork of EOS with another system taking the correct action, which will ultimately prevail because the dApps, which are the real value of a blockchain, will choose the alternate system over EOS.

The price is largely irrelevant. Anything more than zero to create an account is too expensive.

[DecentralizedMind]

@marketstack setram is managed by the consensus of 2/3 Block Producers. I believe 15 need to be in agreement to increase available RAM. The fluctuation of this has some major pros/cons so it's unlikely to be adjusted frequently.

[DecentralizedMind]

RAM is now up to 50% utilization only 2 weeks after launch. Is there a way to see which wallets are hoarding or "using" ram?

[thedrbits]

I agree that the fact that accounts require RAM at all damages the free transaction model and fundamentally damages the on-boarding experience. Also, a limit of 500 million users @ 2 TB of RAM means no FB level adoption is possible. People have multiple accounts, so that's going to be far less than 500 million people.

[BreakingSiam]

After a deep dive into what is going on, this statement actually appears in the EOS Technical Whitepaper:

"application developers will pay the nominal cost of account creation to sign up a new user. Traditional businesses already spend significant sums of money per customer they acquire in the form of advertising, free services, etc. The cost of funding a new blockchain account should be insignificant in comparison"

Setting aside the reality of whether this statement is true or not, it is clear from the current status that EOS has failed in its mission. The cost of funding a blockchain account is orders of magnitude too expensive. Since it appears there is no desire within the EOS community to correct this fundamental oversight, the only option right now to close this issue would seem to be a fork of the Blockone software into a new chain.

It is unfortunate that we must split the community so early in its development, but the gap in philosophical differences appears to be unbridgeable. I invite anyone who might be interested in a project like this to contact me privately.

[ghost]

After deep dive into what's going on, this statement actually appears on EOS dawn 4.0. I strongly recommend to read the newest resources. https://medium.com/eosio/introducing-eosio-dawn-4-0-f738c552879 EOS didn't failed, there is no need to fork EOS repo and name it "A fork of EOS with reworked resource algorithms that are not hostile to Dapps"

Over time Moore’s law will allow block producers to upgrade to 4TB or even 16TB of RAM and this increase in supply will trickle into the the EOSIO RAM market lowering prices.

High performance blockchains need all data in RAM because the time to access disk will quickly drop transaction throughput to just a couple hundred transactions per second. In order to scale RAM usage we need multiple chains with independent memory regions running on independent hardware.

EOSIO block producers can operate many different chains that all use the same token for buying RAM and staking bandwidth. The producer elections will happen on the main chain and all related side-chains will be operated by the same set of producers. Each chain can have its own 1 TB+ of RAM and decentralized applications can send messages between chains with just a couple seconds of latency.

The price of RAM will be different on all chains which will inform DAPP developers where it is cheapest to operate.

It is our belief that scaling via Inter Blockchain Communication will give almost unlimited scaling potential. This approach scales RAM, network, and CPU at the same time. Considering that signature verification, context-free-action validation and IBC proofs will already saturate most CPUs with high-single-threaded throughput, optimizing for multi-threaded WASM execution will likely be bottlenecked by other resource constraints.

[BreakingSiam]

Thanks ppolak101 for your comments.

The problem though, isn't so much the cost of RAM. The problem is the EOS model that requires RAM to be purchased at all by individual accounts. All resource usage needs to be a function of the contract, not the individual users. Dapp developers are looking for a blockchain that does not get in the way of user signup. The only way to make EOS completely invisible to the end user is to remove this constraint.

As this is a fundamental design choice by Blockone, and as the developers do not seem to be interested in modifying their model, it would appear the only way to correct this deficiency is to fork the software. I don't particularly enjoy the decision, but it would appear to be the only way forward at present.

[BreakingSiam]

Also, this statement seems very confusing:

High performance blockchains need all data in RAM because the time to access disk will quickly drop transaction throughput to just a couple hundred transactions per second.

This would appear to be extremely dependent on the way the code is written. Proper caching should easily allow for tens of thousands of transactions per second. If this were not the case, modern SQL databases could not exist.

There does not seems to be any fundamental reason why the model chosen by Blockone needs to be the only model. If there is a reason why this solution and only this solution is practical, then Blockone needs to step up and justify it to the community. As it stands, EOS is in danger of being supplanted by a better environment that does not suffer from this problem.

[ghost]

There is no need for individual user to purchase any ram to be able to use dapp. Dapp developers can choose to use ram alocated by dapp, or force user to use his own. For example Monstereos dapp uses users RAM, but developers could also make a registration process completely invisible, by creating accounts in the background, or by buying a bunch of ram on their own and use it instead. I still don't see any reason to make any fork. And BTW is there any reasonable proposition, or just make another chain?

[BreakingSiam]

It is not currently possible to create a user account and specify 0 RAM size during creation.

[ghost]

This would appear to be extremely dependent on the way the code is written. Proper caching should easily allow for tens of thousands of transactions per second. If this were not the case, modern SQL databases could not exist.

I don't understand. Are You comparing single-server SQL database performance to a blockchain?

It is not currently possible to create a user account and specify 0 RAM size during creation.

It's not, nobody said it is.

There does not seems to be any fundamental reason why the model chosen by Blockone needs to be the only model. If there is a reason why this solution and only this solution is practical, then Blockone needs to step up and justify it to the community. As it stands, EOS is in danger of being supplanted by a better environment that does not suffer from this problem.

The reason is in the link i sent before - performance.

[BreakingSiam]

And BTW is there any reasonable proposition, or just make another chain?

Of course, there is a reasonable proposition. I thought that was clear. Namely, challenge the statement that all user data needs to be kept in RAM, all the time. This is too expensive to be a practical model. User data needs to be in persistent storage.

[BreakingSiam]

The reason is in the link i sent before - performance.

Not an acceptable answer without proof. This is the reason for a fork.

[BreakingSiam]

Fundamentally, cost is more important here than performance. As has been stated many times, performance can be scaled by using multiple chains. Cost however, needs to be optimized. The blockchain that optimizes the cost of launching a Dapp will ultimately be successful. EOS is currently too expensive to use.

[ghost]

The problem though, isn't so much the cost of RAM.

Fundamentally, cost is more important here than performance.

Confused...

[ghost]

EOSIO is opensource. Basically anyone can do his own fork and start other blockchain. But i think majority will stay with original, for now working very well and i'm sure good designed.

[BreakingSiam]

I don't understand. Are You comparing single-server SQL database performance to a blockchain?

I am stating that fundamentally, a system can get throughput of tens of thousands of transactions per second reading and writing to persistent storage, and database prove that. The blockchain needs to be designed so as to optimize for this problem. I do not take at face value that this will limit the throughput to a few hundred transactions per second. I have enough design experience to know that is not likely to be correct unless poor design choices have been made.

[ghost]

I do not take at face value that this will limit the throughput to a few hundred transactions per second.

There are many servers on a blockchain which are communicating with each other. Maybe one single server can handle millions of tps, but any delay is multiplied on a blockchain, because database is multiplied. 1 sec delay on read time equals 1 minute delay on 60 server blockchain(simplified). That's why it's all stored in RAM.

[BreakingSiam]

The design could also be written to precache the needed account data, so only a small percent of accounts were in RAM. After everything had been finalized, it could then be rewritten to persistent storage. There is no reason to keep unused, idle account information in RAM on the exceedingly unlikely chance it might be needed. That model is too expensive to be of practical use. Latency on any particular transaction might go up this way, but throughput would not be seriously affected.

A few extra msec of latency on a transaction is a much more acceptable solution than paying $1 to create an account.

[ghost]

I don't think we can discuss real price right now in so early stage, when RAM is probably expensive mostly because of speculators. I believe we'll see the real price after some time, after sidechains and bps additional storage.

[BreakingSiam]

I don't think we can discuss real price right now in so early stage, when RAM is probably expensive mostly because of speculators. I believe we'll see the real price after some time, after sidechains and bps additional storage.

I believe you are correct, however, in my opinion, any cost other than zero for account creation is too expensive.

[BreakingSiam]

EOSIO is opensource. Basically anyone can do his own fork and start other blockchain. But i think majority will stay with original, for now working very well and i'm sure good designed.

The best developers in the world can make bad design decisions that become very expensive to correct later on. Right now, Blockone has a choice. Correct the model and re-engineer the software so that accounts can be created with zero RAM, or double down on the decision that RAM is required for a user account and try and push that through sales and marketing.

If they don't correct the problem though, EOS will be forked and corrected by someone else.

[ghost]

I don't think you understand eosio opensource conception. Blockone is no longer an owner of the code. Anyone at anytime can make another EOS blockchain, or just contribute to github. There is no sales or marketing in EOS.

[bycz6]

What is the cost per account creation? Comparing to steem, where the cost is also high, but the cost is covered by a master account, right?

ppolak101 notifications@github.com escreveu no dia terça, 26/06/2018 à(s) 05:21:

I don't think you understand eosio opensource conception. Blockone is no longer an owner of the code. Anyone at anytime can make another EOS blockchain, or just contribute to github. There is no sales or marketing in EOS.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/EOSIO/eos/issues/4173#issuecomment-400173467, or mute the thread https://github.com/notifications/unsubscribe-auth/AWhsC9BCMr6VkDUYhjLsgctMCK1Z0LOKks5uAba0gaJpZM4UqvoE .

[ghost]

It's 4KB price, so right now 0.32 EOS

[andr11111]

What do you think about the following RAM model. Here it says:

Under the Dawn 3.0 system contract, you could only sell RAM for the price you paid. The goal was to disincentivize hoarding and speculation. The downside to this approach is that those who buy RAM cheaply have no financial incentive to free RAM for other users after it gets more congested.

Wouldn't it be better to use the initial approach, but instead of allowing to sell RAM for the same price it was bought, use a decay function that allows to sell it only for a lower price, which slowly declines over time. This can be thought of as RAM rent fee. This would discourage speculation while at the same time giving incentives to free up RAM sooner than later. Just a thought.

[andriytyurnikov]

@BreakingSiam - and Dan talked a lot about the importance of blockchain having better user experience then non-blockchain, yet somehow we got current situation. I don't see how transaction speeds are more important than zero cost for end user - and obviously, B1 spent to much time talking to no one and making hard tradeoffs alone under pressure of delivery date (and the whole situation with wallets and voting tools shows how bad things are, and their javascript libraries suck, BTW) This stuff should be totally escalated.

P.S. some account warmup signaling technics may be applied as a performance trick, instead of fundamental tradeoff.

[elliottssu]

I want to konw if the number of new users of app is one hundred thousand, how many ram, CPU and Network Bandwidth do i need?

[elorenzoni]

Around 390 Mb (100,000 4k / (10241024) to create the users. The CPU and NET is far less demanding. It is reseted every day and depends on the number of transactions you will generate. The memory is the great problem as you need to allocate around 4k for each user and a lot more to store app specific data on the multindex structs. At the current RAM price is totally impracticable. You will need to wait to launch such application until the sidechains be available.

[elorenzoni]

I know that we will need to buy around 4k of ram for each new account. When the account get created it uses around 3k to store keys and other internal information. I know that this account can not ever be deleted. Suppose that this account become inactive later. Is there any way to claim back this ram to use in another account ? In this way the problem of user ram would be mitigated. If not this amount of ram will be lost forever as it will stay allocated uselessly.

[PatientDirected]

Take a look at TELOS, WAX and EVO (Evolution) they are using a different ram pricing model tied to actual ram costs, uncoupled from EOS value. I would also assume there could be a fast cache setup on the network (perhaps a forked copy) for virtualized ram that would allow some performance decrease for lower ram costs on the network.