The DAO Attack

Thursday, June 23, 2016 from 4:00 PM to 6:00 PM (IST)

Meeting Notes

Since the meetup had a smaller group of participants (5 folks), it was moved to a conference room with a whiteboard.

The DAO - Attack Explanation

In yesterday’s meeting, we discussed the DAO attack vector in the code and how the money was siphoned off into the child DAO contract. This was very informative discussion by Rakesh BS. We created a simpler Vault contract with the recursive call vulnerability. We used a Hacker contract that exploits this vulnerability to get money out of the Vault contract. In essence, the exploit was based on the construction of the withdraw function in the Vault contract and the fallback function of the Hacker contract. The difference between send and call was a large part of the exploit. An independent variable was used to make sure the function did not hit the callstack limit when executing the code.

We then speculated about possible ways and means by which the code that is written for a contract could be validated to prevent such issues. One point that was raised was that Turing complete languages had inherent features that could lead to such bugs. The discussion turned to contract driven programming languages and design by contract. The example of the Ariane 5 explosion and the Eiffel Programming language was taken. This is a powerful paradigm and one which was felt would have been helpful in a programming language designed for a blockchain contract.

Why design a new turing complete language? Why not just leverage one of the plethora of existing languages - a lot of these have very powerful features and tools to ensure code validity.

At a more business and legal level, a point that was raised was the risk of raising such a huge amount of money for what should have been an prototype. And the fact that a risk assessment was not done even after raising so much money. As they say - “Hindsight, is 20-20!” but if the entire DAO experiment had been restricted in terms of the money raised, then the risk and the fallout of a failure would have been more contained.

Merkle Trees

This was a deep dive into Merkle trees, their structure and the ways they can be used, done by Rakesh BS. He used the context of Bitcoin, specifically the way full nodes provide merkle proofs to SPV nodes to prove that a transaction is valid and part of a particular block. He explained how full nodes only need to provide log₂(N) byte hashes as proof, where N = the number of transactions in the block.

We then discussed a bit about the bandwidth and processing implications of this on the full node, especially in the context where Bloom filters are used to obfuscate the key against which transactions were requested.

It was an enlightening discussion and the reference to a practical example made things easier to understand IMO.

Bloom filters

A followup topic we did was a technical discussion on Bloom filters, using the context of the functioning of a SPV node in the Bitcoin network. This was also a very good and enlightening discussion and the use of a practical example really brought the abstract concept to life!

Finally the technical portion of the meeting ended with a pointer provided by Rakesh for homework - Tries

Post meeting we had a lively discussion of the latest Game of Thrones series :-)

References -

• Difference between send and call in Ethereum
• Design by contract
• Eiffel Programming language
• Ariane 5 explosion
• Merkle Trees
• Bloom Filters
• A nice introduction to Bloom Filters
• Video comparing and contrasting Trie and Patricia Trie