10 ms·

Ethereum Contracts Are Going to Be Candy for Hackers

193 points by vessenes 10y ago

yarrel 10y ago
Article is much better than headline, including a case study and constructive proposals.
- vessenes 10y ago
  Thanks! The headline did have a bit of a buzzfeed quality on reflection.
kneel 10y ago
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.
- vessenes 10y ago
  I think we'll see a lot of interesting blockchain stuff come out in the next year. Recently, I have been trending toward the idea that one thing Bitcoin got right was carving out its useful domain area and focusing on that when it came to opcode support. It seems to me to be much easier to reason about a very limited set of actions than the virtually unlimited ones Ethereum offers. On the other hand, it's incredibly fast to spec out and deploy one of these contracts, which is pretty amazing to me. Lots of interesting things coming.
- fragsworth 10y ago
  > 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 10y ago
    >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 10y ago
      The security history of the JVM suggests that one shouldn't be optimistic there either.
      - rtpg 10y ago
        counterpoint: I haven't really heard of any "javascript escaping the container" bugs in a really long time (excepting node.js-related issues)
        ChristianBundy 10y ago
        JavaScript doesn't run on the JVM.
        cloudjacker 10y ago
        thanks for saying this, sometimes I'm like "wow" on hackernews comments, because you kind of assume people know what they're talking about but then its like not really.
        rtpg 10y ago
        I know that Javascript isn't run in the JVM, my point was that it's possible to write a virtual machine that doesn't get exploited every 5 minutes. the JVM is a bit special because there are a large amount of escape hatches, native code and a complex trust model, which has caused a lot of the exploits you end up seeing.
        astrodust 10y ago
