Quote from: TPTB_need_war on February 13, 2016, 01:16:59 PM

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.

Do not dismiss my point thinking that the boundary is at block confirmation. That is a naive perspective.

The issue is that since the output state of a contract in one partition could impact the input state of a contract in another partition (and there is no way to prevent this unless no one can write any user data into the block chain), then validators in each partition need to trust validators in all partitions, thus they really need to verify the scripts from all the partitions else the consensus-by-betting doesn't reflect rational incentives which the math depends on for rational (versus randomized noise) convergence, i.e. the game theory of the consensus model is impacted. But if all partitions have to validate all partitions, that destroys the scaling gains from partitions.

The point is there can't be partitions with programmable scripting. Coasian boundaries are subject to destruction by entropy.

Quote from: TPTB_need_war on February 13, 2016, 07:10:44 PM

Quote from: rokkyroad on February 13, 2016, 06:53:31 PM

programming languages with formal verification systems backed by state-of-the-art theorem provers

Ah so Vitalik does realize there is a problem like the sort I am pointing out. But perhaps he has not yet realized that even 100% dependently typed scripting won't fix the problem I am claiming is inherently insoluble.