Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: