
Ethereum Contracts Are Going to Be Candy for Hackers - vessenes
http://vessenes.com/ethereum-contracts-are-going-to-be-candy-for-hackers/
======
kneel
Running a machine on a blockchain (Ethereum) is much more complex and error
prone then recording transactions on a blockchain (bitcoin)

The Ethereum virtual machine has to be completely error free if any sane
person is going to put their money into it. I just don't see that happening.

I do see a lot of glitzy websites using blockchain buzzwords, but there isn't
much going on besides fundraising. This should be a concern for anyone
speculating on Ethereum.

~~~
fragsworth
> The Ethereum virtual machine has to be completely error free if any sane
> person is going to put their money into it. I just don't see that happening.

Your fear seems to stem from misunderstanding how Ethereum works or what it
even is.

Most likely, Ethereum itself (the "engine") will be effectively error-free -
probably as good as the Linux kernel - once it reaches 1.0. And smart
contracts can be as simple or complex as you like. If you're afraid of bugs,
don't put money into any complex smart contracts. If there's a lot of money
involved, then spend some money/time reviewing the smart contract.

Also, contracts can set precedent once they are in the ecosystem. If a
contract has been heavily used prior to your desire to use it, you can copy
it, and be relatively confident that it will be secure for you to use.

~~~
voidlogic
>Most likely, Ethereum itself (the "engine") will be effectively error-free -
probably as good as the Linux kernel - once it reaches 1.0.

"will be effectively error-free" != "probably as good as the Linux kernel",
not even close :D

~~~
aab0
The security history of the JVM suggests that one shouldn't be optimistic
there either.

~~~
rtpg
counterpoint: I haven't really heard of any "javascript escaping the
container" bugs in a really long time (excepting node.js-related issues)

~~~
astrodust
JavaScript has several mature, thoroughly scrutinized implementations.
Ethereum has one brand new implementation.

To put it mildly: There will be blood.

~~~
danfinlay
There are actually eight different implementations at this time, although the
go client has a slight majority of users according to ethstats.net

