RAM costs for new accounts (i.e. incremental costs for dApp user acquisitions) are too high #4173
Comments
7-of-9
changed the title
|
Yeah, if we want to open account for 10k user you cant simply fork out USD10k right? that would be insane |
|
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? |
|
@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. |
|
ram is really expensive now |
|
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. |
|
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. |
|
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. |
|
@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. |
|
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. |
|
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 (
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. |
|
@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? |
|
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. |
|
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. |
|
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. |
|
I sent a tweet to Dan about this. Let's see if he can make a statement. |
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? |
|
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 |
|
@walnutown Did you publish your own |
|
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. |
|
@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. |
|
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? |
|
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. |
|
After a deep dive into what is going on, this statement actually appears in the EOS Technical Whitepaper:
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. |
|
After deep dive into what's going on, this statement actually appears on EOS dawn 4.0.
|
|
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. |
|
Also, this statement seems very confusing:
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. |
Confused... |
|
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. |
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. |
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. |
|
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. |
|
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. |
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. |
|
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. |
|
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
<#4173 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AWhsC9BCMr6VkDUYhjLsgctMCK1Z0LOKks5uAba0gaJpZM4UqvoE>
.
|
|
It's 4KB price, so right now 0.32 EOS |
|
What do you think about the following RAM model. Here it says:
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. |
|
@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) P.S. some account warmup signaling technics may be applied as a performance trick, instead of fundamental tradeoff. |
|
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? |
|
Around 390 Mb (100,000 * 4k / (1024*1024) 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. |
|
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. |
|
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. |
|
Aloha : ) Also, I'd like to know if @walnutown observation is true:
because I'd like to create custom token, and the primary reason I choose EOS is because of no tx fee. Would be grateful if you'd provide some info. |
|
Actually, I just want to know if i create custom token ( like in this tutorial: https://developers.eos.io/eosio-cpp/docs/token-tutorial) would I be charged fee for every transaction? |
|
Dan is equivocating in that post. Rather than admitting the underlying problem, he is trying to treat the symptoms. User accounts are idle 99.99% of the time. They do not need dedicated RAM, and it will not make the transaction speed any slower to cache the accounts in RAM only when they are needed. It will increase latency on the first transaction, but not transaction rate if properly designed. The need to force people to stake RAM in order to create an account is simply a business decision in order to force individuals to buy EOS. The customers of EOS should be app developers, not end users. End users should not care about the blockchain. It is wrong to design a system that requires this, and it will lose out to those blockchains that do not. Dan's newest solution simply replaces forcing users to engage the blockchain with EOS tokens by forcing them to engage the blockchain through his new iOS wallet. It is not a solution at all. I appreciate business realities and Dan's need to make money and support the valuation of EOS tokens, but this is a question of suitability of EOS as a usable blockchain. The only way this happens is if user accounts are completely free with absolutely no restrictions. Anything other than this will ultimately doom EOS because someone else will fork the project and design the chain correctly. |
|
@BreakingSiam, please understand that issue may be perceived (and maybe correctly, btw) as a tradeoff between free accounts and transaction speed - and resolving fundamental tradeoffs is hard as one would be grilled for making any choice. If someone would resolve the issue - EOS would be able to absorb others innovations. At the end of the day it is about execution, and so far nobody executing on that particular problem. Where I agree with you is that current solution underdelivers to initial promises of EOS project - free transactions for users, where free is supposed to be free, not free once you pay for account or free once you'll pay for RAM, but unconditionally free. |
|
I think you have misunderstood what I said. It is not a tradeoff between free accounts and transaction speed. It is at best a tradeoff between free accounts and a small amount of LATENCY on your first transaction. The EOS whitepaper makes a nonsequitor on this point, which is why I believe this is a business decision by Dan, and not an actual technical issue. Again, your comment of "If someone would resolve the issue - EOS would be able to absorb others innovations." misses the point. EOS is trying to make end users interact with the blockchain. The technical issue is easy to solve. The only reason it wasn't designed this way in the beginning, assuming my belief is correct, is they don't want to. It kills the EOS business model. The problem here is that the RAM model itself is incorrect for a useful blockchain, and all the problems discussed here are simply symptoms of that design flaw. But it is a philosophy and business design flaw, not a technical one. |
|
@BreakingSiam transaction may interact with multiple accounts, so have your latency multiplied on number of accounts you interacting with. Blockchain IO is time-consuming operation (same in ETH, btw) also IO operations are hard to parallelize - so IO is essential to performance in general. "The only reason it wasn't designed this way in the beginning, assuming my belief is correct, is they don't want to." " The technical issue is easy to solve." |
|
Without Dan coming on here and explaining the specifics of why this decision was made, it is impossible to say the real reason. But I have many years of engineering experience, and this one smells. I could be wrong, but without a detailed explanation I will stick to my analysis. Regardless, the idea of making users create accounts is not conducive to app developers. As an app developer, I want the easiest possible solution for my users. Making them aware of the specifics of the blockchain I use is not a reasonable business position. Maybe in 20 years it will be different, but this is a nascent industry and we need real applications, not ideology. |
|
@andriytyurnikov Just a little observation on your view
I suppose there is solution for this ( You can create ETH addresses for free, right? ). |
|
@aleksa2285, term trade-off means that you have to choose between certain characteristics and lose some to get some. Eth have addresses, not accounts, Eth has very limited IO capacity within a transaction, and a small transaction processing capacity. Surprise - all those are related. Off-chain, or on-chain, who cares. Theoretically, we may want to spend some amount of inflation generation of new accounts, but such approach has consequences too - free accounts would be created in bulk, and their RAM would be unstalked and sold by rogue actors - no doubts about that. Proposals and solutions are nice, but Eth can do this or I suppose there is solution for this is not a proposal of the solution (: |
|
For the step 2 of https://medium.com/@bytemaster/a-three-step-plan-for-lowering-eos-account-creation-costs-c3bf1ec736b7, how is the source modification going? |
|
The ram price is market driven, and we believe this has dropped since this issue was first opened. Closing this issue, however please contact developers@block.one if you require more information. |
and others
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?
The text was updated successfully, but these errors were encountered: