SIX VALID CRITICISM OF ETHEREUM ACCORDING TO THE CREATOR (VITALIK BUTERIN)

As the Co-creator of Ethereum and the most recognisable face of the ethereum Foundation, Buterin articulated concerns that are likely prevalent among those in the development community. This post try to expantiate on the Ethereum co-founder concerns in a general way.

1. Poor Scalability
   From a social and technical standpoint, scalability has been seen and highly regarded as a major obstacle to Ethereum’s continued development. The incremental growth of the network makes it more difficult and inimical to enact significant changes through consensus. The incessant abuse by mining pools and activists als o pose a serious threat to Ethereum’s progress. Additionally, issues ranging from size and speed to gas controversies and throughput limitations renders any foreseen solution to scalability a mere mirage. No wonder Buterin emphasize scalability as the number one issue.

2. Ridiculously Expensive PoW
   Proof of Work which can be defined simply as the way miners confirm transaction and enter them into a blockchain. Although PoW is due to be replaced by Proof-of-Stake (PoS), for now, the cost incurred by the Ethereum network is absurd. According to Digiconomist’s Ethereum Energy Consumption Index, the network is using approximately the same amount of electricity as Moldova (a territory with over 3.5 million population). Judging from an environmental point of view, ethereum has a lot to do to be feasible for widespread adoption.
   Another disturbing development is the issue of spawn camping as coined by Buterin which he explained on twitter that ‘spawn camping occurs when a 51% miner cartel keeps attacking over and over again, rendering the chain useless’

1. Bad Privacy
   Privacy has become a very important topic in crypto-currency which of course have led to the popularity of Zcash and tumbling. Tumbling is a process whereby small amounts of a coin from independent pools to pay for a transaction making it much harder to trace the transaction’s originator.
   Mr Buterin explains an ongoing a plan to develop a general-purpose HLL (High Level Language) that compiles to zk-snark verification. Implementing zero-knowledge or zk protocol for Ethereum could make Zcash and tumbling services secondary, or even obsolete!

2. Security
   This can be explained in one sentence which is – it’s hard for regular users to hold large amount of funds without running substantial risks of theft or loss of their private keys. A good analogy is the scenario of having one irreplaceable, unique key to house, then losing it would be devastating though storing your valuables in your house might seem like a good idea for security purposes, but you would also need to weigh the chances that you may permanently lose access to your belongings. Crypto currency users face this same dilemma with their wallets. Additionally, centralised wallet providers present an attractive target for hackers making it very risky to keep a significant amount of crypto-currency in a single wallet. The choice of spreading your funds across several wallets can help avoid an unpleasant event but also requires keeping track of multiple private keys. Investors need to weigh the benefits of a decentralised currency versus the absence of a third-party mediator.

1. Storage
   Economics do not encourage good “storage hygiene”; insufficient incentives for clearing storage and insufficient cost for filling it, especially for long periods of time

2. Marginal Technical Inefficiencies
   There has been various marginal technical inefficiencies plaguing Ethereum development. Vitalik responding directly to a request for elaboration on reddit. This is highly technical.
   He explains:
   • With its 256-bit values, the EVM is substantially less efficient than it could be, making it hard to implement many kinds of cryptographic primitives.
   • The trie is hexary and not binary, and there doesn't yet exist a data format for taking advantage of the redundancy between a trie node and the fact that the hash of the node is in that node's parent; these two things together mean that Merkle branches are ~4x longer than they need to be.
   • RLP is somewhat overcomplicated; if I could redo it I would remove the single-byte case. I'd also come up with a trie format that doesn't use RLP to keep it simpler and easier to encode and decode.
   • The storage tree is 2-layer and not 1-layer. This makes various optimizations harder to implement and adds more edge cases.
   • The storage tree doesn't properly let users take advantage of the fact that fetching and writing anywhere up to a few kilobytes to a database doesn't cost that much more than fetching or writing 32 bytes. As a result, most applications take substantially more DB reads than they need to.
   • All current implementations of the state tree do an account or storage read by hopping through the tree in the DB. This makes any state reading opcode take O(log(n)) database reads when there exists a way to only make it take one.
   • Quite a few gas costs are probably still not well-optimized.
   • Not enough ability to take advantage of parallelization.

I hope this post is helpful and educative for you guys. Please I need you to upvote and I will keep on delivering good posts just like this. Thank you very much.