[http://ethdocs.org/en/latest/ethereum-
clients/index.html](http://ethdocs.org/en/latest/ethereum-clients/index.html)

------
harwoodleon
I went to a talk with Vitalik Buterin recently where he stated code quality
was one of ethereum's biggest threats.

But, there is a market for code quality review too now!

Trustless contracts must at least be audited or they will have no ultimate
credibility.

Just because something carries a risk, that is no reason not to adopt it, even
try to fix it.

If the authors main point about code quality error rates is the main point,
NASA has had far more time and funding and it would not be outputting random /
get rich quick games either.

Ethereum has issues, but it is young and has a fantastic support base of
enthusiasts.

The original author should have done more research on the roadmap for smart
contracts and ethereum.

~~~
vessenes
I'm the author, and I agree with Vitalik. I thought it was interesting to dig
into the wild west of live contracts and see what was happening right now.

The early days of Bitcoin had many of these same business models, although
with much worse security and trust models.

Getting security and secure practices together is going to be a large effort,
and a simple post like mine is just a way of throwing my hat in the ring and
getting some conversation going.

------
yarrel
Article is much better than headline, including a case study and constructive
proposals.

~~~
vessenes
Thanks! The headline did have a bit of a buzzfeed quality on reflection.

------
joosters
The much-hyped 'DAO' that has crowd-funded over $100 million dollars worth of
ether, is based upon one of the largest contract code seen so far. Even if it
has been code reviewed, it's almost certain that bugs remain in there. All it
takes is one hacker to find a flaw and $100 million will be gone in an instant

~~~
rtpg
is there an easy-to-look-at link to the code?

~~~
vessenes
Yes!

Most Ethereum contracts aimed at public consumption are published at ethereum
chain viewers. I like etherscan: this is the DAO's contract
[https://etherscan.io/address/0xbb9bc244d798123fde783fcc1c72d...](https://etherscan.io/address/0xbb9bc244d798123fde783fcc1c72d3bb8c189413#code)

------
dmix
Don't these contracts existing in a market? If one contract is flawed won't
customers flock to another competing one? This would create an incentive for
quality control.

Or is the proposed problem that these flaws are unavoidable or too costly to
prevent? I could see the high-investment cost being a deterrent for developers
to adopt the platform. In general the contract code should be as simple as
possible and memory safe.

Either way, the sample reference in the article is not very useful. This is a
bad time to be looking for quality as this is extremely early and very much in
the experimental stage of the idea. It will, of course, deserve scrutiny when
it gets more mature though.

~~~
vessenes
From my review of some of these contracts, even fairly obvious flaws are not
being exploited (yet).

So, flaws will become known, and presumably there will be ratings and trust
ratings and so on eventually. In the interim, though, some of the flawed
contracts moved well over $100k in their first week of existence. That seems
worth paying attention to.

I would propose flaws like these are unavoidable, unless you can pay what NASA
paid. And remediation techniques should be developed urgently, not at some
later date.

~~~
Bromskloss
What are the fairly obvious flaws?

~~~
vessenes
Check out some contracts and see for yourself!

------
numlocked
The author talks about a mechanism for replacing parts of a script (e.g.
maintaining it in production in spite of the 'forever' longevity of a
contract). The Truffle Ethereum development framework has such a proposal in
the works -- a simple 'migration' mechanism that will allow in-place upgrades
of running contracts:

[https://github.com/ConsenSys/truffle/issues/138](https://github.com/ConsenSys/truffle/issues/138)

------
zby
I used to think that these problems would kill ETH - but after reading this I
am changing my mind. This will be a hell of a game for hackers! Like Core Wars
for money.

------
swordswinger12
The IC3 research group at Cornell, and especially Elaine Shi's group, has been
thinking about this recently. They are (I think) working on some kind of
program analysis framework using deep PL techniques to formally verify smart
contracts.

~~~
pipermerriam
There is actually already fledgling support for this in Solidity (the
prevailing language that Ethereum developers use to write smart contracts).

[https://forum.ethereum.org/discussion/3779/formal-
verificati...](https://forum.ethereum.org/discussion/3779/formal-verification-
for-solidity-contracts)

------
j1vms
If Ethereum or something like it were to succeed, it would end up taking the
form of low-level plumbing for financial products or other stuff which will
simply say: "built on the Ethereum trustless/blockchain system". And as others
here point out, there would be an ecosystem with companies which would audit
and rate smart contracts for trustworthiness by an end-user. That in itself
might end up being another application of Ethereum. Again, emphasis on the
aforementioned _if_.

------
davidgerard
Smart contracts should be thought of as "the Underhanded C Contest on the
blockchain."

------
eggy
>>industry average bugs per 1000 lines of code at 15-50 and Microsoft released
code at 0.5 per 1000, and 0(!) defects in 500,000 lines of code for NASA

Does anybody know how useful this metric is?

I have read NASA uses C, C++, Java and Ada, of which the last three have a lot
boilerplate. Heavily commented C can be verbose too. I realize there is
probably a lot of review, commenting and redundancy built-in, and that adds to
the overall LOC too.

An MS bug might mean Excel crashes, or a bad business decision is made, unless
somebody is using MS software for more critical end points. With NASA, it can
be guidance systems, and other low-level routines running in radiation-
hardened electronics.

Rosetta lander used Forth onboard, so there were probably a lot fewer LOC to
make mistakes in. Just one way to approach bug-free programming vs. ADA's or
Java's verbosity and checks.

I write J code, so one error usually amounts to 1 in 5 or 10 LOC ;) But then
again, I can see all my code in one glance, and I program iteratively in the
REPL.

~~~
vessenes
I had the same difficulty looking at the code. Do we count import lines and
variable defs? Seems sort of lame.

J of course has a different problem; only a handful of people can even parse
it, much less opine on correctness.

~~~
eggy
Handful is a bit extreme ;) But seriously, it is easy to troubleshoot due to
the interative nature of development in the REPL, the similiarity with
mathematical formula and their layout. A PhD student wrote his thesis in 2008
about parallelization, FPGAs, ASICS and arrays, and was fully intending to
write it in J, but his advisor suggested something more known, so he wrote it
in Haskell. I'll put in the reference when I find it.

There is a table in the paper that shows the math formula, the Haskell and
then J. Pretty interesting comparison.

To me, if you are not using a prover, then it is mainly going over 10K LOC 1
to 3 times vs. 100 LOC 10 times, 30K LOC reviewed vs. 1K LOC reviewed for
errors and correctness.

~~~
c2340596
"it is easy to troubleshoot due to the interactive nature" isn't going to cut
it. You cannot change the code of an etherum contract after the fact. Once
it's used there is no second chance.

~~~
eggy
Thanks for bringing it back to the OP's topic, but I was specifically
addressing the quote the OP made about number of errors per LOC tally. I was
pointing out how it could be weak metric, since the languages used in the
examples might contain many LOC of template boilerplate that would make for a
low bug:LOC off the bat.

An ADA hello world is 5 LOC vs. 1 for a lot of other languages.

Java is not too different.

J and Python are 1 LOC, and typically not template text, but originally coded.

~~~
SkyMarshal
I'm ok with boilerplate when it buys you something useful, like readability,
explicitness, and security, as in Ada.

------
pessimizer
Don't lawyers do this to real-life contracts?

~~~
jerf
First, let me acknowledge that this is a fair question. A bit cynical,
perhaps, but fair.

To answer it, no, not like this. Contract law has a lot of humans in it. You
are certainly able to sign some contracts with combinations of clauses that
can get you, and I've read horror stories at the mega-corp levels about
contract clauses interacting unexpectedly and screwing some party or other.
But even in those cases, the way they got screwed was by a collection of
individually-sensible clauses.

A computer running a contract is by contrast blitheringly stupid. If you write
a logic error into your contract that lets a participant suddenly claim all
the contracted value by simply, say, sending a bid of 0 as many times as there
are participants or something, there's nobody and nothing that will prevent
that. If you try that in a human contract, it will be invalidated by some
human judge.

Sure, lawyers may write complicated contracts in an attempt to screw the other
signatory and they may play complicated games with the clauses, but running
contracts as otherwise-unsupervised programs is a whole new level.

Furthermore, just having had a quick scan over the language documentation, it
looks to me like a bog-standard imperative mutable language. One that is very
young, and with few if any features designed for being used in a high-security
environment. It appears to be based on raw event-based programming, a style of
programming very easy to mess up and hard to declare and preserve invariants
in. It looks like a very dangerous programming language to be trying to write
financial contracts in. At least it's not dynamically typed, does seem to
avoid excessive coercion, and should be memory safe; it could certainly be
worse. But it could be better, too.

~~~
Bromskloss
I'd love to hear more about those horror stories you mention.

~~~
a3camero
"The dispute between Rogers Communications of Toronto, Canada’s largest cable
television provider, and a telephone company in Atlantic Canada, Bell Aliant,
is over the phone company’s attempt to cancel a contract governing Rogers’ use
of telephone poles. But the argument turns on a single comma in the 14-page
contract. The answer is worth 1 million Canadian dollars ($888,000).

Citing the “rules of punctuation,” Canada’s telecommunications regulator
recently ruled that the comma allowed Bell Aliant to end its five-year
agreement with Rogers at any time with notice."

Read more:
[http://www.nytimes.com/2006/10/25/business/worldbusiness/25c...](http://www.nytimes.com/2006/10/25/business/worldbusiness/25comma.html)

~~~
vanattab
quote from the linked nytimes article " The dispute is over this sentence:
“This agreement shall be effective from the date it is made and shall continue
in force for a period of five (5) years from the date it is made, and
thereafter for successive five (5) year terms, unless and until terminated by
one year prior notice in writing by either party.”

The regulator concluded that the second comma meant that the part of the
sentence describing the one-year notice for cancellation applied to both the
five-year term as well as its renewal. Therefore, the regulator found, the
phone company could escape the contract after as little as one year. "

------
ChemicalWarfare
I don't know much about Ethereum so I might be way off here.

From what I understand though:

1\. The contract you deploy to the blockchain is tied to your account where it
gets the funds (ether/gas in Ethereum's lingo) to pay for its existence. So if
those funds aren't there - the contract is 'dead' ;

2\. There are ways to use Ethereum's registrar metadata to use contract's
'name' that isn't hardwired to the implementation so you can change the
implementation behind the scenes. You can also have an intermediate contract
whose only purpose is to proxy requests to the more involved contract so you
can update your 'backend' at will.

~~~
vessenes
1) Well, contracts have balances, true. The people calling the contracts pay
for it to run, so the dead terminology is at best imprecise. If the contract
pays out 10 ether in .01 ether increments, and never takes any in, then it
will be dead once depleted. On the other hand, people calling the contract pay
for the cycles to run it, so one wouldn't typically go dead in that way.

2) I'm not an expert on the registrar situation by any means. But, I do not
believe that updating a registrar pointer changes the balances at each
contract (the old and new), so while it may be useful for some cases, those
which involve balances may be more troublesome if you haven't thought ahead.

~~~
ChemicalWarfare
the 2nd point was to address the fact that the contract can be updated/patched
with little if any impact to it's end users. so the new version of the
contract gets pushed out, the old one is not in use any longer and just kind
of dies off :)