- olalonde 10y ago
  > 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. Bitcoin also has a mini VM and scripting language (transactions are verified by "concatenating" the script of an output with the script of an input and running it). One big difference is that Bitcoin's scripting language isn't turing complete (e.g. you can't have loops or recursion) and there are other limitations like a per block limit on expensive operations (signature operations to be precise).
- ChemicalWarfare 10y ago
  To top that off - a relatively simpler Bitcoin software is maintained by a team of well known developers with all the typical artifacts and cycles associated with enterprise software development - release notes, testing etc etc. I'm sure the Ethereum team does the same but then when it comes to DAPPs and Contracts running on their VMs and potentially trying to compromise the underlying system things are way too fuzzy for now.
- cjbprime 10y ago
  > 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. Are you aware of the $155M USD people have sent to https://daohub.org https://daohub.org using (depending on) Ethereum?
  - kneel 10y ago
    Are you aware that the Dao was created by employees from slock.it and the Dao's first project is to fund a project from slock.it? Anyone who did 20 minutes of due diligence would be scratching their head at this.
    - cjbprime 10y ago
      Yes. I don't think they put in $155M, though. Which means they can't force such a project through unilaterally.
ChemicalWarfare 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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?
0x0 10y ago
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
- vessenes 10y ago
  Let's just say I was courteous to some of the early and published contracts out there. It does sketch out a new world for grey and black hats, when the attacks can be pretty easily separated out from an IP since they're submitted over the ethereum network.
- gus_massa 10y ago
  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 10y ago
    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 10y ago
      Those a problems with wallets, not bitcoin.
dmix 10y ago
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 10y ago
  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 10y ago
    What are the fairly obvious flaws?
    - vessenes 10y ago
      Check out some contracts and see for yourself!
- brianpgordon 10y ago
  How would the average Ethereum speculator know that the contract is flawed? Given the limited success of other, much easier-to-use blockchain technologies I'm skeptical that Ethereum can reach critical mass if every participant must learn the Solidity language and conduct a complete code review of any contracts they call. It seems to me that the Ethereum marketplace has to be married to some kind of source of trust, even one as simple as an upvote/downvote system.
pessimizer 10y ago
Don't lawyers do this to real-life contracts?
- jerf 10y ago
  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.
  - harwoodleon 10y ago
    But the issue with humans is also interpretation. If a contract or set of clauses is detrimental to a specific party, because if the complexity of the structure of a contract, not the language used - then surely this is easier to spot and fix with software heuristics, rather than deciphering humalanguage
harwoodleon 10y ago
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 10y ago
  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.
wickedlogic 10y ago
Seems like a problem solved with traditional simulation tools.
Rauchg 10y ago
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 10y ago
  From reading their site, it sounds like you expose yourself to massive counterparty risk using this, as a "federation" is holding your bitcoins.
woah 10y ago
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.
numlocked 10y ago
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
j1vms 10y ago
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.
joosters 10y ago
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 10y ago
  is there an easy-to-look-at link to the code?
  - vessenes 10y ago
    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/0xbb9bc244d798123fde783fcc1c72d3bb8c189413#code https://etherscan.io/address/0xbb9bc244d798123fde783fcc1c72d...
- gwern 10y ago
  Clearly the DAO's first investment should be in getting Augur up and running, so DAO token holders can hedge against a DAO hack in the prediction markets...
- pipermerriam 10y ago
  As a developer in the Ethereum space this idea has actually been something I've thought about a lot. It's on a list of things that I'm looking out for because they will inevitably happen. 1. Like you said, a bug will cause the "effective" theft of a huge amount of funds. 2. Someone will make a contract that unexpectedly makes a huge amount of money. That contract however will have absolutely no mechanism for extracting this money, forever locking the money it makes away beyond reach of anyone. 3. Someone will make a contract that the American government has deemed illegal. That contract will have been made such that there is no off switch. The only possible way for them to stop it would be to convince the majority of the network to remove it via a protocol update. I expect they will not be able to get this majority and thus we have an unstoppable force meets immovable object situation. 4. Ethereum will have it's `npm` left-pad moment when a contract that is used widely is suddenly suicided. The number of down stream effects will be enormous. Most of them will be unfixable.
eggy 10y ago
>>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 10y ago
  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 10y ago
    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 10y ago
      "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.
swordswinger12 10y ago
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 10y ago
  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-verification-for-solidity-contracts https://forum.ethereum.org/discussion/3779/formal-verificati...
davidgerard 10y ago
Smart contracts should be thought of as "the Underhanded C Contest on the blockchain."
zby 10y ago
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.

193 points by vessenes 10y ago

yarrel 10y ago

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

vessenes 10y ago
Thanks! The headline did have a bit of a buzzfeed quality on reflection.

kneel 10y ago

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.

vessenes 10y ago
I think we'll see a lot of interesting blockchain stuff come out in the next year. Recently, I have been trending toward the idea that one thing Bitcoin got right was carving out its useful domain area and focusing on that when it came to opcode support. It seems to me to be much easier to reason about a very limited set of actions than the virtually unlimited ones Ethereum offers. On the other hand, it's incredibly fast to spec out and deploy one of these contracts, which is pretty amazing to me. Lots of interesting things coming.
fragsworth 10y ago
> 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 10y ago
  >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 10y ago
    The security history of the JVM suggests that one shouldn't be optimistic there either.
    - rtpg 10y ago
      counterpoint: I haven't really heard of any "javascript escaping the container" bugs in a really long time (excepting node.js-related issues)
      - ChristianBundy 10y ago
        JavaScript doesn't run on the JVM.
        cloudjacker 10y ago
        thanks for saying this, sometimes I'm like "wow" on hackernews comments, because you kind of assume people know what they're talking about but then its like not really.
        rtpg 10y ago
        I know that Javascript isn't run in the JVM, my point was that it's possible to write a virtual machine that doesn't get exploited every 5 minutes. the JVM is a bit special because there are a large amount of escape hatches, native code and a complex trust model, which has caused a lot of the exploits you end up seeing.
      - astrodust 10y ago
olalonde 10y ago
> 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. Bitcoin also has a mini VM and scripting language (transactions are verified by "concatenating" the script of an output with the script of an input and running it). One big difference is that Bitcoin's scripting language isn't turing complete (e.g. you can't have loops or recursion) and there are other limitations like a per block limit on expensive operations (signature operations to be precise).
ChemicalWarfare 10y ago
To top that off - a relatively simpler Bitcoin software is maintained by a team of well known developers with all the typical artifacts and cycles associated with enterprise software development - release notes, testing etc etc. I'm sure the Ethereum team does the same but then when it comes to DAPPs and Contracts running on their VMs and potentially trying to compromise the underlying system things are way too fuzzy for now.
cjbprime 10y ago
> 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. Are you aware of the $155M USD people have sent to https://daohub.org https://daohub.org using (depending on) Ethereum?
- kneel 10y ago
  Are you aware that the Dao was created by employees from slock.it and the Dao's first project is to fund a project from slock.it? Anyone who did 20 minutes of due diligence would be scratching their head at this.
  - cjbprime 10y ago
    Yes. I don't think they put in $155M, though. Which means they can't force such a project through unilaterally.

ChemicalWarfare 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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?

0x0 10y ago

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

vessenes 10y ago
Let's just say I was courteous to some of the early and published contracts out there. It does sketch out a new world for grey and black hats, when the attacks can be pretty easily separated out from an IP since they're submitted over the ethereum network.
gus_massa 10y ago
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 10y ago
  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 10y ago
    Those a problems with wallets, not bitcoin.

dmix 10y ago

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 10y ago
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 10y ago
  What are the fairly obvious flaws?
  - vessenes 10y ago
    Check out some contracts and see for yourself!
brianpgordon 10y ago
How would the average Ethereum speculator know that the contract is flawed? Given the limited success of other, much easier-to-use blockchain technologies I'm skeptical that Ethereum can reach critical mass if every participant must learn the Solidity language and conduct a complete code review of any contracts they call. It seems to me that the Ethereum marketplace has to be married to some kind of source of trust, even one as simple as an upvote/downvote system.

pessimizer 10y ago

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

jerf 10y ago
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.
- harwoodleon 10y ago
  But the issue with humans is also interpretation. If a contract or set of clauses is detrimental to a specific party, because if the complexity of the structure of a contract, not the language used - then surely this is easier to spot and fix with software heuristics, rather than deciphering humalanguage

harwoodleon 10y ago

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 10y ago
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.

wickedlogic 10y ago

Seems like a problem solved with traditional simulation tools.

Rauchg 10y ago

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 10y ago
From reading their site, it sounds like you expose yourself to massive counterparty risk using this, as a "federation" is holding your bitcoins.

woah 10y ago

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.

numlocked 10y ago

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

j1vms 10y ago

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.

joosters 10y ago

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 10y ago
is there an easy-to-look-at link to the code?
- vessenes 10y ago
  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/0xbb9bc244d798123fde783fcc1c72d3bb8c189413#code https://etherscan.io/address/0xbb9bc244d798123fde783fcc1c72d...
gwern 10y ago
Clearly the DAO's first investment should be in getting Augur up and running, so DAO token holders can hedge against a DAO hack in the prediction markets...
pipermerriam 10y ago
As a developer in the Ethereum space this idea has actually been something I've thought about a lot. It's on a list of things that I'm looking out for because they will inevitably happen. 1. Like you said, a bug will cause the "effective" theft of a huge amount of funds. 2. Someone will make a contract that unexpectedly makes a huge amount of money. That contract however will have absolutely no mechanism for extracting this money, forever locking the money it makes away beyond reach of anyone. 3. Someone will make a contract that the American government has deemed illegal. That contract will have been made such that there is no off switch. The only possible way for them to stop it would be to convince the majority of the network to remove it via a protocol update. I expect they will not be able to get this majority and thus we have an unstoppable force meets immovable object situation. 4. Ethereum will have it's `npm` left-pad moment when a contract that is used widely is suddenly suicided. The number of down stream effects will be enormous. Most of them will be unfixable.

eggy 10y ago

>>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 10y ago
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 10y ago
  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 10y ago
    "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.

swordswinger12 10y ago

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 10y ago
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-verification-for-solidity-contracts https://forum.ethereum.org/discussion/3779/formal-verificati...

davidgerard 10y ago

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

zby 10y ago

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.