[DennisP]

As the article briefly suggests, this problem can be completely avoided if every method has no more than one external call and always puts it last.

I'm messing around with contracts to do about a dozen different things, and it turns out to be easy to meet this restriction, as long as I'm willing to design the UI accordingly. (E.g. don't send money to lots of users in one step, just update their balances and make them call a withdraw function.)

[cheeze]

It seems like there are quite a few pitfalls to avoid just in writing these contracts, and they aren't obvious things in many cases. This seems incredibly dangerous, given what is at stake when a bug is included in a contract.

Is there any form of auditing that contracts can go through to not have these pitfalls?

I wonder how many of them are still undiscovered...

[DennisP]

There's both an active developer community willing to help for free, and professional auditors you can pay. There are also people talking about a NASA-style bugs/best practices database at some central location.

People are realizing that this needs to be developed like safety-critical software, not like fast-moving startup websites. But I would say it's not as scary as, say, developing software for aerospace or medical applications.

And what really helps is that you can do a lot with very little code. I think all of my contracts are under five pages. I don't think we're ready for big complicated contracts, but there's a lot we can do with simple little contracts.

[tylervigen]

In case anyone hasn't read it, the NASA coding process is extremely interesting: http://www.fastcompany.com/28121/they-write-right-stuff

[sandworm101]

Five pages? I thought these things were meant to be shorter than plain-English contracts. I draft and review contracts daily and five pages is long for basic things (employment, NDAs, IP transfer etc).

[DennisP]

It's software, not really comparable to an English-language contract. Most software is much bigger than that.

Five pages is an outside estimate, for something like a currency exchange. My crowdfunding contract is about two pages, and the vault is one.

[dragonwriter]

> It's software, not really comparable to an English-language contract.

If the point is to be an alternative to normal, "dumb" contracts, than that is exactly what it needs to be comparable to.

[sandworm101]

He is correct in stating that it is code v. english, apples v. oranges. But I was under the impression that the whole point of using code was to explain something in more concrete and definitive terms. If doing so takes more words, more abstract word, with more oppertunity for bugs and loopholes, then what is the point?

[DennisP]

Smart contracts are not an alternative for things like employment, NDAs, and IP transfer. But how long would your contract be if you were setting up a currency exchange?

And how much software would you have to write in addition to that? On Ethereum the back-end software and the "contract" are the same thing, since the software enforces the terms.

[aminok]

Natural languages like English imply much more through context, and trade precision for succinctness. This is less true for legalese but still the case. Computer programs need to be explicitly defined and precise because there is no intelligent interpretation.

[reddytowns]

  Yes,
    but,
      English
        is 
          not 
            commonly
            written

      with
        conventional 
        programming
        whitespace and indentation  
          practices.

[DennisP]

Just for fun I took one of my longest contracts, removed all the line breaks and added word wrap, and it came to a page and a half.

[jarsin]

> I wonder how many of them are still undiscovered...

Yup. I find it interesting how everyone only thinks it's these couple of issues. I wouldn't do anything beyond experiments with it at this point.

[bradenb]

It would be nice if you could dry-run each execution of the contract and verify it passes a series of tests. It seems to me that regardless of how these contracts are written, you should be able to verify the behavior.

[jcoffland]

That's what the test net is for.

[jsprogrammer]

I have asked if there is a contract simulator and I got no response.

Even though the coding experience seems pretty poor, it doesn't appear to be particularly dangerous as bad contracts can just be rolled back.

[bradscarleton]

There is no contract simulator AFAIK, but you can deploy contracts to a test network or your own private test network. The benefit there being it's cheaper from a Gas perspective, and you don't pollute the main network.

[DennisP]

Aside from running on a test chain there's the Mix IDE, which basically does have a simulator, and an actual debugger. So far it's kinda unstable and tends to crash, but I like it a lot anyway.

[axlee]

If this code style is an absolute requirement for the code not to be exploited, it should be probably be built-in in the language specification itself.

[happyslobro]

Or at least, we should have a linter, and strongly encourage it's use. Maybe make a rule of disclosing linter warnings when presenting contracts.

[jude-]

> this problem can be completely avoided if every method has no more than one external call and always puts it last.

Actually, it's a bit more nuanced than that. If you have methods that make external calls--even if it's the last thing they do--you still have to ensure that all your externally-callable methods do not share state with the methods that make external calls. Restricting where and how often you do your external calls isn't sufficient, since that last external call at the end of your method can turn around and call other methods in your contract (which can alter the contract's state, if you're not careful).

EDIT: clarification

[wyager]

Patchwork solutions won't cut it. "Solidity" is inherently unsuited for the task of safe and correct contract design.

[happyslobro]

This looks like an ideal use case for a Haskel based DSL. We need good static analysis capabilities, and we have to carefully manage side effects.

[chc]

I'm not sure Haskell's type system is sophisticated enough to be relied on to prevent the kinds of problems The DAO ran into. As I understand it, one of the bugs boils down to recursive calls between two side-effecting functions, which seems like it would probably be just as possible in a parallel-universe Ethereum based on Haskell.

[splintercell]

Check ou this paper

http://publications.lib.chalmers.se/records/fulltext/234939/...

[happyslobro]

Hmm, so the DSL needs to enforce some kind of contract and limit scheme, like that Ada dialect that the aerospace guys occasionally bring up. I bet they have decades of research that the next DAO project devs should familiarise themselves with.

[baby]

What's your setup to mess around with contracts?