Hacker News Reader

Comment by zkSNARK | Hacker News Reader

Why don't the ETH people actually put out some decent templates for smart ICO contracts. It seems nonsensical that their platform is supposedly a "world computer" designed to enable smart contracts when a vast majority of the created contracts fail because of being hacked.

I invested in the ETH pre-sale and have done very well from it, but I have been selling a bit lately because I think someone else will come along with a system that open sources some really solidly vetted template contracts that have been thoroughly penetration tested by professionals.

View on HN

It's not just the templates, Solidity is a terribly designed language. It reminds me of the original JavaScript before 10+ years of dedicated attempts to make it usable.

With how many VM's we already have for Java and JavaScript it's idiotic that ETH designed their own language and eventually they will pay the price. This will probably be another coin that comes along without an idiotic language/VM

Isn't this the purpose of lisk?

fwiw the VM's instruction set seems just fine, the problem entirely lies within the crap programming languages available at this time. This seems to all be fixable if someone comes around and designs a language that makes it harder to shoot yourself in the foot.

The VM also has severe problems. Whether or not you are required to check exceptions at a call site depends on how you call a function, for example. It also does not have a monotonically increasing time value, since operations are allowed to manipulate the clock time up to some value.

Actually, the last multi-signature hack was because of the "decent" template contract produced by Ethereum developer.

Meaning that the template itself was messed up? Did they hire professionals to attack it in a test scenario or did they just roll with it?

I'm not so sure about that. Comparing the vulnerable source code to the original (which you can find here https://github.com/ethereum/dapp-bin/blob/master/wallet/wall...) tells a totally different story. It looks like the vulnerable version tried to condense everything into a single contract (think class), when it had originally been split up into multiple contracts (think classes). The result was that functions that were originally initializers were no longer callable only once. Someone's refactor of the original code seems to be what lead to this issue. The vulnerable functions even started with "init" but were not actually initializers.

Unless the original author also introduced the bug, I don't think it's fair to blame the original contract.

Some work is being done: http://vitalik.ca/general/2017/06/09/sales.html but tl;dr no perfect models for ICO's exists.

Contract templates and libraries are being developed as part of OpenZeppelin: https://github.com/OpenZeppelin/zeppelin-solidity

Reply on news.ycombinator.com