If the loss had happened to anyone else other than the people behind Etherium, the fork would never have happened.
A fundamental problem with Etherium is contracts between anonymous parties. If the other party in the DAO hack was discoverable, the hack would not have been a major problem.
Executable, rather than declarative contracts, are probably a bad idea. Putting in a virtual machine is a cop-out - it means you don't know how to solve the problem of expressing contracts formally, and are pushing it off on someone else. That someone else will probably botch it, as the DAO did. I've previously suggested that decision tables [1] would be a better basis for a contract system. This decision table tutorial [2] is something of an ad for a tool, but it uses as an example the sort of things one would want in a contract.
The paper points out that many of the Ponzi contracts on Etherium have exploitable bugs. Some can be induced to compute too much and thus run out of "gas", aborting. Some allow an attacker to change the party who gets the fees. Some can be stalled out with a suitably constructed transaction.
Making Etherium contracts a full byte code execution engine was a big mistake. That form is too bug-prone and led to the DAO debacle. It should have been something simpler, such as a decision table.[1] That simple declarative form can handle most useful business logic, but can't loop. It's always decidable and is easy to hand-check.
> Letting the hacker walk away with millions at that point would have been silly.
The issue is, the person wasn't a 'hacker' in any meaningful sense of the word.
Etherium claims to be "a decentralized platform that runs smart contracts: applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third party interference" (from etherium.org). That is, an Etherium program doesn't implement a written contract, it is the contract.
Despite this lofty goal, the core team saw fit to hard-fork the chain because they didn't like how a particular program was executing. The claim that the 'hacker' had 'stolen' funds from theDAO is ridiculous - you can only steal what doesn't belong to you, and ownership of theDAO's Ether is defined by the program itself!
More broadly, the hard-fork seems to imply that an Etherium contract is really made up of two contracts. One contract is the program itself, which explicitly spells out what is and not allowed. The other contract is an implicit understanding of what the program 'should' do, and exists only in the minds of the creators of the contract. The issue arises when this implicit 'contract' is used to override the real contract - flying in the face of how Etherium claims to work.
A much better solution would have been to try to address the underlying issues in Solidity - perhaps requiring future contracts to explicitly allow recursion? I personally question the decision to use a Turing-complete language to express contracts in the first place.
Ethereum worked very well with the DAO...for the hacker that stole several million and that forced them to fork.
I will never trust a system where they can decide arbitrarily to void all the transactions that everyone made after several days.
I think Ethereum undermined their whole reason for existence when they did a fork in response to a valid contract because enough people did not like the results.
The fact that they called it a hack when it explicitly followed the Ethereum guidelines calls into doubt the sincerity of the people behind Ethereum.
If people want to actually have malleable contracts in the case of fraud, the courts provide a much more accountable process that has had centuries of fine tuning.
its worth noting that the fork wasn't actually because of a bug in Ethereum, but because of a bug in a smart contract (the DAO). Ethereum itself worked perfectly. Bugs do exist in Ethereum and Bitcoin all the time, but they can almost always be fixed without changing the underlying protocol, so the clients just need updated.
The fork happened because the community decided the smart contract in question was important enough to the survival of Ethereum that it'd be worth essentially backing out the contract (in a roundabout way)
I think this comment on the original blog post says it very well:
"To be clear, if this happened due to an exploit in the software, then I can accept a hard fork fixing the issue. However, if the DAO team made a mistake in the way they designed their smart contract, as an issue of principle, they should not be "bailed out" by the Ethereum team because they are "to big to fail." Hard lessons like these teach the cryptocurrency community at large to do their homework and to be excessively (and obsessively) diligent with their security."
There's a pretty significant lesson here, and it's not that the DAO authors were careless. They were, and so were all of the investors, but the core problem is not the DAO.
It's Solidity. It's the Ethereum virtual machine. Even today, security vulnerabilities are being found in code strategies that are generally considered 'best practice'.
Writing a safe smart contract on Ethereum is extremely difficult, and most people playing with Ethereum don't seem to realize this. There's a pretty well understood maxim, "don't roll your own crypto." Etherem's smart contracts ARE cryptography, and their safety depends on implementation details that are completely hid from users during tutorials, and that even the language designers are only still discovering.
And it's one of the major reasons that the Bitcoin devs have not been excited about Ethereum. It's a project whose ambitions have outpaced our ability to engineer safely.
One day we can have safe smart contracts. But the Ethereum of today is not well designed, and is not a good foundation for smart contracts. A simple hardfork to fix this DAO mess isn't going to be enough. The whole virtual machine needs to be redesigned.
And my money is quite seriously on Bitcoin figuring out the safe way to do smart contracts faster that anyone else. The vast majority of experienced experts in this space are still spending the majority of their time on Bitcoin. As popular as Ethereum has become, Bitcoin still owns the mindshare, and there are good reasons that Bitcoin has chosen not to pursue smart contracts at this time.
There was an Ethereum contract called The DAO which had a bug in it that got taken advantage of. They decided to hard fork all of Ethereum to retrieve the appropriated money.
It's seen as some as an admission that the Ethereum ethos of "the code is the contract" is unrealistic.
To be clear, that attack (also the The DAO event that caused the ethereum fork) was a hack. It was a bug in the contract that got exploited. And that's a risk too.
But even if a DAO does everything right, technically, they're still subject to the problem of having to trust entities in the real world (e.g. "whoever on the Blender foundation gave them the address to pay") to behave the way they promise (e.g. "actually hand them an address under the control of the Blender Foundation"). It's trivially easy in this world to just cheat.
And in the real world, with real people on both sides of the transaction, that's addressed in the courts. And it works, and fraud as a proportion of our economy is quite small. But that protection doesn't extend to anonymous smart contracts.
This is the most insightful comment about this incident that I have seen so far. The problem is that the Etherum system uses an imparative language to describe smart contracts. This opens the door very wide for the kind of bugs that led to the theft of $200M from The DAO. The correct solution would probably have been to design a domain-specific declarative language that provides abstract building blocks for smart contracts. This would have allowed to hide the procedural complexity in the interpreter and contract bugs like the present one would not have been possible. Even if there was a problem, it could likely be fixed in the interpreter leaving the contracts and the blockchain untouched! This means that a lot of unanticipated problems would not have been fatal for the contracts. The problem of the current approach is that it conflates the business logic and it's implementation thus increasing the burden for contract authors and increasing the attack surface.
In many other domains, a suboptimal choice of language paradigm would just add some extra friction but in the domain of smart contracts it can lead to catastrophic failures. Many people claim that the cause of the present disaster is just a faulty contract and that the Etherum system is working correctly. Some even say that the present case shows how well the technology is working. But willtim's comment makes it clear that there may be a fundamental problem with Ethereum. I wonder whether the imparative paradigm was a conscious design choice or something that just happened because the developers didn't even realize that it was a design choice.
Edit: I wrote this before willtim's added his edit 2.
One amusing consequence of the "fork" is that it demonstrates that there are few Etherium contracts outstanding that matter. Otherwise, the people on opposite sides of the contract would be having big disputes over where their contract ended up. Did anybody other than the DAO crowd actually use that feature for anything big enough or long term enough to matter?
Too bad this theft did not affect the founders of Ethereum like the DAO exploit did. Otherwise, they would have found a way to reverse this and get people their money back from the hacker, even if it meant changing the protocol and upgrading existing binaries.
"Except "learning" in Etherium's case would have been to abandon the currency due to its insecurity, probably fork the code, and just start over from block 0 again."
Aren't you confusing Etherium with The Dao ? Yes, the dao needed to be abandoned due to its insecurity, but my understanding is that the Etherium base itself was not at fault.
A fundamental problem with Etherium is contracts between anonymous parties. If the other party in the DAO hack was discoverable, the hack would not have been a major problem.
Executable, rather than declarative contracts, are probably a bad idea. Putting in a virtual machine is a cop-out - it means you don't know how to solve the problem of expressing contracts formally, and are pushing it off on someone else. That someone else will probably botch it, as the DAO did. I've previously suggested that decision tables [1] would be a better basis for a contract system. This decision table tutorial [2] is something of an ad for a tool, but it uses as an example the sort of things one would want in a contract.
[1] https://en.wikipedia.org/wiki/Decision_table [2] http://reqtest.com/requirements-blog/a-guide-to-using-decisi...
reply