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.
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.
> 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).
> 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.
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.
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.
But. JS was designed with this in mind, and has been tested for it for years. It's actually one of the greatest strengths of JS, but I imagine it was a lot of work (except, perhaps, maybe functional languages).
Linus doesn't view security bugs as a special category of bugs. So he doesn't prioritize them they way most infosec people would like them to. The lack of a strong security advocate in their leadership is largely the reason why Linux isn't the best example.
The other big reason being that it's a giant blob of C and a large attack surface.
All of these factors could be easily avoided or simply don't exist for an Ethereum contract developer.
don't forget the fact that he was approached by the NSA to insert backdoors into linux, a fact his father testified to on the record before EU parliament[0].
> effectively error-free - probably as good as the Linux kernel
I encounter major glaring issues as well as continual regressions in the linux kernel on weekly basis. I don't even know what you mean by as correct as the linux kernel
Ethereum faces a similar situation as counter-terrorism: There only needs to be one sizeable incident that slips through the cracks for confidence to be shot.
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.
> 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 using (depending on) Ethereum?
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.
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.
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
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.
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...
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.
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.
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.
If one contract is flawed won't customers flock to another competing one?
Market is small so competition won't be strong; customers aren't professional security reviewers, so have no idea about flaws. What's most likely to happen is people putting money in and then losing it when an attacker discovers the flaw. That will put people off the whole smart contracts concept.
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:
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.
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.
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.
>>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.
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.
"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.
Please don't create many obscure throwaway accounts on HN.
This forum is a community. Anonymity is fine here, but users should have some kind of consistent identity that other users can relate to. Otherwise we might as well have no usernames and no community at all, and that would be an entirely different forum.
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.
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.
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
The issue with contracts isn't interpretation. The legal system evolved and develop procedures in how those contracts are executed. It is done through a form consensus building between two parties and the jurisprudence. There is procedural component of that involves human judgment and also provides avenues of appeal. The human element also serves as a sanity check within the legal system: intent and the consequences of a clauses matters more than what is stated. Ethereum, right now has none of this. The execution of the contracts are blind. Also, if software can be any indication of things, complex software with a lot of interacting parts tend to be very complex, and with no human in the process, with no consensus amongst those involved, what is being executed by those clauses and the intentions of those clauses can be worlds apart. I think in the realm of software, when this happens, people label this disconnect as a bug...
"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."
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. "
Me too. I can't remember enough about what they were to pull up details, though.
I remember it was some combination of contractual obligations to supply a certain product at a certain price, obligations to supply a certain number of them, a clause that changed the price if a certain number of them were bought, that sort of thing. You can do things like create contracts where you can buy enough of the items to trigger the lower price then force the company to take back the ones you paid the higher price for, or if you can screw with the price of some component that is necessary for the production of the thing make it so it costs the producer more to make than you're going to pay, stuff like that. Legal shenanigans? Absolutely. But considered to be normal stuff at the higher levels of the game.
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.
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.
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 :)
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.
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
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.
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
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.
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.
ICYMI: Bitcoin will gain Turing-completeness via a merge-mined sidechain called Rootstock (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.
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.