Quote from: Fuserleer on March 20, 2016, 08:17:31 PM

The sharding solution they have proposed, whereby contracts can only interact in the same shard, will work just fine. That of course brings with it usability issues, whereby a contract/account on shard 5 can't interact in any way with a contract/account on shard 10.

Enabling contracts to interact across shards is a different level of hard altogether, and I'm at the tipping point of accepting that it can't be achieved after looking at the problem myself for the past year or so.

As many know, eMunie has partitioning (our name for sharding) of transactions, and these partitions can interact with accounts in a different partition. Great you might think, then just apply the same mechanics to contracts.

Unfortunately its not that simple, as with transactions you are managing a single, known state (the balance) that is native to the system, so you are able to build functionality and algorithms that leverage those properties to enable cross partition/sharding interactions. With a contract its much more complex, as a contract may have many states, all of which will have an unknown/indeterminable function, and be arbitrary in nature.

If the states of a contract are arbitrary, the system can never know what all the states might be (because they are defined by the contract creator). Nor can it know the rules that govern them due to the same reason (the rules too are arbitrary), thus there is no way to enforce consensus across shards. Therein lies the root of the problem.

For this to be possible at all would require that the system knows, natively, all possible states for any contract that may ever exist, and the rules that govern those states....

I endorse this. The user scripting is what breaks the ability to do cross-partitioned (cross-sharded) decentralized. Of course centralized or every validator validating every partition works but defeats the entire point of decentralized block chains and reliability by eliminating trust, reputation, and the power vacuum failure modes thereof.

Upthread I had explained how I think Fuserleer is managing handle cross-partitioning for ledger balance. In theory this could be applied to the gas if the gas wasn't also intertwined with the contract state transitions, but the gas must be so intertwined.

Also in that upthread post, I conjectured (having not seen his design specification yet) why I think Fuserleer's attempt will have to forsake long term Consistency or Access for those transaction trees which can't converge across all Partitions. Fuserleer apparently reduces the convergence problem to per-transaction graph, versus per-block. In other words, I conjecture that eMunie's design purports to isolate transaction trees which are conflicting and converges only on those transaction trees which are non-conflicting (in terms of a double-spend) across all partitions. i am expecting collatoral damage or other issue, but I must wait for the full specification before I can really comment meaningfully more than just wild conjecture based on what Fuserleer has written about eMunie's design in various threads.

I don't feel like searching the thread for the post I am referring to.