[mbrock]

I don't understand "you can't assume anything about the state of the contract." Surely the contract's state is only modified by the contract's own code, which means you can assume that the state is not altered arbitrarily but only according to the rules set up by the contract. Yes, you need to be careful about external calls that make altering calls to you.

[jerf]

The problem pointed out in this article isn't that it is impossible to write correct contracts. The problem is that it means that it is superhumanly difficult to write correct contracts, using the current feature set and infrastructure. This is especially true in what is theoretically an actively hostile environment, which the DAO hack proves is also actually an actively hostile environment.

It is theoretically possible to call out to another contract that has the ability to make further calls safely... but how can you be sure you've done it safely?

This isn't a unique problem. It arises in imperative-based programming all the time. But what in Javascript may be a bit of a coding error that means the next page of search results didn't load this time, in Solidity it means you may lose your shirt.

Also, I'd suggest that after-the-fact "static analysis" tools don't help. It's basically the same situation that real-world computer security is in, and right now, that world is massively advantage attacker, with generally far less direct incentive to attack than a blockchain functioning directly as money does. If the static analysis tool is open enough for "everyone" to use, the attackers get to use it too, and they can use it on all contracts at once because they're all open, and they have all the motivation to do so before the proper contract owners have time to fix their contracts. Every time the static analysis tools release a new check, it's an advantage-attacker race between exploiting the new check and fixing the contracts. The attackers are going to win big, repeatedly.

A Turing-complete blockchain needs to come out of the gate nearly 100% correct on this front, just as it needs to come out of the gate nearly 100% correct on the encryption security.

[mbrock]

I'm not sure that it is super humanly difficult. It seems likely that programming patterns, such as not using I trusted external sends at all, will emerge that any contract will need to abide by to be trusted.

If what you say is true then Ethereum is DOA, which seems unlikely to me. (I don't own any ETH.) I totally agree that it would be great to have more language based security and I've started dabbling with some stuff myself (playing with verified byte code compilation in Agda) but my basic attitude is that worse is better, these hacks are unfortunate but educational, and now we're going to see way more care in contract construction and let's hope it works out.

It might be that Solidity is going to be replaced, and it's super interesting what will come. A bunch of people are insisting that some variant of functional programming with types is necessary for correct contracts but I'm skeptical until I see an actual proposal...

[jerf]

And there are still people running around who think that writing code based on threads and semaphores isn't superhumanly difficult and people just need to Try Harder (TM).

At least when they're wrong, they usually don't lose millions of dollars. (But only... usually.)

I think some people are mentally modeling Ethereum as a sort of hobby thing in their head when they say things like that. I mean, who cares if my hobby static-rendering blog platform has a few bugs in it, right? But Ethereum aspires to be the foundation of an economy. Real foundations of economies have billions of dollars worth of effort poured into them. While a small set of particularly brilliant people may produce something that can run in this environment, Ethereum isn't what it would look like if they did.

I also think that people don't realize that the usual fate of a cryptocurrency is to die. Bitcoin isn't the first cryptocurrency by a long shot. Cryptocurrencies in general are not strong, robust things. I think something like Ethereum is quite likely, but there's no particular reason to believe we aren't three or four more major fully independent stabs at the problem away from a stable solution. Ethereum makes Bitcoin look like a homework problem in comparison; it would almost be beyond belief that we'd get it right the first time.

[mbrock]

I think humans are capable of writing correct programs even in machine code, it's just tricky and requires some expertise.

I also think the EVM itself allows for other paradigms than Solidity that might make it easy to create certain kinds of contracts.

And I think worse is better is very powerful, so it wouldn't surprise me if Ethereum sticks along for a long time, like Bitcoin seems to be doing despite its flaws.

[Dzugaru]

I'm not an expert in programming languages design and I've read about Etherium just a couple of days ago. But when I saw that "Solidity is like JavaScript and Python" - I was like "What? I'd pick some functional programming language for that!".

[nugget]

Well in theory couldn't any obscure exploit in the underlying framework (Solidity or related) be used to exploit contracts based on it? I think a comment from yesterday nailed it - that a system like this may be perfect for processing a repetitive, high volume of relatively low value contracts, wheres high value contracts may be better served by traditional systems wherein the Courts provide dispute resolution as needed. Broadly it would seem like Ethereum needs to isolate the potential for loss due to zero day exploits such that it is less than the savings realized from operational efficiency.