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.
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.
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).
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.
"will be effectively error-free" != "probably as good as the Linux kernel", not even close :D
To put it mildly: There will be blood.
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.
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.
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
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.
Are you aware of the $155M USD people have sent to https://daohub.org using (depending on) Ethereum?
Anyone who did 20 minutes of due diligence would be scratching their head at this.
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.
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.
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.
Most Ethereum contracts aimed at public consumption are published at ethereum chain viewers. I like etherscan: this is the DAO's contract
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.
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.
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.
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.
J of course has a different problem; only a handful of people can even parse it, much less opine on correctness.
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.
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.
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.
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.
At the same, there's https://en.wikipedia.org/wiki/Scrivener#Doctrine_of_.22scriv... and https://en.wikipedia.org/wiki/Reasonable_person .
Combining the two and suggesting that the result will somehow magically be more secure and less hackable - in any sense - is nonsense.
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...
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. "
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.
Hopefully someone can come up with some better examples. But I'll at least make a peace offering with this: http://thedailywtf.com/articles/Special-Delivery
Does the company in question lose business when this comes out?
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.
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.
Either way, you have a trust problem -- who shall be trusted to transfer out all the value the contract holds?
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.
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.
A little similar to how bad guys hook onto github feeds and instantly exploit leaked aws keys etc
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.
I highly recommend their whitepaper as it's also a great overview of the Blockchain ecosystem as a whole.