The Ethereum Paradox

[TPTB_need_war]

[...]

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-academic

http://www.theguardian.com/technology/2015/dec/09/bitcoin-founder-craig-wrights-home-raided-by-australian-police?CMP=twt_a-technology_b-gdntech


Edit: and add Gregory Maxwell (nullc) to list of people who don't understand Turing-completeness:

   He's discussion at the All Star Panel, was very odd, and not in any way lucid or clear. Here is /u/nullc take on a transcript I made. https://www.reddit.com/r/Bitcoin/comments/3w027x/dr_craig_steven_wright_alleged_satoshi_by_wired/cxsfy8p

[TPTB_need_war]

I do not find the reason for the recent rise. Did anybody find why the price rose so much recently?

Possibility is they need to raise the ETH price so they can sell some because they had exhausted their $millions in funding from the ICO vaporware pre-sale:

https://www.reddit.com/r/ethereum/comments/45bhus/so_the_ethereum_foundation_can_now_fund_itself/czwqr30?context=3

Another reason one might imagine that perhaps Vitalik could be corrupted to participate in the pump by emphasizing Casper vaporware and hiding the fact they were not close to solving the fundamental technological issues. And yet they were running out of money (but not now if they can sustain these higher prices for ETH and/or have sold a lot of ETH on this price rise ... in either case selling ETH to bag holders).

So one might imagine perhaps the insiders have cleverly realized they could control Vitalik so they would be able to cash out.

The professionals play these games very strategically. You bag holders have no chance against them (unless of course you sell early enough and get out the door before the rest of the bag holders). Note I am not short ETH, but I did play this game strategically also. I waited for ETH to reach a nosebleed price before I started to reveal the truth more aggressively. This is a warning to these professionals (hucksters) to not fuck with my coin when I release it.

Edit: I have just challenged Vitalik directly:

https://www.reddit.com/r/ethereum/comments/45bhus/so_the_ethereum_foundation_can_now_fund_itself/czx5jej

Edit#2: Vitalik admits they've been selling on the pump (in violation of escrow?). And note he mentions raising monthly budget so more money in their pockets (see how this works, I'll scratch your back if you scratch mine!):

https://www.reddit.com/r/ethereum/comments/45bhus/so_the_ethereum_foundation_can_now_fund_itself/czwqr30

In Ethereum insiders' own words[promotional hype] (ostensibly in direct violation of the Howey test which perhaps makes ETH illegal unregistered investment securities?):

Vitalik Buterin, Ethereum's founder, has summarised the reason for the growing price and demand of the cryptocurrency:

   “Application developers are seeing that the Ethereum platform is a very powerful technology that offers advantages in a very broad set of areas. There has been a lot of interest in Ethereum applications over the last few months; particularly in January the number of individuals and companies interested in Ethereum private chains, Ethereum-based financial applications, smart contracts, IoT, etc, has all increased greatly.”

According to Roman Mandeleil, ether.camp CEO and founder, there are two reasons for Ethereum’s early success:

   “The first reason is that the people have come to trust that the network is solid and reliable. Ethereum has had eight months of live network to prove just that.

    Secondly, users have noticed that the network is being constantly improved with new products and new services, which is a major attraction for new users who eventually buy ether and consequently push up the price.”

[illodin]

What should the Ethereum team do now? Admit that they failed and call it quits, downgrade the feature list and try to continue, continue as if nothing happened and hope some divine intervention will solve the issues?

[generalizethis]

What should the Ethereum team do now? Admit that they failed and call it quits, downgrade the feature list and try to continue, continue as if nothing happened and hope some divine intervention will solve the issues?

Maybe they can build a soda machine.

[illodin]

What should the Ethereum team do now? Admit that they failed and call it quits, downgrade the feature list and try to continue, continue as if nothing happened and hope some divine intervention will solve the issues?

Maybe they can build a soda machine.