~~~
vessenes
Right, but for a ponzi scheme contract, that's not a great outcome. Or, say, a
crypto-currency, one of the sample apps in Ethereum documentation.

Either way, you have a trust problem -- who shall be trusted to transfer out
all the value the contract holds?

~~~
ChemicalWarfare
I would imagine that would be something the contract identifies explicitly
along the lines of Bitcoin multisig.

~~~
vessenes
That's one conversation I'm hoping to get launched soon. The sample 'make your
own digital currency' code from Ethereum has no such provisions right now.

To my mind, it's a little like K&R C showing you how to walk through a string
in the 1980s -- adversarial data was not a big concern at the time.

------
0x0
This is pretty interesting. So I guess there's a huge opportunity here for
grey/black-hatted people to analyse contracts and transactions and spot flaws?
Apparently even bitcoin has weaknesses like these, with non-standard
transaction scripts that may be easily solvable/stealable for anyone with a
bit of insight

~~~
gus_massa
In Bitcoin, almost all the people use the same script, so it's enough to
review it. (I think the only problem is a small malleability.) And when a big
problem is discovered almost all the people will change in a short time.

In Ethereum is more encourage to write smart weird custom contracts, so many
people write a custom contract with only one pair of eyes to review it, so
it's more probable to find errors.

~~~
0x0
For sure, but I think there's opportunity/vulnerability in bitcoin too. From
the top of my mind I recall reading about people grabbing coins quickly from:
bad random number generators in at least android, brainwallets/rainbow-tabley
private keys, non-standard script for fun or error to the tune of having to
solve "2+2"

A little similar to how bad guys hook onto github feeds and instantly exploit
leaked aws keys etc

~~~
codehalo
Those a problems with wallets, not bitcoin.

------
woah
The article is kind of oversold. He starts out by talking about how there's an
impending apocalypse of vulnerable contracts, but then the example is a
contract that was clearly written as something between hello world and a joke.

------
wickedlogic
Seems like a problem solved with traditional simulation tools.

------
Rauchg
ICYMI: Bitcoin will gain Turing-completeness via a merge-mined sidechain
called Rootstock ([http://www.rootstock.io/](http://www.rootstock.io/)), that
also offers a transaction throughput boost (300TPS right off the bat).

I highly recommend their whitepaper as it's also a great overview of the
Blockchain ecosystem as a whole.

~~~
woah
From reading their site, it sounds like you expose yourself to massive
counterparty risk using this, as a "federation" is holding your bitcoins.

