Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
7-of-9 opened this issue Jun 17, 2018 · 61 comments

Comments

Projects
None yet
@7-of-9
Copy link

commented Jun 17, 2018

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?

@7-of-9 7-of-9 changed the title RAM costs for new accounts (i.e. incremental costs for dApp user acquisition) are too high RAM costs for new accounts (i.e. incremental costs for dApp user acquisitions) are too high Jun 17, 2018

@fundurian

This comment has been minimized.

Copy link

commented Jun 17, 2018

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

@BreakingSiam

This comment has been minimized.

Copy link

commented Jun 17, 2018

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

This comment has been minimized.

Copy link
Author

commented Jun 17, 2018

@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.

@oasis-eos

This comment has been minimized.

Copy link

commented Jun 17, 2018

ram is really expensive now

@7-of-9

This comment has been minimized.

Copy link
Author

commented Jun 17, 2018

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

This comment has been minimized.

Copy link

commented Jun 18, 2018

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

This comment has been minimized.

Copy link

commented Jun 18, 2018

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

This comment has been minimized.

Copy link
Author

commented Jun 18, 2018

@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

This comment has been minimized.

Copy link

commented Jun 18, 2018

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.

@andrei-anisimov

This comment has been minimized.

Copy link

commented Jun 18, 2018

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

This comment has been minimized.

Copy link
Author

commented Jun 19, 2018

@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

This comment has been minimized.

Copy link

commented Jun 19, 2018

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

This comment has been minimized.

Copy link

commented Jun 19, 2018

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

This comment has been minimized.

Copy link

commented Jun 19, 2018

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

This comment has been minimized.

Copy link

commented Jun 19, 2018

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

@btsfav

This comment has been minimized.

Copy link

commented Jun 19, 2018

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

This comment has been minimized.

Copy link

commented Jun 19, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jun 20, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jun 20, 2018

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

This comment has been minimized.

Copy link

commented Jun 20, 2018

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

This comment has been minimized.

Copy link

commented Jun 20, 2018

@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

This comment has been minimized.

Copy link

commented Jun 22, 2018

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

This comment has been minimized.

Copy link

commented Jun 22, 2018

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

This comment has been minimized.

Copy link

commented Jun 24, 2018

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

This comment has been minimized.

Copy link

commented Jun 25, 2018

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

This comment has been minimized.

Copy link

commented Jun 26, 2018

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

This comment has been minimized.

Copy link

commented Jun 26, 2018

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

This comment has been minimized.

Copy link

commented Jun 26, 2018

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

Fundamentally, cost is more important here than performance.

Confused...

@ghost

This comment has been minimized.

Copy link

commented Jun 26, 2018

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

This comment has been minimized.

Copy link

commented Jun 26, 2018

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

This comment has been minimized.

Copy link

commented Jun 26, 2018

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

This comment has been minimized.

Copy link

commented Jun 26, 2018

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

This comment has been minimized.

Copy link

commented Jun 26, 2018

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

This comment has been minimized.

Copy link

commented Jun 26, 2018

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

This comment has been minimized.

Copy link

commented Jun 26, 2018

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

This comment has been minimized.

Copy link

commented Jun 26, 2018

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

This comment has been minimized.

Copy link

commented Jun 27, 2018

@ghost

This comment has been minimized.

Copy link

commented Jun 27, 2018

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

@andrei-anisimov

This comment has been minimized.

Copy link

commented Jun 28, 2018

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

This comment has been minimized.

Copy link

commented Jul 4, 2018

@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

This comment has been minimized.

Copy link

commented Jul 5, 2018

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

This comment has been minimized.

Copy link

commented Jul 5, 2018

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.

@elorenzoni

This comment has been minimized.

Copy link

commented Jul 5, 2018

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

This comment has been minimized.

Copy link

commented Jul 29, 2018

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.

@aleksa2285

This comment has been minimized.

Copy link

commented Jul 31, 2018

Aloha : )
Just wanted to say that this problem might be recognised -> https://medium.com/@bytemaster/a-three-step-plan-for-lowering-eos-account-creation-costs-c3bf1ec736b7

Also, I'd like to know if @walnutown observation is true:

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.

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.

@aleksa2285

This comment has been minimized.

Copy link

commented Jul 31, 2018

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?
p.s. I am aware that this question shouldn't be asked in this issue

@BreakingSiam

This comment has been minimized.

Copy link

commented Jul 31, 2018

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.

@andriytyurnikov

This comment has been minimized.

Copy link

commented Jul 31, 2018

@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.

@BreakingSiam

This comment has been minimized.

Copy link

commented Jul 31, 2018

@andriytyurnikov

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.

@andriytyurnikov

This comment has been minimized.

Copy link

commented Jul 31, 2018

@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."
Wow.

" The technical issue is easy to solve."
I refuse to believe that Dan (or Evolution, or Telos) would reject your PR with solution of this easy to solve problem.
Also one should understand, that with free accounts built in, EOS would be attcked with account creation spam on the very day of introduction of such feature. So weak implementation would make it vulnurable.

@BreakingSiam

This comment has been minimized.

Copy link

commented Jul 31, 2018

@andriytyurnikov

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.

@aleksa2285

This comment has been minimized.

Copy link

commented Jul 31, 2018

@andriytyurnikov Just a little observation on your view

Also one should understand, that with free accounts built in, EOS would be attcked with account creation spam on the very day of introduction of such feature. So weak implementation would make it vulnurable.

I suppose there is solution for this ( You can create ETH addresses for free, right? ).
One approach would be ( as stated somewhere above ) to generate off chain solution?

@andriytyurnikov

This comment has been minimized.

Copy link

commented Jul 31, 2018

@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 (:

@EugeneChung

This comment has been minimized.

Copy link
Contributor

commented Aug 7, 2018

@halsaphi

This comment has been minimized.

Copy link

commented Oct 31, 2018

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.

@halsaphi halsaphi closed this Oct 31, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.