Or perhaps they should beg for some donations so they could create a GUI, I've heard those are the only thing standing in the way of inevitable mass adoption.

[YarkoL]

I do not find the reason for the recent rise. Did anybody find why the price rose so much recently?

Bitcoin block size war and fatigue. I've heard a lot of ppl
dumping their btc for what looks like a serious
contender.

[CIYAM]

In regards to the ordering of "script execution" the experience that the CIYAM team has had with the development of AT (the first "live" Turing complete system that has been running for over a year now) it is actually just another consensus rule.

(i.e. it is neither a difficult problem to solve nor very hard to verify)

I am not a fan of the Ethereum VM because I think it is overly complicated (the AT virtual CPU is a much simpler implementation) but I don't doubt that it can work in a deterministic way just as AT has been doing perfectly.

It should be noted that I am not very familiar with Ethereum beyond the original paper (which I read way back before many people had heard of it) so if the current design has some new problems in regards to the ordering of script execution then that could be entirely possible.

[TPTB_need_war]

In regards to the ordering of "script execution" the experience that the CIYAM team has had with the development of AT (the first "live" Turing complete system that has been running for over a year now) it is actually just another consensus rule.

(i.e. it is neither a difficult problem to solve nor very hard to verify)

My point was that once partitions are introduced, they can't be kept orthogonal due to externalities, thus partitions can't be introduced. It is only simple because you didn't add partitions. But w/o partitions the scalability isn't attainable.

Notwithstanding partitions, I would be very curious to see how you ordered script execution since there is no synchrony in a distributed system. Again I refer you to this page:

http://www.multichain.com/blog/2015/11/smart-contracts-slow-blockchains/

[CIYAM]

My point was that once partitions are introduced, they can't be kept orthogonal due to externalities, thus partitions can't be introduced. It is only simple because you didn't add partitions. But w/o partitions the scalability isn't attainable.

Okay - (see my final paragraph after I edited) - so yes with partitions I would think that does change the picture.

IMO scalability is best achieved by having many separate blockchains and using ACCT to transfer tokens between them (that is of course perhaps a harsher method of dividing things up).

[andulolika]

All this ethereum hyp and pump will probably end up bad, ill just keep buying clams.

[TPTB_need_war]

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.

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.

[monsterer]

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).

Miners decide the order of transactions within a block - unless the block gets orphaned, this remains fixed. Block ordering in PoW chains is eventual, which implies the deeper a block gets embedded in the chain the higher the probability it won't be reordered. I don't know if etherium scripts start executing after a set number of confirmations, but they almost certainly should do to reduce the probability of the ordering changing.

[TPTB_need_war]

Miners decide the order of transactions within a block - unless the block gets orphaned, this remains fixed. Block ordering in PoW chains is eventual, which implies the deeper a block gets embedded in the chain the higher the probability it won't be reordered. I don't know if etherium scripts start executing after a set number of confirmations, but they almost certainly should do to reduce the probability of the ordering changing.

I expected you to write that. That is why I wrote this rebuttal before you wrote your post:

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.

[monsterer]

Miners decide the order of transactions within a block - unless the block gets orphaned, this remains fixed. Block ordering in PoW chains is eventual, which implies the deeper a block gets embedded in the chain the higher the probability it won't be reordered. I don't know if etherium scripts start executing after a set number of confirmations, but they almost certainly should do to reduce the probability of the ordering changing.

I expected you to write that. That is why I wrote this rebuttal before you wrote your post:

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.

I was talking about PoW chains - casper is a horrible idea IMO.

[TPTB_need_war]

Miners decide the order of transactions within a block - unless the block gets orphaned, this remains fixed. Block ordering in PoW chains is eventual, which implies the deeper a block gets embedded in the chain the higher the probability it won't be reordered. I don't know if etherium scripts start executing after a set number of confirmations, but they almost certainly should do to reduce the probability of the ordering changing.

I expected you to write that. That is why I wrote this rebuttal before you wrote your post:

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.

