It is up to the programmers that will be deleloping applications to make sure there is a logic inside smart contracts which are essentially computer programs with unlimited capabilities to have logic that will take care of out of order problems. Yes it is possible to write an application on Ethereum that will produce unpredictable results. But it is also possible to write applications that will work smoothly if the developer understands the architecture well enough.
In a strict sense you (and monsterer who mentioned that first) are correct, which is why I wrote the following:
Even if someone argued against my upthread point that strict partitions can't exist for scriptable block chains wherein I claimed this is due to uncontrolled external chaos due to external I/O, there is another unarguable reason that strict partitions can't exist for a scriptable block chain. That is because the gas (currency) transfers must be atomic with the script block confirmation (i.e. if they are orphaned and chain reorganized then they must be done together) so they must be in the same partition. But if the currency for a partition is a static set of UXTO or account balances (i.e. no cross-partition spending), then the system can not function properly.
Yet we also explained above (and even monsterer agrees on this point fwiw) that cross-partition spending breaks the Nash equilibrium.
Thus I continue to maintain my point that Ethereum can not scale with decentralized validation.
Which I subsequently
elaborated on today. The point about gas is why it is impossible to have sharded validation even if the scripts can otherwise be guaranteed to respect their partitioning.
But in a real world scenario where scripting is not controlled but is open for anyone to code, then when these scripts fail, they may not only fail themselves, but they may also do other things which cause other scripts to fail and
even cause the economics of 51% attacks to be much easier and more plausible (make sure you click that link, as well read how
I explained it to monsterer upthread). In short, the Nash equilibrium can collapse due to unpredictable externalities. But even if you argue against this, the
sharding (paritioning) of gas is implausible with sharded validation.
Its really pointless to have a general discussion without reference to specific application. One thing is for sure: the slowlness and lack of concurrency greatly limits possible applications. What worries me is that Vitalik is computer science drop out and he may have missed some of the important stuff that people suppose to study
The whole thing about Ethereum seems to me like a strech of imagination that may lead nowhere. Blockchain is very specific thing created for very limited and specific purpose and so will be possible applications of Ethereum which I see to be mostly limited to transactional stuff. These applications will have to be quite simple, no heavy processing is going to work well in such archetecture. I really would like to see very specific ideas for Ehtereum apps and not general stuff that is theoretically possible.
Yeah that is my point that even though the virtual machine works, it doesn't scale decentralized (yeah sure we can scale anything centralized). And it won't even scale to where Bitcoin is now decentralized because scripts consume more validation resources than validating ECDSA signatures.
Here are some ideas for DApps to think about when designing a smart contract block chain:
www.coindesk.com/7-cool-decentralized-apps-built-ethereum/I am of course thinking about this and how to do it correctly.
If I get healthy, I will try to teach these young guys a lesson about respecting those who have experience. I don't think Vitalik and Vlad are entirely clueless (and certainly Greg Meredith is a true academic and had worked at Microsoft Research), but I do believe they lack the experience in creating software and shipping it to millions of users. They lack some of the things I had to learn the hard way in those many years of shipping software that worked.
For example,
I long ago shortcut directly to the generative essence of the problem space and thus am not wasting everyone's time and $millions pursuing braindead designs that can't possibly work. Instead I understand that validation must be centralized in any possible consensus system and thus I turned my attention to decentralized control over centralized validation. Those guys are instead still stuck back at figuring out what can't work.