Ethereum is Doomed • Hacker News Board

Re: Ethereum is Doomed

#161

Post by mbrock » Tue, Jun 21, 2016, 9:47 AM UTC

rwallace wrote: post #150

edejong wrote: post #135

Earlier quoted context omitted.

There are languages which are both expressive and Turing incomplete, for example Coq. In the Coq language, Turing incompleteness is actually needed to be able to make complete proofs. Maybe Solidity would have been better implemented within Coq, but it's too late now.

Is it too late now? It seems to me that it should be possible to implement a better language on top of the existing system, there are plenty of languages that compile to JavaScript after all, so it's still worth discussing what a better language might look like. You say Coq is expressive; okay, but in what sense, for what purposes? A language which isn't Turing complete - or even one which is - isn't going to be expr…

Note that Solidity is not JavaScript, it's just superficially similar in some ways. The comparison with JavaScript is for marketing pretty much.

In particular, Solidity is statically typed.

I would say that smart contracts are a lot like event processors that update bits of contract-local state and enforce preconditions. They are run in a single "thread" in blockchain order, but they can also invoke each other reentrantly (and that's the major source of confusion so far, so it should be limited and made very explicit).

Some contracts perform more complex calculations, e.g. I know of one that calculates compound interest using fixed point math.

There might be room for several different simpler languages for different purposes... It would make sense to use the most restricted language that can express the contract you want.

Re: Ethereum is Doomed

#162

Post by tromp » Tue, Jun 21, 2016, 9:53 AM UTC

bobjones201606 wrote: post #108

Could the person who got the DAO's ETH create a contract to pay out miners who vote against a hard fork with the "stolen" ETH?

Assuming contracts can identify the coinbase address of past blocks, then that would be relatively straightforward.

But this may not be up to the miners alone. Perhaps even more important is what for the major exchanges choose to run, since they're needed to convert Ether back into BTC/fiat currency. If a major exchange makes a public announcement committing to either the soft or hardfork, then that will sway a great many miners.

Re: Ethereum is Doomed

#163

Post by rwallace » Tue, Jun 21, 2016, 9:55 AM UTC

mbrock wrote: post #161

rwallace wrote: post #150

Earlier quoted context omitted.

Is it too late now? It seems to me that it should be possible to implement a better language on top of the existing system, there are plenty of languages that compile to JavaScript after all, so it's still worth discussing what a better language might look like. You say Coq is expressive; okay, but in what sense, for what purposes? A language which isn't Turing complete - or even one which is - isn't going to be expr…

Note that Solidity is not JavaScript, it's just superficially similar in some ways. The comparison with JavaScript is for marketing pretty much. In particular, Solidity is statically typed. I would say that smart contracts are a lot like event processors that update bits of contract-local state and enforce preconditions. They are run in a single "thread" in blockchain order, but they can also invoke each other reentr…

From what I've seen of the discussion on this, you're right about uncontrolled reentrancy being a big source of problems.

One thing that occurs to me: would the command-query distinction be a useful notion here? I have no truck with it in the general context in which it was coined, but in this context maybe it would be useful to draw a hard line distinction between 'I call you to ask for information' and 'I call you to ask for money'.

Re: Ethereum is Doomed

#164

Post by jobigoud » Tue, Jun 21, 2016, 9:59 AM UTC

edejong wrote: post #135

rwallace wrote: post #134

The problem with Turing completeness is that if it's not there from the start, people inevitably end up needing features that aren't present in the restricted language, and then a Turing complete language is added to either the original system or a successor, and being an afterthought it usually ends up being a hack job. Examples: SQL was supplemented with procedural languages for stored procedures, Excel was supplem…

There are languages which are both expressive and Turing incomplete, for example Coq. In the Coq language, Turing incompleteness is actually needed to be able to make complete proofs. Maybe Solidity would have been better implemented within Coq, but it's too late now.

> it's too late now

Ethereum uses a virtual machine. There already have been several different languages to write contracts.

Re: Ethereum is Doomed

#165

Post by kalleboo » Tue, Jun 21, 2016, 10:01 AM UTC

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…

> want to be able to do something every year without worrying about a judge taking that away from them

Except we're just about to prove that an institution can decide to nullify a Ethereum contract with the soft/hard forks. In the very best case that will a cabal of miners with unknown intentions (and clearly they're not too invested in the Libertarian "code is contract" angle of the network) instead of a democratically constructed judicial system.

