Why I’m short Ethereum (and long Bitcoin)
When it passed a market cap of $1.5 billion, both in March and in May, Ethereum became the highest valued non-bitcoin cryptocurrency ever.
The enigmatic project is no doubt the altcoin that has the most Bitcoin enthusiasts confused—or even rattled. People are wondering whether Ethereum could be Bitcoin 2.0, like Facebook versus Myspace, or VHS to Bitcoin’s Betamax.
Others have stated that Ethereum is carving out its own space entirely, calling it the oil to Bitcoin’s gold.
I don’t share either opinion. In my view, Ethereum is in direct competition with Bitcoin, and going forward it’ll most likely lose market share against it.
On March 18 I took a first ETH/BTC short position. I got stopped out, after which I suspected a double top and I initiated a new short position:
In this article I explain why I have a bearish outlook on Ethereum’s token $ETH, certainly when expressed in Bitcoin terms. I don’t claim omniscience and I of course could be wrong. Still, I think the following list gives voice to substantially under-appreciated concerns about the Ethereum cryptocurrency and ecosystem.
If after reading this article you feel inclined to also short ETH/BTC, I suggest keeping in mind the following:
- Professional traders risk less than 1% of their capital in a trade, 2% in a maximum commitment. This is also my personal rule of thumb.
- Trading positions can only be held by an exchange, which means you will be subject to (significant) risk of loss of funds in case of a hack.
- A number of smart people are ETH-bullish—I suggest studying their arguments, maybe even their direct criticism of this article.
- Even if my analysis is correct, I could still lose money on my trade: markets can stay irrational longer than we can stay solvent.
Alright, let us dive in — first with an overview of the appeal of Ethereum, then with a criticism of its main selling point: flexibility.
Ethereum’s ambition
The idea behind Ethereum is to move way past digital cash that simply registers transactions in an immutable ledger, such as is the case with Bitcoin. Ethereum’s vision is to build a Virtual Machine, a cloud based decentralized computer. Interfacing with that machine, people can then create strings of code called “smart contracts” or “decentralized applications” and publish these on the Ethereum network. In exchange for a fee, the network will then execute the code for anyone calling on it.
After Gavin Wood published his Ethereum Yellow Paper, lot of enthusiasm ensued, and programmers started discussing and developing ideas such as a decentralized airbnb, decentralized prediction markets, a decentralized gold exchange, a decentralized hedge fund, and so on. Ethereum’s programming language is simple to learn and young developers jumped on the opportunity to create decentralized applications (‘dapps’). So far there are 298 such dapps listed.
Sounds great, right? An all-in-one decentralized financial system with its own native currency, greater functionality than Bitcoin, and much easier to code applications for. Truly a ‘Bitcoin 2.0’.
However, I think there’s a catch. Having followed the project since inception, I’m concerned that a number of risks and fundamental issues are being overlooked in bootstrapping this ambitious project. I think the project at least needs to undergo a big overhaul, and at worst needs to be abandoned entirely, to prevent more intellectual and financial capital to be wasted in the pursuit of impossible goals.
(Here is probably a good place to acknowledge that I’m not a computer scientist nor even a coder. I hope to compensate for that by linking back to sufficiently technically credible sources.)
Computer network trade-offs
Imagine a network of computers, from bottom to top: the hardware, the energy needed to run the processors, the operating system, and the protocols that coordinate the data exchange. No matter which configuration you choose, there will be a trade off between cost, security, speed, and flexibility.
Bitcoin’s core protocol does everything to maximize security so that it can be used as ‘digital gold’, a decentralized store of value. Therefore it operates at a fairly high cost, while generating low speed, low flexibility transactions. Indeed, it doesn’t acquire new functionality quickly—as illustrated by the many failed colored coin projects. Now, that doesn’t mean that lower cost, higher speed, and high flexibility are impossible, but just that those things have to be built on other protocol layers on top of the Bitcoin module: layers such as the lightning network and sidechains.
Ethereum has a different approach. It prioritizes flexibility and, I argue, compromises on security, speed, and even cost .
Let’s go over each of these computer network categories one by one.
Flexibility
The Bitcoin ‘digital cash’ core protocol is a stern and barren environment. Its primary client is called Bitcoin Core, which runs on the C++ programming language. C++ is known for its precision in allocating memory and high speed, and for its steep learning curve. For constructing new transaction-commands, Bitcoin uses a scripting system: there’s a list of less than 70 precise commands that can be executed at the core protocol level. Bitcoin smart contracts have been part of the roadmap since Satoshi, and a lot of thinking has gone into the limitations required to maintain consistency with the security confines of the Nakamoto framework.
Ethereum is founded with different ambitions in mind. The Ethereum Homestead Guide, written mostly by Ethereum Foundation hired developers, states, “…unlike the Bitcoin protocol, Ethereum was designed to be adaptable and flexible.”
The way Ethereum creates this adaptability and flexibility is in four ways: radical openness, multiple implementations, multiple contract specification languages, and institutionally endorsed hard-forks.
First, the founders chose the opposite approach from Bitcoin’s scripting system by pursuing Turing Completeness; in other words, by setting absolutely no restrictions on which type of code can be published and executed on the blockchain. In the words of Vitalik Buterin, “Instead of having a protocol with lots of features, what you have is a protocol with a built in programming language, and then you can write whatever features you want on top.”
The challenge here is that flexibility comes with a large attack surface. Ethereum code published on the blockchain can contain unintentional loopholes and other vulnerabilities. If any code can be embedded in Ethereum, so can code that is intentionally designed to crash the Ethereum software. We saw this exact scenario play out on September 18, when a specific smart contract on the Ethereum blockchain caused most geth and parity client nodes to crash at once, after which the hash rate dropped by 12%. Another such attack happened a few days later, on September 22nd, followed by more recent attacks which thwarted even the “come at me bro” hotfix.
The extreme openness of the Ethereum blockchain has been disapproved by several computer scientists and developers — criticism that seems to have been validated by the recent client crashes:
Secondly, the Ethereum developers created multiple interfaces to program and publish code on the blockchain, with the following motivation:
Maintaining diversity in clients connecting to and running the Ethereum network forces the development and documentation of a cleaner protocol and enables increased robustness of the overall system: an issue with a single implementation will likely not take down the network assuming other implementations are unaffected.
Ethereum Foundation director of technology Taylor Gerring adds:
When a discrepancy occurs due to either human or computer languages, a roundtable of client developers can compare results and discuss the ramifications of a particular interpretation so as to determine a specific course of action.
Today Ethereum features clients in different programming languages. While 90% of the nodes run on Geth, the Ethereum foundation also supports a python-based client and a C++ based client as official reference clients. There are currently also six active third party implementations.
This strategy of supporting multiple implementations, rather than being a diversifying boon for the network, has been criticized as fundamentally undermining its goal of decentralized consensus:
Even Satoshi Nakamoto was critical of multiple consensus implementations:
I don’t believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network.
For an in depth look into this issue, see the write up by Aaron van Wirdum: “The Long History and Disputed Desirability of Alternative Bitcoin Implementations.” In it, Peter Todd argues that the September 18th Ethereum attack could have effectively resulted in an accidental split into two independently operating chains.
Furthermore, in a recent article, Todd argues that Ethereum’s multiple implementations do not make its network more reliable, because there exists no comprehensive protocol specification for those implementations to be based on. If we assume that geth, which recently had a 90% market share, is the de facto reference client, one could still argue that the other implementations form a serious distraction, and geth does not attract enough intellectual capital to make it an implementation that can compete with Bitcoin in terms of reliability. Gregory Maxwell points out that:
…In the last six months Bitcoin Core had 800 non-merge commits from 91 authors across 469 merges, while go-ethereum [geth] had 247 from 22 authors across 105 merges.
Based on these numbers, one could say that Bitcoin displays four times as much activity and diversification compared to Ethereum.
Furthermore, despite continuous cheers for the boons of diversification, the concerns about multiple implementations are not just theoretical musings. Ethereum’s predecessor Mastercoin also had multiple implementations, causing numerous problems and leading them eventually to revert to a single reference implementation.
It’s my view that the multiplicity of implementations, in absence of a unambiguous specification, will lead to more problems down the road.
A third way in which the Ethereum project has worked to adopt a flexible approach, is by supporting the creation of multiple contract specification languages (JS-esque Solidity, go-esque Mutan, python-esque Serpent, …).
This ‘shotgun approach’ to protocol languages has not been universally lauded. One of the more popular Ethereum languages, for example, is Solidity. It was used to construct the now infamous TheDAO smart contract, a contract from which $50 million worth of ether was stolen (4.5% of the total supply at the time). Philipp Daian, Cornell graduate student under prof. Emin Gün Sirer, had the following to say in his post mortem analysis of TheDAO hack:
I would lay at least 50% of the blame for this exploit squarely at the feet of the design of the Solidity language. …[T]he contract, even if coded using best practices and following the language documentation exactly, would have remained vulnerable to attack.
Perhaps over time more and more bugs in Solidity and the other smart contract languages of Ethereum will be fixed.
In comparison with the reinforced concrete of languages and implementations suitable for security, Ethereum’s implementations and languages are weaker and more malleable — one could compare it to straw. And of course, if you recommend entrepreneurs build houses with straw, you increase the risk of fire.
It’s important to mention that efforts are on the way to improve Ethereum smart contracts by working on better contract standards by means of formal verification. Though whether it’s possible to formally verify the Casper protocol is still unclear.
Finally, a fourth way in which Ethereum promotes adaptability and flexibility is by hard-forking the chain for security or scalability purposes.
Simply put, a hard-fork is a change to the protocol that makes upgraded nodes incompatible with nodes running the older version of the software, and vice versa.
In stark contrast to Bitcoin Core, which has never implemented such a drastic change to the code, most Ethereum developers see hard-forks as both an instrument for fixing undesirable features and acute problems with the network, as well as a legitimate tool with which to execute parts of the scalability roadmap.
Core dev Vlad Zamfir said, “I initially became a fan of protocol hard forks a long time ago, when I realized that they are a necessary part of the blockchain technology upgrade path.”
Of all its perceived sins against Satoshi’s canon, Ethereum’s pro hard-fork stance has probably garnered the most controversy — I think for good reason. Here’s a list of the criticisms against institutionally endorsed hard-forks that I agree with:
- Hard forks can result in two active, independent chains (which happened with Ethereum post TheDAO hard-fork). This introduces new security risks, political division, and consumer confusion.
- Institutional hard-forks destroy fungibility and annul settlement finality, which undermines Ethereum’s status as a blockchain-based cryptocurrency as well as the autonomy of its users. The project’s credibility has suffered too, as several key principles were violated.
- Exchanges hate dealing with the risky repercussions of hard-forks.
- Institutional hard-forks open a political can of worms, leading to (in my opinion) an unstable and inevitably unfair system of lobbying and favoritism. Take for example the ‘Buterin effect’: when following the attack on TheDAO, Vitalik Buterin did not take a clear stance against a hard fork. People began to read between the lines of his statements (much like central banker tea leaf reading) and, probably correctly, assumed that he and the Ethereum Foundation were actually in favor. Supposedly the hard-fork was a decision by ‘community consensus’, even though voting on the issue only occurred during a 12 day window, during which owners of less than 6% of the Ether in circulation actually cast a vote.
- Institutionally endorsed hard-forks introduce legal risks for the core developers, which could endanger and discourage future development efforts. By supporting the hard-fork, core devs potentially ‘prove’ that they have the power to claw back funds, or fix other (perceived) unfairness on the network. As a result, they may be held liable in court by anyone who thinks they are a victim of some injustice (victims of theft, hackers, users of the old chain, FinCEN). One legal conflict-of-interest dance may have already begun, as Buterin, who was a trustee for The DAO, bought TheDAO tokens before the hard fork and then endorsed the new post hard-fork chain which re-allocated a large amount of DAO tokens, claiming community consensus. More legal issues could ensue based on the fiduciary obligations assumed by core devs Buterin and Zamfir over the funds transferred from The DAO into a trustee-like structure, or from the white hat attack group (consisting of several prominent Ethereum Foundation members) that tried to expropriate DAO tokens from the original attacker.
- Institutionally endorsed hard-forks are an unsustainable strategy to scale in the long term. Protocols are foundational layers on top of which infrastructure is built, and as an ecosystem grows, the vested infrastructure interests favor stability over predicted security or performance gains. Buterin agrees: “…hard forks will become technologically riskier and riskier over time and at some point assuming sufficient institutional adoption they just won’t be available as an option anymore.”
In conclusion, if Ethereum is to become the transaction ledger “to securely execute a wide variety of services […] at the global level,” then its contracts and programming language need to be sufficiently robust. The question remains whether the flexibility of the network is undermining this much needed robustness. I’m afraid that it is.
In closing part 1
In the forthcoming part 2 of this article, I plan to discuss three aspects of the Ethereum network: speed, cost, and security. I’ll take a deeper look into the planned transition to a proof-of-stake protocol that uses sharding as strategy towards on-chain scalability. Meanwhile, I welcome comments and thoughts.
I’d like to thank Bryan Bishop, Christopher Allen, Pelle Braendgaard, MAbtc, and Jameson Lopp for reviewing a draft of this article. Of course, all errors remain my own.
Disclaimer: Nothing contained in this article constitutes investment, accounting, tax or legal advice or a recommendation to buy, or sell any security or other investment, management product or service or pursue any investment strategy.
Edits/corrections:
- Changed voting period on the hard-fork issue from 12 hours (source) to 12 days following comments from Vitalik Buterin.
- Removed “So can code that accidentally causes infinite loops”. It’s correct that in Ethereum infinite loops are extremely unlikely or even impossible due to the fact that writing to the blockchain costs gas.
- After consulting with a few people and studying the comments below (see also here) I decided to remove this passage: “However, that could have sweeping repercussions for existing code. As remarked during a recent meeting of Bitcoin core devs, ‘if you change something in Solidity, existing smart contracts might stop working.’ ”
Note (19 April 2017): I closed out the last tranche of this ETH/BTC short in December 2016 at around 0.008 BTC, turned out to be a profitable trade. So far I haven’t written part 2, mainly because I’ve been struggling to gather clear information about how Ethereum is going to scale. I did publish a new Ethereum article earlier this month: “I’m not worried about Bitcoin scaling, but I am losing sleep over Ethereum”.
