Quote from: TPTB_need_war on March 04, 2016, 12:14:39 PM

Quote from: ilia7777 on March 04, 2016, 07:48:10 AM

Back to partitions, I've read about sharding today, the post was written by Vitalik and it describes exactly what is being implemented. It said clearly that if a call from one transaction group is made to another transaction group it would produce "out of range" exception. Its not clear to me why you even discuss the possibility of such calls that would be executed.

Review the upthread discussion of the impossibility of sharding the gas.

Why do I have to repeat myself? You claim to be a programmer of 10 years. You can't remember what you read 2 pages ago in the thread Huh

Quote from: ilia7777 on March 04, 2016, 07:48:10 AM

The second thing I did I watched an interview with Vitalik where he said that in Ethereum 2.0 they are thinking about getting away from every node executing every transaction. In a paper you quoted before exactly such solution is described with double decker blockchain where one layer is used to simply store the state. This seems to be the exact solution they are going to adopt.

I will repeat again for the 10th time in this thread. Every validator must be able to validate the entire history of the lineage of transactions for the shard that validator is responsible for. Otherwise that validator can't be sure it is not going to lose its funds (i.e. electricity for PoW or deposit for the proposed consensus-by-betting) because it approved an invalid transaction due to some lie in the history as trusted but not validated. Combine this with the impossibility of sharding the gas as explained already to you. The white paper you referred to is for a crypto currency, thus there is no gas (from other shard) that must be atomic with the execution of the sharded script (as was explained to you upthread!).

Quote from: ilia7777 on March 04, 2016, 07:48:10 AM

need_war you need to understand that there are no problems in computer science that can't be solved.

False. Make the Halting Problem decideable.

Please don't insult my superior intelligence and experience again with your (ostensibly not even freshman level) learning curve (and the inability to remember the famous Halting problem from freshman CompSci at the university).

Quote from: TPTB_need_war on March 04, 2016, 01:19:10 PM

Quote from: hv_ on March 04, 2016, 07:53:54 AM

Quote from: ilia7777 on March 04, 2016, 07:48:10 AM

Back to partitions, I've read about sharding today, the post was written by Vitalik and it describes exactly what is being implemented. It said clearly that if a call from one transaction group is made to another transaction group it would produce "out of range" exception. Its not clear to me why you even discuss the possibility of such calls that would be executed.

The second thing I did I watched an interview with Vitalik where he said that in Ethereum 2.0 they are thinking about getting away from every node executing every transaction. In a paper you quoted before exactly such solution is described with double decker blockchain where one layer is used to simply store the state. This seems to be the exact solution they are going to adopt.

need_war you need to understand that there are no problems in computer science that can't be solved. If particular architecture doesn't work they will change it to the one that works. The whole thing about blockchain with all the excitement around it seems to me like we say in Russia "sucked out of finger" . But that doesn't mean that Ethereum is not gonna work and that we won't be able to make money on it. Crazy youngsters like Vitalik will develop lots of shit on Ethereum just because people have nothing better to do. No point to talk further, what I studied so far is enough for me to start pouring money in mining farm for it.

Than they need to come over the CAP theorem - could be a bit tricky.

'Proof' is there:

https://bitcointalk.org/index.php?topic=1319681.msg13490710#msg13490710

Grin

Let's talk generalities that apply to any block chain partitioning system.

As monsterer and I discussed upthread, it is possible to partition transactions (and even scripts as "transactions") as long as the partition state is not shared between partitions. Once you need to share any state between partitions (e.g. gas), then those partitions need to validate all the history of each other, otherwise the Prisoner's Dilemma is created and the Nash equilibrium is lost.

Fuserleer claimed he had developed a more granular data structure (not precisely a block chain, although discussion revealed the difference from a block chain was semantic illusion) wherein he can isolate only those histories that are dependent and thus I presume more efficiently merge partitions by validating only the relevant history for the state that is being moved cross-partition. That is one way to go that is different than the design I am contemplating (assuming I have described his design correctly since he hasn't revealed the details). Fuserleer's design would I presume in theory allow to partition validation and only validate what you need to when you need to, but there are several issues I can expect:

The miner/validator may not have the financial incentive to include transactions which have a high validation burden.
The economic problem of validation centralizing over time remains, thus it seems the attempt to keep them decentralized by using partitioning is pointless.
The unbounded amount of delayed validation work has implications similar to delays seen when garbage collection locks up your browser for 5 minutes.

I had also pointed out upthread a more high-level reason that scripts can't be assumed to have isolated state due to uncontrollable externalities, but even if someone argues I am incorrect on that point, it is unarguable the gas can't be sharded (again even if we apply Fuserleer's unreleased design, it will economically centralize).