Re: Ethereum is Doomed

#166

Post by thelollies » Tue, Jun 21, 2016, 10:02 AM UTC

I wonder if a language like Haskell with a strong type system and strict typing could help. If you were able to express exchange of currency with the type system.

Re: Ethereum is Doomed

#167

Post by coldtea » Tue, Jun 21, 2016, 10:05 AM UTC

cyphar wrote: post #144

coldtea wrote: post #63

Earlier quoted context omitted.

First of all, the "officious bystander" test is from English law, not US law. Second, while there are similar tests in other countries' legal systems, it's not that clear cut whether this would be considered such a case or not -- a single lawyer's opinion aside.

> First of all, the "officious bystander" test is from English law, not US law. Yeah, sorry. But as you say there are similar tests in other countries. > it's not that clear cut whether this would be considered such a case or not Whether it would be considered a contract, or what are you referring to? Either way, Etherium and/or the authors of the DAO will get sued, and the investors will win the suit. If you think t…

>If you think there's a scenario where someone walks away with $50 million and nobody goes to jail as a result, I'm sorry to say that you're delusional.

Maybe you should read up on financial fraud, white collar crime and Wall Street?

Re: Ethereum is Doomed

#168

Post by danbruc » Tue, Jun 21, 2016, 10:10 AM UTC

dvdkhlng wrote: post #147

maxander wrote: post #95

Earlier quoted context omitted.

Turing-completeness was the entire conceit of Ethereum, as I understand it- without that you would have Bitcoin with a few bells and whistles, and no one would bother. And once you're committed to that, a new language and environment are essential- something this entire fiasco shows is that a language for contract programming has very different requirements than what software engineers are currently used to, in order…

I think we have a lot of theory about turing-complete computation. I really wonder why somebody would be willing to sign a turing-complete contract? The problem of understanding properties of the contract may be NP-hard [1] i.e. practicallly uncomputable. It may even be undecidable by involving instances of the halting problem [2]. [1] https://en.wikipedia.org/wiki/NP-hardness [2] https://en.wikipedia.org/wiki/Haltin…

It is undecidable in the general case as shown by Rice's theorem [1].

[...] Rice's Theorem may essentially be generalized from Turing machines to most computer programming languages: there exists no automatic method that decides with generality non-trivial questions on the behavior of computer programs.

[1] https://en.wikipedia.org/wiki/Rice%27s_theorem

Re: Ethereum is Doomed

#169

Post by mbrock » Tue, Jun 21, 2016, 10:10 AM UTC

rwallace wrote: post #163

mbrock wrote: post #161

Earlier quoted context omitted.

Note that Solidity is not JavaScript, it's just superficially similar in some ways. The comparison with JavaScript is for marketing pretty much. In particular, Solidity is statically typed. I would say that smart contracts are a lot like event processors that update bits of contract-local state and enforce preconditions. They are run in a single "thread" in blockchain order, but they can also invoke each other reentr…

From what I've seen of the discussion on this, you're right about uncontrolled reentrancy being a big source of problems. One thing that occurs to me: would the command-query distinction be a useful notion here? I have no truck with it in the general context in which it was coined, but in this context maybe it would be useful to draw a hard line distinction between 'I call you to ask for information' and 'I call you…

Solidity contracts can define "const" functions which aren't allowed to change state.

For some uses you can also look at the events that a contract emits, which are indexed and searchable off-chain... so client apps can read them, but not contracts themselves.

Re: Ethereum is Doomed

#170

Post by tomw1808 » Tue, Jun 21, 2016, 10:22 AM UTC

ianpurton wrote: post #153

DennisP wrote: post #22

I have actually tested this attack technique (using my own contracts on a local test chain), and I've been in discussions with some Solidity developers and the guy who first published the attack. The situation is not as bad as this article claims. For starters, you can use address.send(x) instead of address.call.value(x)(). All computations on Ethereum have to be funded with "gas" (transaction fees), and send() only…

The situation is not as bad as this article claims. Well it kind of is actually. The people that wrote the DAO script had the script checked by lots of Ethereum experts and the bug slipped through. So if the Ethereum experts can't stop things like this happening then what chance do individual developers have. Basically creating a turing complete scripting language on the blockchain is not secure. No financial institu…

Whenever I hear "expert" I think of https://www.youtube.com/watch?v=BKorP55Aqvg