Constructive Criticism of Ethereum Development
One of the larger goals of Ethereum from the beginning was to replace the current internet with the internet 3.0, however the current tooling for the ethereum ecosystem as a whole does not deliver enough to support the environment where real applications are made. These are the major issues with developing on the ethereum platform today.
Testing
The inability to quickly, easily, and rigorously test smart-contracts before they are pushed onto the blockchain has hampered development in the Ethereum community. Testing is not some abstract problem for ethereum developers as the DAO, and Parity wallet hacks famously proved. The smart-contract paradigm presents entire classes of exploits that were previously unknown. Better security practices are necessary to push progress forward and a good system around technical testing and debuging is critical for developing non-trivial applications. The difficulty of this problem is further compounded because all code pushed to Ethereum is immutable. Currently the best solution in the ecosystem for developing and deploying smart-contracts to the blockchain is the Truffle Suite — which is slow, runs on testrpc which can be buggy, lacks documentation, and uses implicit design patterns that can be difficult to grok for new users. Testing is an integral part of the success of current and future systems, and the community needs to make strides to survive. And of course, all of this would be a lot easier if the Solidity programming language and tooling was a bit further along in it’s development.
Languages
Solidity is weird. Solidity was “modeled” after javascript, but shares very little except a vague syntactic similarity. It has all sorts of unsound quirks like:
- Mutable state by default
- Overflow and underflow bugs
- Weird visibility rules. contracts vs libraries, this
- Function and keyword overloading
- Weird storage and memory allocation. implicit copy by value or reference depending on where the operands are stored
The next language fronted by the Ethereum foundation, Vyper, is modeled after python when the chief complaint from most of the community was a need for a more secure, simple, sensible language. And unfortunately Low Level Lisp Language is too low level to make any large applications with. So we are stuck for now with Solidity.
Web3.js
Ethereum’s flagship library for interacting with the blockchain, web3.js, does not provide a full-stack solution to all the problems one runs into when writing a Ðapp.
- Web3 doesn’t natively support all the various methods customers actually use to interact with the the ecosystem. i.e. ledger, trezor etc.
- Web3 isn’t nativly extendable. It’s a simple wrapper around the json-rpc api with some ethereum smart-contract functionality.
- The codebase is also too large (too many unnecessary dependencies), the codebase is also written in vanilla es5.
For Web3 to allow the next generation of developers to come in and build amazing apps we need a more complete SDK for Ethereum.
Oracles
Once an action on the blockchain loses atomicity either a third party or an oracle is needed. A third party brings back concerns of centralization, but oracles are not yet well-developed enough. Oricalize and others are working on this problem but we still have a long way to go.
Young
Above all other issues, Ethereum is young. It has all of the problems young projects have about design, documentation, and a small community. A community we look forward to contributing to. In the next few months we’ll be discussing the issues we are having as a dapp developer on ethereum, and sharing the internal tools we develop to make it easier for people to build front end dapps like ours.
Distributed and decentralized is the way forward. We are excited about being being part of the community and look forward to sharing more updates in the near future.