I was talking about PoW chains - casper is a horrible idea IMO.

Okay let's replace PoS consensus-by-betting with Satoshi's PoW. So the problem remains every full node needs to validate every script (which can't scale). If we instead split validators into partitions, then they can't all agree on adding the other partitions to a block unless they've all validated all the scripts thus destroying the scaling advantage of having partitions. If we could assume the partitions can't impact each other in terms of incorrect validation impacting the output a script which impacts the input of another script in another partition, then the partitions wouldn't care to validate each other. But I showed that with scripting, it is impossible to know whether scripts in different partitions impact each other. The externalities that the block chain can't know means it can't guarantee the partitions are bounded (i.e. self-contained).

In short, if the partitions can impact each other, then all full nodes must validate/verify all scripts. Thus partitions are useless for scaling.

Whereas with the directed acyclic graphs that are crypto asset transfer, we can keep these self-contained in a partition, thus we can use partitions to do scaling.

[monsterer]

Okay let's replace PoS consensus-by-betting with Satoshi's PoW. So the problem remains every full node needs validate every script. If we instead split validators into partitions, then they can't all agree on adding the other partitions to a block unless they've all validated all the scripts thus destroying the scaling advantage of having partitions. If we could assume the partitions can't impact each other in terms of incorrect validation impacting the output a script which impacts the input of another script in another partition, then the partitions wouldn't care to validate each other. But I showed that with scripting, it is impossible to know whether scripts in different partitions impact each other. The externalities that the block chain can't know means it can't guarantee the partitions are bounded (i.e. self-contained).

In short, if the partitions can impact each other, then all full nodes much validate/verify all scripts. Thus partitions are useless for scaling.

Partitions in PoW are bad because the hashrate of the entire network gets split by the number of partitions, meaning each individual partition is weaker than the whole unpartitioned network would have been. In fact, the strength of the network tends towards 0 as the number of partitions tends towards infinity.

[TPTB_need_war]

Okay let's replace PoS consensus-by-betting with Satoshi's PoW. So the problem remains every full node needs validate every script. If we instead split validators into partitions, then they can't all agree on adding the other partitions to a block unless they've all validated all the scripts thus destroying the scaling advantage of having partitions. If we could assume the partitions can't impact each other in terms of incorrect validation impacting the output a script which impacts the input of another script in another partition, then the partitions wouldn't care to validate each other. But I showed that with scripting, it is impossible to know whether scripts in different partitions impact each other. The externalities that the block chain can't know means it can't guarantee the partitions are bounded (i.e. self-contained).

In short, if the partitions can impact each other, then all full nodes much validate/verify all scripts. Thus partitions are useless for scaling.

Partitions in PoW are bad because the hashrate of the entire network gets split by the number of partitions, meaning each individual partition is weaker than the whole unpartitioned network would have been. In fact, the strength of the network tends towards 0 as the number of partitions tends towards infinity.

Not necessarily. If the partitions are provably self-contained (e.g. no spending between partitions thus no possible double-spend conflicts between partitions) then all partitions can be added to the same block without having partitions validate each other.

The problem for scripting is it can't be proven to be self-contained in the partition due to externalities (which even convert Bitcoin scripting to Turing complete).

[monsterer]

Not necessarily. If the partitions are provably self-contained then all partitions can be added to the same block without having partitions validate each other.

As long as the block producers are aware of all partitions, this is valid.

[TPTB_need_war]

Not necessarily. If the partitions are provably self-contained then all partitions can be added to the same block without having partitions validate each other.

As long as the block producers are aware of all partitions, this is valid.

But do they have an incentive to? Is the Nash equilibrium lost?

This was one of the issues I had to work through in my design.

[monsterer]

But do they have an incentive to? Is the Nash equilibrium lost?

This was one of the issues I had to work through in my design.

I suppose you could award subsidy based on the number of partitions you include in a block - this is actually similar to how the ethereum GHOST variant works atm.