
Reviewing Ethereum Smart Contracts - notverysecure
https://blog.gdssecurity.com/labs/2017/9/27/reviewing-ethereum-smart-contracts.html
======
krupan
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](https://twitter.com/lopp/status/911020364829884416)

~~~
616c
But if pioneers do not grind their teeth on real world implementation,
application, and hardening how do you expect those scales to change? Was it
better when even US mil branches roamed the public internet and people dialed
in with naive attacks?

I applaud these developers like those who died exploring countries unknown,
minus the raping and pillaging and colonizing (not ironic; I just know people
on HN will call me out if not clear preemptively).

------
kevingadd
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](http://solidity.readthedocs.io/en/develop/bugs.html)

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

~~~
zeroxfe
Whoa there! Sure Ethereum has it's problems, but going as far as "the people
running Ethereum have incredibly bad taste and make poor decisions", displays
a huge amount of ignorance towards some incredible engineers who have built a
fantastic (and very successful) platform.

Ethereum is far more than just the contract language -- it's the distributed
consensus system, the merkle-tree backed blockchain, the p2p network, the
cryptographic transaction ledger, the virtual machine, and much more. It is
way more complex and sophisticated than you're giving it credit for.

There have been multiple languages to target the EVM, and they're been getting
incrementally better, and will continue to evolve rapidly as more PL experts
have gotten involved.

So for all the things they've got wrong, they've got lots more right -- and
it's only been a bit over two years since the initial release. Give them a
break!

~~~
UncleMeat
The EVM itself is fucked, not just Solidity. It has poorly defined semantics
and has a number of strange behaviors that you don't want in high integrity
systems.

~~~
DennisP
For example?

~~~
UncleMeat
Exception semantics are unclear, requiring explicit checks only in some cases
depending on how a function is called.

------
wruza
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?

~~~
DennisP
Yes: smart contracts are extremely short programs, usually doing very simple
things. A thousand lines is a fairly large contract. It's feasible to spend a
lot of time refactoring to make them as simple and clear as possible, to unit
test extensively, and then pay several expert parties to review them in
detail.

We're not quite at the point of being able to do formal proofs of their
properties, but that's on the way, and also relatively practical given how
short the contracts are.

We can see whether contract authors have done these things because unlike
Win95, smart contract source code is always published, since everyone knows a
closed-source contract could trivially steal their money.

~~~
dogma1138
Smart contracts are not that short, and if you look at entries for the
Unhardended Solidty Code contest you'll discover just how easy it is to
implement a vulnerability due to the nuances of Solidity and the runtime.

The virtual machine is also not even remotely proven yet.

There is a lot of risk.

~~~
DennisP
I write and audit Ethereum smart contracts for a living. Most of the projects
I work on aren't much bigger than a thousand lines, and many are less. Some
especially large projects are several thousand lines, still many orders of
magnitude smaller than Win95.

