{"id":37,"date":"2017-04-22T14:46:37","date_gmt":"2017-04-22T14:46:37","guid":{"rendered":"https:\/\/davidgerard.co.uk\/blockchain\/?page_id=37"},"modified":"2017-11-18T16:45:18","modified_gmt":"2017-11-18T16:45:18","slug":"ethereum-smart-contracts-in-practice","status":"publish","type":"page","link":"https:\/\/davidgerard.co.uk\/blockchain\/ethereum-smart-contracts-in-practice\/","title":{"rendered":"Ethereum smart contracts in practice"},"content":{"rendered":"

Excerpt from chapter 10<\/a> of Attack of the 50 Foot Blockchain<\/a> by David Gerard<\/i><\/p>\n

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).<\/p>\n

\u2013 chain-letter automatic Ponzi scheme \u201cKing of the Ether\u201d1<\/sup><\/a><\/p>\n<\/blockquote>\n

For decades, smart contracts were just an interesting hypothetical. When blockchains came along, smart contract advocates were very interested in the blockchain\u2019s 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.<\/p>\n

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\u2019t use a full computer language (avoid Turing completeness), and so on. Szabo wrote up some requirements and a simple example language in 2002.2<\/sup><\/a><\/p>\n

This is particularly important when you have multiple smart contracts interacting with each other \u2013 massively concurrent programming, with unknown possibly-hostile programs calling into functions of yours.<\/p>\n

Ethereum ignores all of this. Its standard contract language, Solidity, is a procedural language based on the web programming language JavaScript \u2013 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<\/sup><\/a> It is ill-suited and hazardous for concurrency (e.g.<\/i>, the Solarstorm vulnerability4<\/sup><\/a>), despite this being a specific intended use case.<\/p>\n

There are endless guides to writing a secure smart contract for Ethereum, but most<\/i> Ethereum contracts ignore them, with the obvious consequences.5<\/sup><\/a><\/p>\n

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<\/sup><\/a> (For comparison, Microsoft code averages 15 bugs per 1000 lines, NASA code around 0 per 500,000 lines.)<\/p>\n

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:<\/p>\n