Ethereum smart contracts in practice

Excerpt from chapter 10 of 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”¹

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.²

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.³ It is ill-suited and hazardous for concurrency (e.g., the Solarstorm vulnerability⁴), 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.⁵

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.⁶ (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.⁷
• 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.⁸
• Many schemes which ran out of gas due to bugs, e.g. King of the Ether.⁹
• Rubixi Ponzi: Errors in the code, copy-and-pasted from other contracts, allowed anyone to become the owner and take the money.¹⁰
• 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.¹¹ 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.

---