Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ethereum is Doomed

nakamotoinstitute.org

Post reply on HN
Print view View original

71–80 of 217 posts

Re: Ethereum is Doomed

#71

Post by CoffeeDregs »

aakilfernandes wrote: post #65
coldcode wrote: post #48

Earlier quoted context omitted.

It is doomed, who would trust a contract now with real "money"? Unless you have a mathematically rigorous proof that the contract is trustworthy I sure wouldn't.

Hopefully no on ever trusts a contract with 100 mill for a while, but for lower values and simpler contracts... absolutely i would.

So you would you sell your house and take an Ethereum contract in return?

Note: I loved Charles Stross's suggestion of code-as-contract in Acccelerando, so I dig the concept.

Re: Ethereum is Doomed

#72

Post by marssaxman »

aakilfernandes wrote: post #46
anaphor wrote: post #45

What if they had used a language without the possibility of recursion and without loops? I'm being serious. Languages that disallow certain types of recursion, and disallow loops exist. You'd think they would've used something that actually allows for total functions that are guaranteed to terminate in a certain way, instead of a JavaScript clone...

We want to allow recursion and loops. We want to be able to run arbitrary code. We just need to be a little wiser about how we do it.

Why on earth would you want that? How can such a staggering explosion of potential complexity justify itself?

Re: Ethereum is Doomed

#73

Post by jacques_chester »

TylerE wrote: post #50
aakilfernandes wrote: post #26

Earlier quoted context omitted.

The whole point of Ethereum is turing completeness. Ethereum without Turing completeness already exists and its called Bitcoin. While this implementation of The Dao has failed, Ethereum is the only blockchain where implementing The Dao is possible.

There is a huge canyon between "you can use this small set of ops" and "turing complete".

Not really. Any language that has sequential instructions, branching and loops is Turing complete, per the Structured Programming Theorem.

Given how hard it is to avoid accidentally introducing these three "simple" elements, Turing completeness often turns up without being planned for.

Re: Ethereum is Doomed

#74

Post by jacques_chester »

3pt14159 wrote: post #9

Ethereum isn't doomed. I don't think it will ever have as much backing as Bitcoin because of institutional buy-in; but the world needs programmable smart contracts. Some rich soon-to-be-dead billionaire tech nerds want to be able to do something every year without worrying about a judge taking that away from them. Individual will is what cryptocurrencies are about. Bitcoin in terms of international payments and store…

> Some rich soon-to-be-dead billionaire tech nerds want to be able to do something every year without worrying about a judge taking that away from them.

Billionaires still have nexuses with the physical world. The machines which execute their code, for example, can absolutely be affected by court orders. So too can their homes, their cars, their planes, their drones and of course their person.

There's a brand of techno-utopianism that assumes that if it's virtual, it's magically immune from the whole mechanism of law. This has never been true. The law asserts itself to be omnipresent in all human affairs and -- unlike a computer program -- the law's power is accepted at face value by billions of people and underlined by men with guns and dogs.

Re: Ethereum is Doomed

#75

Post by yawaramin »

viraptor wrote: post #34
SlipperySlope wrote: post #2

The programming classic "Mythical Man Month" had a chapter for the "second system effect". Its where developers put lots of complicated features in to the second system in a series. Its a pattern for failure. In this case, Ethereum developers built a much more complicated cryptocurrency by making it Turing complete - to the extent of writing their own new computer language and virtual machine to run it. They skipped…

That's actually a pretty good decision in my opinion. At least in this case. Think what would happen if they went for alternative solutions: 1. If it wasn't immutable, you'd never be sure when a contract changes. That's the basic assumption about contract - once you sign it, whether in real world, or by doing some action in Ethereum, you don't expect it to change how it works. That's why immutable is good. 2. User-co…

Solidity contracts are already modules which contain functions. They're equivalent to Java classes with static methods or Scala objects. As for namespacing, I don't know how in this day and age programmers can say that's not worth it.

Re: Ethereum is Doomed

#76

Post by apapli »

Surely an issue here irrespective of technology flaws or not is the economic impact on the time taken to write smart contracts.

If it now takes substantially more dev time to write a smart contract that is "secure" (ie by spending lots and lots of time testing for vulnerabilities) this will invariably come at a cost.

So while the theory of smart contracts is brilliant this recent hack might go down in history as a case study as to why writing contracts is too expensive to do in all but the top 1% of situations.

Re: Ethereum is Doomed

#77

Post by dkarapetyan »

Retra wrote: post #69
dkarapetyan wrote: post #64

Earlier quoted context omitted.

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.

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.

Re: Ethereum is Doomed

#78

Post by intrasight »

aakilfernandes wrote: post #26
dkarapetyan wrote: post #19

I didn't know the language was turing complete. Isn't this computing 101? If you want a secure thing then you must be able to reason about it statically. Making things turing complete means any non-trivial property of program correctness can not have a generic solution and so you've just opened yourself up to a world of hurt.

The whole point of Ethereum is turing completeness. Ethereum without Turing completeness already exists and its called Bitcoin. While this implementation of The Dao has failed, Ethereum is the only blockchain where implementing The Dao is possible.

I also don't see the relevance of it being TC. I've heard regex is TC. Wouldn't want to write a contract in regex.

Re: Ethereum is Doomed

#79

Post by rtpg »

DennisP wrote: post #25
darawk wrote: post #10

Earlier quoted context omitted.

My understanding is that it looks essentially like this: send(theEther, childDao) deduct(theEther, tokenHolder) But that you can get it to overflow the stack in between the two so that the send completes but the deduction no longer happens.

If you overflow the stack it throws and rolls back (which is another attack in certain circumstances). What killed TheDAO is basically that childDao called back the sender method, which sends again without having deducted yet. Do the deduct before the send, and the whole problem goes away.

Right, but would the deduction commit even if the send fails? Isn't this the whole concurrency 101 "Atomic deduct and send" problem?

Re: Ethereum is Doomed

#80

Post by cheez »

pmorici wrote: post #31
cheez wrote: post #21

Earlier quoted context omitted.

It's effectively legal because a lot of financial fraud is not pursued. For example, people from different countries scamming old people out of $1000 for Prince Abu to free his millions. That being said, I can understand why you think something being legally exploitable is something new. Just like a loophole in a contract is a loophole in a contract. In the case of smart contracts, there is no recourse unless built i…

Scamming old people isn't a bug with the bank.

It's a bug in the system though.
Post reply on HN