After the collapse of the Ethereum project known as The DAO, many critics of the smart contract platform have basically said, “I told you so,” and bragged about how this would be the inevitable result of a blockchain that is not as limited (for security reasons) as Bitcoin. Although the ether price recently dipped below the $10 mark, the platform is not dead; there are still plenty of believers.
Having said that, this is definitely a time when the Ethereum community should take a look at what they’re doing and perhaps change their strategy. While the idea of allowing anyone to code up a smart contract and deploy it on the public Ethereum blockchain may sound enticing, it’s possible that these sorts of hard-coded financial contracts may be best left to the experts.
Was the Disaster with The DAO Inevitable?
Back in January, Blockstream Testing Engineer Jonas Nick pointed out a flaw in an example contract found in the documentation for Solidity (a programming language for Ethereum) that would allow an attacker to steal coins from the contract. This underlines the difficulties associated with making sure these sorts of smart contracts are safe and secure. Once a contract is deployed on the network, those who lose money via the contract have no recourse for getting their funds back -- at least in theory.
“I spent a few hours looking for bugs in The DAO because I thought it was inevitable that they exist,” Nick told CoinGecko when reached for comment on The DAO. “Turing completeness is only one of the red flags. Solidity and the Ethereum Virtual Machine are not built using proven technologies, a proper tool chain for debugging and testing is non-existent, and Ethereum is being advertised as a framework to easily write software handling significant value. However, as we see doing that still requires a significant investment.”
In terms of why The DAO failed, RSK Labs Co-Founder and Chief Scientist Sergio Lerner sees issues at multiple levels. “The fact that the Ethereum consensus layer runs a Turing-complete procedural virtual machine (VM) means that the blockchain is able to support different kinds of programming languages and compilers, both functional and procedural,” he told CoinGecko. “I think that the root cause of the DAO theft was immaturity in several layers: the Solidity compiler, the DAO creators, and the DAO investors. But [there’s] less responsibility at the VM level.”
“The VM is not really Turing complete, as there is a limitation on the number of steps the program can run based on the gas limit of each block,” Lerner added.
Although there is some disagreement among security experts in regards to what ultimately led to The DAO’s failure, there appears to be consensus that it was a combination of an inappropriate programming language for smart contracts, a lack of code auditing, and naivety from speculators.
Should Every Developer Be Writing Smart Contracts?
One of the key issues with smart contracts is that they need to be provably secure before hundreds of millions of dollars can be dumped into them. Blockstream Principal Architect Christopher Allen, who also co-authored the TLS standard, does not believe the average programmer will be able to develop secure smart contracts in the near future. “If the goal is to enable relatively entry-level, Javascript-level engineers to write secure code, I am very skeptical that we’ll be able to offer that for some time,” he told CoinGecko. “Instead, we need better tools to make it easier for sophisticated engineers to identify problems earlier.”
Sergio Lerner is also sympathetic to the concept of slowing down the deployment of a newly created smart contracts that store large amounts of value. “Ethereum is presented to the public as a revolutionary platform for trustless decentralization experiments,” he stated. “So as long at these are experiments, sure, every programmer should try it. But Ethereum's web page doesn't say anything about serious financial applications, and [has] almost no content about smart contract security. So I think the Ethereum philosophy must change if the platform will serve real world financial use cases.”
Cornell Professor Emin Gün Sirer, who researches distributed systems like Ethereum, takes a different point of view. “I very much support languages that make it ‘easy’ to write smart contracts,” he said when reached for comment. “The way to achieve security and robustness in smart contracts is not to use arcane languages to weed out the aspiring developers. We will get there by educating the developer community, not by weeding people out. We should push the agenda even further in the other direction: We should train everyone to the level where they can write trustworthy smart contracts. It'd improve our regular software!”
Due to the focus on developing a solution to the issues related to The DAO, it’s unclear if the Ethereum community plans to take a different approach to smart contracts in the future. Some critics view a potential hard fork that would “bail out” holders of DAO tokens as a moral hazard, which means the community will not be able to learn from its mistakes and avoid these sorts of unverified, insecure smart contracts in the future.
Bitcoin vs Ethereum on Smart Contract Philosophy
At this point in time, it’s unclear where the correct balance is when it comes to the development of smart contracts. On the one hand, developers want the freedom to develop whatever they want to develop right now. On the other hand, the Bitcoin development community’s slow and steady pace of adding new opcodes has helped them avoid serious flaws at the protocol level for some years now. Developers of smart contract platforms will need to find a sweet spot between allowing innovation to take place while also making sure that strict security standards are maintained.
“Blockstream is committed to very cautious, prudent additions of additional opcodes to Bitcoin Script-style smart contracts, through the open source Elements Project,” said Christopher Allen. “Some of the opcodes were tested as Elements Project sidechains, then approved by the Bitcoin community for try out in the Bitcoin testnet, and then approved by soft fork for use by the entire Bitcoin community.”
“This process can take years,” Allen continued. “For instance, a single opcode, Peter Todd’s OP_CHECKLOCKTIMEVERIFY, was discussed in 2013, became a BIP in 2014, was peer-reviewed, implemented and tested over 2015, and approved on November 13, 2015 (Peter often points out he has given more interviews about that opcode than there are lines of code in the implementation).”
OP_CHECKSEQUENCEVERIFY, an opcode that holds great importance for the Lightning Network, was also just activated on Monday.
Allen recently co-authored a paper with Shannon Appelcline about specific improvements for smart signature systems. In the paper, Segregated Witness is mentioned as an improvement that makes it easier to implement new opcodes on Bitcoin’s mainnet, and sidechains are mentioned as a solution for testing new opcodes in an environment separate from the main Bitcoin blockchain. In this sense, it’s kind of like the Bitcoin development community is slowing adding new smart contract capabilities rather than allowing any developer to code a contract up and release it to the world.
If smart contracts are controlled by code and not societal forces, then they must be made secure from the start. Bitcoin, Ethereum, and Rootstock are taking different approaches to the concept of smart contracts, and we’ll have to see what works best for developers and speculators over the long run. For now, the most widely-used smart contract on an immutable ledger is still a simple Bitcoin transaction.
Kyle Torpey
Kyle is a freelance writer who has been interested in bitcoin since 2011. His work has been featured on Business Insider, VICE Motherboard, Let's Talk Bitcoin, RT's Keiser Report, and many other media outlets. Follow the author on Twitter @kyletorpey
