Ethereum smart contracts in practice

Excerpt from Attack of the 50 Foot Blockchain by David Gerard

If you suspect that spending crypto-currencies on virtual thrones for non-existent kingdoms is illegal in your jurisdiction, please avoid participating (and complain to your political representatives).

– chain-letter automatic Ponzi scheme “King of the Ether”1

For decades, smart contracts were just an interesting hypothetical. When blockchains came along, smart contract advocates were very interested in the blockchain’s immutability. There were some smart contract experiments on Bitcoin, but Ethereum was pretty much the first practical platform for writing and running computer programs on a blockchain.

Humans are bad at tasks requiring perfection. But when programming errors have drastic consequences, the usual approach is to make it harder to shoot yourself in the foot: functional programming languages, formal methods, mathematical verification of the code, don’t use a full computer language (avoid Turing completeness), and so on. Szabo wrote up some requirements and a simple example language in 2002.2

This is particularly important when you have multiple smart contracts interacting with each other – massively concurrent programming, with unknown possibly-hostile programs calling into functions of yours.

Ethereum ignores all of this. Its standard contract language, Solidity, is a procedural language based on the web programming language JavaScript – to make it as easy as possible for beginners to write their first smart contract. It contains many constructs that mislead programmers coming from JavaScript into shooting themselves in the foot.3 It is ill-suited and hazardous for concurrency (e.g., the Solarstorm vulnerability4), despite this being a specific intended use case.

There are endless guides to writing a secure smart contract for Ethereum, but most Ethereum contracts ignore them, with the obvious consequences.5

Smart contracts on Ethereum are worse than even non-financial commercial code; as of May 2016, Ethereum contracts averaged 100 obvious bugs (so obvious a machine could spot them) per 1000 lines of code.6 (For comparison, Microsoft code averages 15 bugs per 1000 lines, NASA code around 0 per 500,000 lines.)

Since cryptocurrency enthusiasts had already self-selected for gullibility, the very first smart contracts they wrote were chain letters, lotteries and automatic Ponzi schemes. These ably demonstrated the requirement for coding correctly, first time, every time:

  • The casino whose pseudorandom number generator had the random seed in the code, so anyone could recreate the precise sequence of random numbers.7
  • The GovernMental Ponzi was going to pay out 1100 ETH, but due to a coding error this required more gas than the maximum possible gas for a transaction. The ether is now stuck there forever.8
  • Many schemes which ran out of gas due to bugs, e.g. King of the Ether.9
  • Rubixi Ponzi: Errors in the code, copy-and-pasted from other contracts, allowed anyone to become the owner and take the money.10
  • A Ponzi which would pay out only to the creator of the scheme because of what looked to casual inspection of the code like a typo in a variable name.11 No doubt just an accident, I’m sure.

Automated Ponzi schemes are not nearly as fashionable in 2017; most of the effort goes into smart contracts for managing ICO tokens. However, as The DAO showed, the coding quality is as good as ever.


1 King of the Ether: “An Ethereum contract, living on the blockchain, that will make you a King or Queen, might grant you riches, and will immortalize your name.”

2 Nick Szabo. “A Formal Language for Analyzing Contracts”. 2002. (archive)

3 Nicola Atzei, Massimo Bartoletti, Tiziana Cimoli. “A survey of attacks on Ethereum smart contracts”. 6th International Conference on Principles of Security and Trust (POST), European Joint Conferences on Theory and Practice of Software, April 2017.

5 Zikai Alex Wen and Andrew Miller. “Scanning Live Ethereum Contracts for the ‘Unchecked-Send’ Bug”. Hacking Distributed (blog), 16 June 2016. “Upon inspection, not one of the Solidity programs that passed our heuristic check actually applied the recommended best-practice of testing the callstack directly.”

6 Peter Vessenes. “Ethereum Contracts Are Going To Be Candy For Hackers”. Blockchain, Bitcoin and Business (blog), 18 May 2016.

7 Martin Holst Swende. “Ethereum contract security: An Ethereum Roulette.” Blog post, 14 August 2015.

10 “Hi! My name is Rubixi. I’m a new Ethereum Doubler. Now my new home – Rubixi.tk”. Bitcointalk.org Bitcoin Forum > Alternate cryptocurrencies > Marketplace (Altcoins) > Service Announcements (Altcoins), 11 April 2016.

11 Vitalik Buterin. “Live example of ‘underhanded solidity’ coding on mainnet”. Reddit /r/ethereum, 10 April 2016.