As the article briefly suggests, this problem can be completely avoided if every method has no more than one external call and always puts it last.<p>I'm messing around with contracts to do about a dozen different things, and it turns out to be easy to meet this restriction, as long as I'm willing to design the UI accordingly. (E.g. don't send money to lots of users in one step, just update their balances and make them call a withdraw function.)
So one contract can call a function in another contract, in the middle of their transaction:<p><pre><code> if (_recipient.call.value(_amount)()) { // vulnerable
</code></pre>
That's inherently a scary feature, and it was exploited.<p>Etherium's "Solidity" suffers from the desire to have it be a general-purpose computer. It should have been if-then rules, or a logic tree, or a decision logic table - a finite representation of business logic subject to exhaustive case analysis. Contract executions should have been atomic transactions - either everything commits, or everything gets rolled back. Stack overflow and running-out-of-gas terminations are inherently trouble.<p>Etherium needs to go back into the shop for a redesign. At least we found out early that this isn't going to work.
"This impacts all contracts on Ethereum, not just the DAO. This is an issue with Ethereum’s JavaScript-like programming language (Solidity)."<p>No it doesn't, no it's not. It affects contracts that use this functionality with arbitrary untrusted contracts (which is a bad idea), and most contracts just don't use this functionality at all.
Isn't this just a normal data race with stateful actors? Something modified the data while A is calling B (doesn't have to be B, could be any X) in between a call and its response.<p>The answer to this is that mutation needs to be kept under control. Immutable data structures in mutable buckets. Locking around the data that mustn't change. Deep copy all state before calling out. And so forth.<p>This is basically an understood problem and I'm a bit appalled that Ethereum didn't build protection against it into their design.
I don't understand "you can't assume anything about the state of the contract." Surely the contract's state is only modified by the contract's own code, which means you can assume that the state is not altered arbitrarily but only according to the rules set up by the contract. Yes, you need to be careful about external calls that make altering calls to you.
"that impacts all of Ethereum"<p>Well, all of Ethereum smart contracts which are written in Solidity and which use a "call construct" in a certain way.
With all this fuss over ethereum security flaws, can someone explain to me the practical use case for these smart contracts? I just don't understand where the benefit comes in. It seems like any type of contract that would be useful requires a human to qualify the meaning of the terms since these contracts cannot autonomously measure the state of the world.<p>Even something as trivial as betting on sports requires deference to a trusted authority to say "this team won". What advantages does an ethereum smart contract provide over, say, some kind of trusted bitcoin escrow site?
Interesting Ethereum uses the term "function" however in programming we understand a <i>pure</i> function to be an operation that always returns the same result given the same inputs.<p>I don't know anything about Ethereum, but if functions rely on external shared state then they aren't pure functions, are they?
Any code that calls arbitrary callbacks is prone to failure. The context in which a callback is called matters.<p>Calling a callback at the end of a method avoids interfering with the caller's state but ignores the state of the caller's caller.<p>An ethereum contract will only be tractably analyzable if it avoids dynamically invoking arbitrary callbacks.
Given that trust is the single most critical aspect of the entire platform, why doesn't it use languages (for both the platform, and the contracts), programs in which can be easily formally verified, and for which tools for such verification already exists?
So what they should have implemented is communicating sequential processes / actors instead of arbitrary calls.<p>The more I read about ethereum's technical details, the more it sounds like a joke to me.
This reads a little sensational. The original source [1] referred to in the article looks at the issue in more detail.<p>[1] <a href="http://pdaian.com/blog/chasing-the-dao-attackers-wake/" rel="nofollow">http://pdaian.com/blog/chasing-the-dao-attackers-wake/</a>
Nearly a year ago I made the comment --<p>"Who are these people[1] and what credentials do they have to build and run a cryptocurrency platform?"
[1] <a href="https://angel.co/ethereum-1" rel="nofollow">https://angel.co/ethereum-1</a><p>Today, not a single cryptographer, mathematician, or anyone with software security experience is listed on the Ethereum Foundation member list[2]. I am not attacking any individuals by themselves, but as a group this says a lot.<p>For the record, what I see listed online today is a: consultant, magazine founder, a programmer, and a lawyer. On the advisory board a sales person, a psychologist, a leveraged debt consultant. On the "special advisors" list, which I have no idea what this means, maybe someone who answered a phone call a few times, one person with a bunch of business credentials, something "fintech" related with little explanation, and a tech CEO.<p>Maybe the Ethereum Foundation doesn't need anyone with deep experience in cryptography and security?<p>[2] <a href="https://www.ethereum.org/foundation" rel="nofollow">https://www.ethereum.org/foundation</a>