Hacker News new | ask | show | jobs
by Animats 3659 days ago
There are two fundamental problems with Etherium contracts.

1. They're executable programs. They could have been a set of declarative rules listed in priority order, but no, the designers went overboard and made them general programs with loops and recursion. There are straightforward ways to analyze sets of rules; they're usually amenable to case analysis. It's hard to analyze programs.

Writing a declarative contract language is a challenge. But doing so forces the designers to think through what they want the system to be able to do, and what they don't want it to do. Doing contracts as executable programs is punting on the problem. It says "we don't know how to do this, so we'll dump the problem on the users."

2. The stack overflow problem is idiotic. The system should have been designed so that if a program aborts, anything it did is rolled back. That's the design flaw this attack exploits.

1 comments

To be fair, ethereum has bytecode at its base- almost certainly someone will wrote a more declarative language on top of it now to help minimize the chance that unexpected calling trees can lead to unexpected behavior.

Also, the existing solidity language is pretty well designed, it's just a hard problem and an even better design may be needed.

> To be fair, ethereum has bytecode at its base- almost certainly someone will wrote a more declarative language on top of it now to help minimize the chance that unexpected calling trees can lead to unexpected behavior.

The mismatch between executable code and high-level language is a known attack vector called the "full abstraction" problem. This has already been used to subvert the CLR and the JVM. If your bytecode is not inherently secure, and you permit executing arbitrary bytecode, then any language running on top that builds more sophisticated invariants that aren't enforceable via the bytecode are very likely vulnerable.

Almost certainly someone will wrote a more declarative language on top of it

Papering over the mold seldom works. It makes things easier, not more reliable. See C++ templates.

Note that putting a language on top of the existing language won't prevent VM stack overflows of the type used in the attack. It's more likely to hide them.
A better example is Haskell, which usually compiles down to a low level C dialect.
Any language can compile to the low level C dialect.