Hacker News new | comments | show | ask | jobs | submit login

The DAO attack was plan interference. Absorb and grok that idea, and then the rest will hopefully follow.

Specifically, Viper has two glaring flaws, both of which are not suffered by E, Monte, etc. The first is a lack of correct encapsulation. Viper appears to have a Python-style object model, which means that it's not possible to closely hold a value. As a test, how would you build an object with a value in its closure which no other object can access?

Second, Viper doesn't have mitigation for plan interference, which means that it's possible for certain kinds of recurrences to alter your program's security guarantees. As a test, how would you mitigate the DAO attack in Viper?

Finally, I fear that these flaws may be inherent to Ethereum, meaning that any language on Ethereum inherits these flaws structurally and cannot mitigate them. In that case, maybe it's time to design a capability-safe Ethereum!




Indeed, in the (pre-DAO) Ethereum audit report https://github.com/LeastAuthority/ethereum-analyses/blob/mas... they brought up your second issue and recommended Mark Miller's thesis (which covers the material in the OP).

I haven't looked into Viper and how it might address these matters.




Applications are open for YC Summer 2018

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

Search: