Quote from: Fuserleer on February 12, 2016, 02:46:58 PM

I've viewed information/presentations etc about Eth's proposal for partitioning/sharding and its quite interesting. If you really dig into how they set it up, it seems to apply some similar ways of thinking as my channeled ledger proposals, and applying them to a block chain. That is, no UTXO, instead tracking of "account balances" (which they already have in V1.0) and accounts "living" in a particular partition. They fall short by trying to apply this to a block chain.

[...]

With a channeled ledger, transactions are "independent" elements and can be transmitted directly to the nodes that need them...

[...]

There is still the matter of the cross-partition problem, and it seems that the Ethereum proposals intend to solve it by way of Merkle receipts and Patricia trees. This approach may be successful, I had a similar solution in mind if the preferred implementation of compact global state using zk-proofs to prove an account has sufficient balance was impossible. It hasn't hit any show stopper problems as yet though, so I've not looked deeper into the alternative solution/s and their implementation.

[...]

I want to set aside the performance issues for the moment and focus on the impossibility of granting both Partition tolerance and retaining Consensus/Consistency and Availability/Access, which the CAP theorem states is impossible. I know many developers want to delude themselves into believing the CAP theorem only applies at the a lower level semantic layer of the distributed network, but I intend to challenge your explanation in order to prove that is a delusion.

It is my understanding from evaluating possible designs, that if transactions are allowed to span partitions (a.k.a. shards), then it is impossible to prevent a double-spend by spending on two or more partitions (i.e. maintain Consistency) unless all partitions verify each other, which of course defeats the scaling benefits that partitions were intended to provide (and really just eliminates the partition tolerance). And if transactions are not allowed to span partitions (i.e. they can only transact to the validators in their partition), then it is impossible for a transaction to become unstuck (i.e. regain Availability) if all the authorized validators for the partition are censoring the transaction, are unreachable or have stopped being validators. It is possible to change the set of validators periodically such as based on the progression of the block chain (e.g. Dash Evolution quorum), but this makes it impossible to objectively detect a 51% attack (which is one of the aspects my design attempts to improve). I solved this issue by allowing BOTH partitioned transactions and spanning transactions where the latter conforms to the normal Satoshi longest chain rule (but with my unprofitable PoW improvement). Also there remains the issue that there must be a global consensus that all partitions were validated correctly, yet if all partitions validate each other, then the scaling advantage of having partitions is lost. You mention Merkel and Patricia trees to provide cross-partition transactions? I think it is impossible to achieve my solution and provide security without a (either PoW or PoS) chain, i.e. that Partion tolerance must be limited to intra-block because there still needs to be a consensus around whether a transaction has spanned a partition and thus if we introduce partition tolerance interblock then we will lose either Consistency or Availability. Also note PoS has Nash equilibrium failure modes which PoW doesn't have, so I chose PoW but improved it by making it unprofitable.

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 Huh

Quote from: https://blog.ethereum.org/2015/12/24/understanding-serenity-part-i-abstraction/

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.