Hacker News Reader

Comment by api | Hacker News Reader

The whole Ethereum VM is too complex. For a role like smart contracts you'd want something dirt simple with few operations and provability.

View on HN

IMHO the VM here isn't really the problem. Its the compiler. The way I look at it this is really a compiler bug, that only gets "activated" with this upgrade.

The whole design is bad. Calls out to untrusted code should never have been allowed. You should be able to send messages out to untrusted code and to send ether. Perhaps the recipient of a message could be allowed to raise an exception, thus causing the transaction to abort, but otherwise the untrusted code should never have been allowed to reenter anything.

There's a simple way to prevent re-entrency.

----------

bool isEntered = false;

function doSomething() { if (isEntered) { throw; } isEntered = true; ...; isEntered = false; }

----------

I don't really understand why they went with this gas-limit solution. I feel like there must be something I'm missing cause its too obvious.

Because the kind of developer the average ICO scam hires isn't quality enough to code this kind of security.

A similar method is to put the external call at the very end of your function, after any state updates, and make sure that function isn't called from another function. These are well-known techniques in the community and commonly used, which is probably one reason the researchers didn't find any vulnerabilities in deployed contracts.

The gas limit on send was more of a belt-and-suspenders thing, not intended as the sole protection; that may have been a bad idea in retrospect, but at the time people were pretty focused on adding every protection possible against another DAO situation.

Reply on news.ycombinator.com