As of writing this post, Ethereum is trading at ~$450 USD. After soaring to $1000 back in 2018, it’s dropped as low as $83–and has now recently rallied a great amount. As news articles and a new wave of FOMO inevitably deludes the market, I thought it might be a good time to reflect and see what Ethereum might look like in an ideal world.
_Note: I won’t be talking about POS/POW. Instead, I’ll focus on the technology of Ethereum.
Crypto is an incredibly odd space–while the internet “boom” in the late 1990s and early 2000s showed quickly how useful it could be, the current system for crypto has yet to prove it’s worth. I think there are a couple reasons for this–
- Developer Tooling
- It’s really hard to create good software
- Security
- Lack of accessibility to the physical world.
Let’s look at each point individually:
Developer Tooling
This is bigger than it seems. Think about the language Go, one of the fastest growing languages right now. Sure, it was created by legendary thinkers and creators in the industry–but I’d argue one of the main attractions comes from the comprehensive tooling built around it. For example, when I first heard of it back in 2017, something simple such as gofmt was enough to grab my attention.
With Ethereum, tooling is still limited; yes, truffle suite is constantly evolving and expanding by day–but it’s still relatively frustrating to use. The commands that are used are esoteric–and unless you have some background knowledge on how blockchains work, it’s going to be hard to pick up.
It’s really hard to create good software
I think this is the biggest hurdle with Ethereum. If you’ve been in the industry for even a couple months, you should realize that writing quality software is very difficult. There are ever-changing requirements, errors nobody thought of, design choices that become tech-debt, and so much more.
Now, with that context in mind, what if I told you that smart contracts are inherently dangerous? How, you may ask? Firstly, most of the time, you’ll be dealing with actual coins; in other words, money. Second, there are vulnerabilities that you can expose by writing your smart contract. See here for some examples. Finally, a lack of human intervention when errors occur could mean catastrophic failures. Indeed, once it’s deployed, there’s no going back (you can do upgrades but the old contract will never be lost/destroyed).
Let me also briefly mention here that the vulnerabilities are also likely easily abuse-able. Why? Because the model of Ethereum demands trust. If you want others to use your smart contract, it pretty much means that you’re going to have to open-source your code. And when you do, you are under the scrutiny of, possibly, millions of attackers.
Furthermore, Solidity (the language created for Ethereum) is difficult. It’s like writing C code, but worse. The primitives provided by the language are suffocatingly limiting. To make it even harder to work with, storing data on the smart contract is extremely expensive, which means you have to find alternative methods of storing and securing your data. For those familiar with the space, IPFS is likely the logical choice, but that also comes with a steep learning curve. With so many hurdles, writing quality code becomes even harder.
Lack of accessibility to the physical world.
When I first heard of the “possibilities of Ethereum,” one of the examples I was given was tightly integrated with the physical world. I still give this example when I explain what smart contracts are–and it goes something like this:
Imagine there is a service called AirCnC. It’s a service where you can rent homes for a time. Suppose that the service has a Smart Contract where if you send the correct amount of money (specified in the smart contract), then the door to the home will open for the X number of days you wanted to rent it out for (also specified in the smart contract). Furthermore, it’s 100% guaranteed that it will behave exactly how it’s spelled out. Wouldn’t that be a fantastic? Trust is inherent and fully integrated into the core model of Ethereum. With some imagination, we can see how the world–by eliminating the need for “trust”–ironically, becomes more trustworthy.
The problem is–this is in no way feasible right now. In order for physical objects to participate, we need to use IOT devices. Yet, these IOT devices are still limited in regards to storage, network speeds, and security. Important IOT devices such as those that control locks–is guaranteed to be attacked at one point or another. Look, even Tesla, a half-a-trillion dollar company, had their cars hacked. Still, the vision of our future–one that intermingles technology and human behavior harmoniously–may hinge on things like Ethereum.
So what could it be?
Ethereum has been called the “World Computer”[1] [2] [3] countless of times. To me, the Ethereum project is working to make computing a commodity. Computing–as used in this context–is still a little ambiguous. At surface level, it’s like having computing power like EC2 available with a fee–and if you’re a participant of the network (i.e. you have a node running Eth like geth), you’re essentially recovering some part of the costs (if not all).
I think Ethereum should go a step further. Because all the smart contracts live in the chain, Ethereum, to me, is also a mono-repo. Each smart contract is like a lego-block–and you, as an “architect,” could come in and assemble the right pieces together to create a service with little coding.
Obviously, this is an ideal scenario, and the devil’s in the details. Software Engineers are still in high demand because each use-case is often, uniquely different. However, any engineer who has worked on multiple projects know that they often write the same code solving the same problem. Proponents of the mono-repo (such as engineers in Twitter and Google) cite this as one of the main benefits of having a mono-repo.
The challenge of such vision, however, is quite substantial. Firstly, even if we were to wholly subscribe to a functional programming paradigm (with things like pure-functions), I reckon the unique components needed for each project may collapse the idealistic analogy of lego-block coding. Secondly, code-discovery (like service-discovery) is a hard, unsolved problem; how do you know if the smart-contract that you need exists? How do you know it fits your use-case? Thirdly, as I mentioned previously, security is a big concern. Finally, just like open-source software, finding maintainers and incentives is difficult.
I’m still pondering on the possibilities of a world computer like such; one where coders become more like architects–and spend more time designing and building, rather than implementing.
[1] https://www.abra.com/resources/worlds-computer/
[2] https://www.coindesk.com/devcon-shows-ethereums-world-computer-is-a-movement-not-a-product
[3] https://www.coindesk.com/whats-big-idea-behind-ethereums-world-computer