Hacker News new | ask | show | jobs
by cheeze 3655 days ago
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...

4 comments

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.

In case anyone hasn't read it, the NASA coding process is extremely interesting: http://www.fastcompany.com/28121/they-write-right-stuff
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).
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.

> 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.

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

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.

  Yes,
    but,
      English
        is 
          not 
            commonly
            written

      with
        conventional 
        programming
        whitespace and indentation  
          practices.
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.
> 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.

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.
That's what the test net is for.
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.

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.
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.