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

121–130 of 217 posts

Re: Ethereum is Doomed

#121

Post by bendbro »

viraptor wrote: post #38
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…

I think you're thinking of use cases that would definitely be stopped outside of ethereum world: > 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. You can do things like this, but the law either already covers this, or will adjust. If you gain money, you're expected to pay the usual tax on that gain. First few may g…

As long as you never convert into traditional currency, how will they know you participated in a transaction?

Re: Ethereum is Doomed

#123

Post by [deleted] »

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.

[deleted]

Re: Ethereum is Doomed

#124

Post by marssaxman »

tamana wrote: post #89
marssaxman wrote: post #72

Earlier quoted context omitted.

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

TheDAO showed a $40m reason why we hackers want the complexity :-)

This debacle seems like the most obvious possible outcome for any system combining the concepts "Turing-completeness" and "cryptocurrency blockchain". What baffles me most about the whole mess is that any of it caught anyone by surprise. I guess I had vaguely (naively?) assumed that the people building Ethereum and TheDAO must have come up with some clever solution for this sort of problem, but so far I haven't heard of one.

Re: Ethereum is Doomed

#125

Post by plaguuuuuu »

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.

Turing completeness isn't so bad when you have a relatively low gas limit on a transaction that ensures you can halt at some point.

Maybe I spent too much time in functional languages and I've been doing too much React stuff lately but the way I see it, we have

    Contract_method(state, parameters) => {new state, return value}
You could always run the program on a fake, mock state then test postconditions for sanity. So, if those postconditions pass and we haven't run out of gas, run the program for real, otherwise return an error.

Eg transferring 30 eth from contractA to contractB you would have one of the postconditions asserting that ContractA balance is the old balance minus 30.

The notion of gas implies a stack or effort limit, so it's guaranteed that any operation will eventually fail once it runs out of resources. Thus you can specify a theoretical upper limit on resources used in pre-verification, which (AFAIK)is paid by the client contract that requests to withdraw money from the other contract.

I guess one could avoid this by using a DSL that is formally verifiable, but it's still an interesting option

Re: Ethereum is Doomed

#126

Post by dkarapetyan »

plaguuuuuu wrote: post #125
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.

Turing completeness isn't so bad when you have a relatively low gas limit on a transaction that ensures you can halt at some point. Maybe I spent too much time in functional languages and I've been doing too much React stuff lately but the way I see it, we have Contract_method(state, parameters) => {new state, return value} You could always run the program on a fake, mock state then test postconditions for sanity. So…

Yes, I'd assumed since Ethereum was so highly touted and hyped that the foundations of the entire thing were sane. Well I mean sane in the sense that the actual contract language was as restrictive as possible and custom made for expressing contract law but it turns out you can do arbitrary computation and although in theory you're limited by this gas thing because the language is not formally specified and verified it is not clear at all if there are no other bugs lurking around with respect to bypassing the gas bounds.

What you described is basically abstract interpretation and if it was designed properly then the type system would have taken care of the simulation piece.

Re: Ethereum is Doomed

#128

Post by Animats »

It's now clear that Ethereum's contract system has major security vulnerabilities. This is a killer flaw for something which exists only to secure transactions between mutually mistrustful parties. Maybe someone else will do this again, better. Etherium itself probably is doomed.

There are also hard questions to ask the people involved. The same people seem to be behind Etherium, the DAO, and the programmable door-lock startup which the DAO was supposed to fund. This is suspicious. This might be an inside job. At least three times in the Bitcoin world, some Bitcoin exchange claimed they lost money due to a "hack", but in the end it turned out to be an inside job.

Re: Ethereum is Doomed

#129

Post by plaguuuuuu »

dkarapetyan wrote: post #60
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.

This doesn't sound right to me. Contract law should not require turing completeness. First order logic should be more than sufficient. How does having a loop in contract law make any sense?

I agree. Furthermore, the notion of contracts that cannot be specified in first-order logic seems relatively dangerous to me.

Re: Ethereum is Doomed

#130

Post by wyager »

dkarapetyan wrote: post #120
wyager wrote: post #117

Earlier quoted context omitted.

> You want something that guarantees termination You usually get that through a restricted subset of an otherwise turing-complete language. The standard approach is to impose a finite metric on the arguments of a function and demonstrate that, as the function recurses, that metric monotonically approaches zero. >barely becoming practical in languages like Rust. As far as I know, this cannot be done in Rust. Agda, Coq…

I meant reasoning about resource usage. Rust provides lifetimes which I think is based on linear logic (see https://news.ycombinator.com/item?id=7061876 ). In theory, this gas thing should act as the metric you mentioned but it doesn't seem like it is implemented properly when it comes to how the fundamental building blocks of Solidity act with respect to the gas metric. The termination stuff in total languages I thi…

Ah, that's an interesting idea. Static resource usage analysis instead of computation tokens.

> Dependent types aren't the easiest thing to pick up.

Look at liquid types. They're a lot easier to leverage in practice. Liquid Haskell is all just comments on top of a regular Haskell program.

Post reply on HN