Hacker News Reader

Comment by heliumcraft | Hacker News Reader

Based on a poor design? according to who? It's the most advanced blockchain out there by far and wide! This was a single contract with a flaw, it's like saying the whole internet is doomed because some website got a SQL injection.

View on HN

I don't think "most advanced blockchain out there" is actual praise. Systems, especially systems that are meant to serve as a substrate for more advanced systems must be simple to understand and reason about. Making the foundation turing complete is indeed poor design.

If your goal is a calculator, then a computer is a poor design indeed.

Ethereum is meant to be a platform and goes far beyond what Bitcoin can do.

Turing completeness is not an implication of poor anything. All it does is remove certain kinds of generality from your proofs. You can still prove things, you just have to be careful stating what the assumptions are.

So you mean to tell me that taking away the ability to write generic programs to validate contracts is good design? See Rice's Theorem (https://en.wikipedia.org/wiki/Rice%27s_theorem). Once you have turing completeness verifying any non-trivial program property starts requiring grad school experience and real proficiency with writing and verifying proofs. Most people, including programmers, do not have the training nor the discipline to actually do what you suggested.

In practice the assumptions you mention turn out to be assumptions about totality and termination of certain building blocks and so you are back to a restricted subset of the language which should have been the original language to begin with but instead of automatic verification you have turned the problem into manual labor. Thinking about this more I agree with the naysayers. Etherium was a good experiment to show people what they should not put into a smart contract system.

So instead of hiring a juris doctor lawyer to review my contracts, I'll hire a PhD computer scientist ;)

Correct. Programmatic contracts should have democratized the entire business but instead this new scheme creates a new class of "lawyer".

I strongly prefer "laws" that are based on mathematics/computability theory than on social conventions.

I think this is the core flaw in the mindset of Ethereum adherents: the very idea that it is even possible to have "Laws" which are completely objective to the point of mathematical logic and that these could/should be enforced, literally, by a computer running a program.

We are thankfully very very far from a system of Laws which are anything like that. Such a system might be great in certain "sandbox" environments for manipulating resources that have carefully controlled interactions with the outside. But to have arbitrarily complex "smart contracts" running in the affairs of the real world? no thanks!

We are in agreement. It's unfortunate that the initial implementation was a blunder.

.and that PhD computer scientist will have a contract that he/she cannot be held responsible for anything bad that happens with the code he/she writes. Written by a juris doctor lawyer. :)

So, just write your contract in a non-turing complete subset of it. Just because the power is there doesn't mean you have to use it if you don't want to.

According to the article, you need to write interfaces that accept a function and call it somewhere down the line. At this point you already cannot guarantee the lack of recursion, simply because the supplied function can call your function again. It is simply not possible to write a code that always halts, unless you never even call the supplied function.

There's a difference between general recursion and bounded recursion, and you can very easily constrain recursive functions to terminate, especially if you're in control of the data they must pass around.

You just made my point. The Ethereum designers have offloaded all the hard work onto others. What value do I get out of this platform if I'm doing all the hard work?

Please read http://hackingdistributed.com/2016/06/17/thoughts-on-the-dao....

Solidity language makes very hard to write safe code:

Is Ethereum/Solidity Suitable for Secure Smart Contracts? It's clear that writing a robust, secure smart contract requires extreme amounts of diligence. It's more similar to writing code for a nuclear power reactor, than to writing loose web code.

Yet the current Solidity language and underlying EVM seems designed more for the latter. Some misfeatures are:

A good language for writing state machines would ensure that there are no states from which it is impossible to recover. A good language for writing state machines would make it painfully clear when state transitions can and cannot happen. A good language for maintaining state machines would provide features for upgrading the security of a live contract. A good language for writing secure code would make it clear that there are no implicit actions, that code executes plainly, as read. The current language does not fulfill any of these commandments, and in fact, the last one, involving implicit recursive calls, is what did The Dao in.

The SlockIt team even had the designer and implementor of Solidity perform a review of their code. If he cannot get something like The DAO to be secure, no one can.

Reply on news.ycombinator.com