Reviewing Ethereum Smart Contracts

I saw this on Twitter today:

Cyber security is a nightmare.

Crypto asset security is a 10X nightmare.

Smart contract security is a 100X nightmare.

https://twitter.com/lopp/status/911020364829884416

Is this a joke? An ICO which pretends to do security auditing for other ICOs (why do you need your own cryptocurrency for that other than as a quick cash grab)?

Imagine if Windows 95 stored your payment data and was bridge-connected to the internet. This will give you an idea of how I look at these smart contracts.

Is there any reason to think of it another way?

It remains a complete embarrassment that Ethereum is based on a home-grown trainwreck of a programming language instead of one of the existing well-supported, battle-tested verifiable programming languages out there. Honestly, they could have used C and been better off because of the amount of C verification tools out there - Solidity hardly seems safer than C and its compiler has a history of potentially catastrophic newbie mistakes [1]. Note that some of these bugs are in an optimizer, something a security-focused package handling money shouldn't even need, especially if it risks compromising correctness of the contracts.

People talk about Solidity being JS-inspired, but simply using JS would have also been better, because there is verification tooling out there for it, along with compression tooling to make it smaller. And people can use higher-level to-JS compilers like Typescript to get stronger safety assurances if they wish.

Any claims that performance justifies the use of a home-grown language are also absurd: High-performance trading firms like Jane Street make use of verifiable functional programming languages like OCaml despite the importance of speed & latency in order to turn a profit. [2]

No amount of effort from security researchers is going to completely compensate for the fact that the people running Ethereum have incredibly bad taste and make poor decisions. I remain concerned for people who put their wealth at risk investing in smart contracts because the average contract probably has unnoticed issues.

[1] http://solidity.readthedocs.io/en/develop/bugs.html

[2] https://www.janestreet.com/technology/

You're accepting the assumption/abstraction made by Ethereum here, where "gas" is equivalent to performance, even though gas is an arbitrary measurement. You could easily build your own gas-focused optimizer for a toolchain like llvm or for a compiler like ocaml's.

Ethereum could bill contracts based on the actual cycle count they take to execute on the CPU, or some other metric. Then you wouldn't need to use a specialized bytecode designed for the gas system with its own optimizer. Of course, then people would potentially be tuning for the most common CPUs (or ASICs, or whatever) used by miners. But again, it's not necessary to roll your own solution.

Consider also whether gas makes any sense in the long run: Compute power continues to increase, and the cost of compute power continues to drop. If smart contracts are really going to be the foundation of a new economy and people are going to build applications on top of them, does gas make that much sense vs billing for actual compute and network resources like AWS or EC2? Is gas even a meaningful abstraction? I'd argue it isn't. If the 'value' of executing contracts in $/gas exceeds the cost of renting AWS/EC2 nodes you're basically created a market for mining arbitrage, and perverse incentives where those miners want to push the prices in one direction.

Event-oriented programming is old hat in every modern programming language. C/C++ have plenty of frameworks out there you can use to get at it, so do other languages. In some environments it's the de-facto way to write code.

Alternate frontends for the EVM potentially address some issues - which is great - but it doesn't get around the fact that EVM itself is poorly designed, and this is reflected in the system all the way from top to bottom. Some of the errata in the post I linked earlier were ways to exploit design flaws in both the VM and compiler to manipulate contracts, and instead of fixing that in the VM they make you put checking prologues in your functions :/