[...]
Afaics, Ethereum has an additional insoluble challenge which eMunie, Iota, and my design do not have to solve. That is they have to
guarantee ordering of contract execution is Consistent even within a partition, which afaik (from Computer Science fundamentals) is impossible unless the scripts are 100% dependently typed; because otherwise they are not commutative and the permutations of orderings with the unbounded recursion of general scripting results in the block chain state being indeterminate. If one instead argues that any partial ordering will suffice (just chose one arbitrarily), this is equivalent to arguing that contract ordering doesn't matter, i.e. that they are commutative. It is a circular logic. So I really have no idea what the designers of Casper are thinking

Serenity is intended to have two major feature sets: abstraction, a concept that I initially expanded on in
this blog post here, and Casper, our security-deposit-based proof of stake algorithm. Additionally, we are exploring the idea of adding at least the scaffolding that will allow for the smooth deployment over time of our scalability
proposals, and at the same time completely resolve parallelizability concerns
brought up here an instant very large gain for private blockchain instances of Ethereum with nodes being run in massively multi-core dedicated servers, and even the public chain may see a 2-5x improvement in scalability.
Above I and Vitalik both linked to the same page (
in fact I got that link from the quoted Vitalik text):
http://www.multichain.com/blog/2015/11/smart-contracts-slow-blockchains/The point that page makes is that validating Ethereum contracts MUST be slow because nothing can be validated with parallel computation.
I am making an additional and
more damning point. That is since each contract WITHIN a block has to be executed to completion before the next (i.e. no parallelization) this also means that the result of the block chain state will be potentially different depending on which order the contracts are ordered in the block. But note that such order is completely arbitrary (because there is no synchrony in distributed systems, i.e. there is no way to prove which transaction arrived first during the block period since each node will have a different ordering due to variance in network propagation).
The becomes an insoluble problem due to chain reorganizations (unless everyone waits for umpteen confirmations before validating anything but then how do we order the blocks...etc...see next paragraph).
Also we can't assume that contracts in one partition don't affect a contract in another partition due to externalities, e.g. for example the result of a contract causes an external action which causes the execution of another contract. The point of computation is that it is not bounded at the block chain!!!!!!!!!!!!!!!!!!!!!!
Thus if thus if the block period is not infinitesimally small (or especially as the block period grows larger), then the indeterminism that is introduced can cause contracts to behave randomly if they were not designed to handle such indeterminisn. Or worse yet, the validators on different partitions will be in predicament where if there are two or more orderings that are incompatible from different partitions and thus the block chain can't be unified and diverges into forks.
The externalities problem is entirely unfixable. Period! The only way to fix it is to not verify smart contracts on a block chain and instead only record the directed acyclic graph asset transfers on the block chain as the
section "Smart contracts in public blockchains" explains. This means the
entire premise of Ethereum is impossible. Fugetaboutit. Stick a fork in it. It is going to $0 their funding will run out and the game is over.
This is why I said the Ethereum developers do not fully understand the implications of the CAP theorem in conjunction with Turing completeness (or more saliently with the Second Law of Thermodynamics).
I am very tired of people saying that I am trolling and that the Ethereum developers are more clever than I am.
Even I remember Nick Szabo made an analogous error when he was at that conference where that guy claimed to be Satoshi and Nick was perplexed as to how the Bitcoin block chain could be made Turing complete with externalities. Someone tell Nick Szabo to read this (specifically from section "
Double decker blockchains" forward):
http://www.multichain.com/blog/2015/11/smart-contracts-slow-blockchains/Make sure you click the video link in the following quote!My immediately prior installment in this journey was about Turing-completeness, so it is highly relevant to note that Nick Szabo just demonstrated to me that he is lacking knowledge about Turing-completeness compared to this Craig Wright that some are claiming might be Satoshi.
At roughly the
17 minute mark in this conference video, Wright correctly explains that due to unbounded recursion, the Bitcoin block chain scripting is effectively Turing-complete. Afaics, he is entirely correct and Nick Szabo is wrong, because although the scripting language stack can't loop within one transaction, one can use multiple transactions to simulate looping. This is precisely the point I made in my recent post wherein I explained that under composition it is impossible to prevent unbounded recursion and thus unbounded entropy. Review the Dr. Suess proof of Turing-completeness. It doesn't matter what the called script answers, the calling script can always change the outcome. If you have the ability to store state on the block chain across multiple invocations of a script, then the block chain becomes the stack. Nick Szabo just demonstrated to me that he isn't as smart as I thought. Dr. Wright makes a relevant point that many people these days seem to forget that in machine code there is no virtual machine that controls what the instruction set can do in terms of which memory it can treat as a stack. Bitcoin's script instruction set can be viewed as machine code w.r.t. to its ability to read and store state any where in the memory space of the block chain UTXO.
What Dr. Wright meant when he said, "the looping function is actually separate from the loop itself ... that would assume the only way of devising code would be to put it directly in the script". Szabo made really stoopid statement implying that the language can only be Turing-complete if the script stack is, but he completely fails to realize that the block chain is state and thus can be an orthogonal stack. And most definitely then you can loop. When I say "loop", I mean in the sense relative to the block chain as the stack, so I do not mean that any one transaction can loop. Yet such a distinction is arbitrary any way, because I can have a client interacting with the block chain causing it to loop.
Here is more about conjecture about Craig Wright being Satoshi:
http://www.wired.com/2015/12/bitcoins-creator-satoshi-nakamoto-is-probably-this-unknown-australian-genius/http://www.theguardian.com/technology/2015/dec/09/bitcoin-creator-satoshi-nakamoto-alleged-to-be-australian-academichttp://www.theguardian.com/technology/2015/dec/09/bitcoin-founder-craig-wrights-home-raided-by-australian-police?CMP=twt_a-technology_b-gdntechEdit: and add Gregory Maxwell (nullc) to list of people who don't understand Turing-completeness: