Motivation

...

The dominance hierarchy of the shards will follow the natural tree structure for local groups, i.e. if A, B, and C are local groups and A = B ∪ C (note that this also implies that A = A ∪ B and A = A ∪ C) then a shard serving A is dominant over a shard serving B or C. When code is deployed to the platform, it must run on all shards which serve the local groups it uses, therefore it will need to exist in a merge block which includes all of those shards. For example, if A, B and C are local groups as above and all of them are served by different shards then a contract that contains processes localized to B and C will have local group equal to A (because A = B ∪ C)  and will need to join the platform via a merge block between all three shards serving those local groups. Note that the root of the local group tree is "rchain://", which is not a valid URI and therefore not a shard. If two shards wish to communicate and the union of their corresponding local groups is "rchain://" then they will need to use a merge block, but the dominance will also need to be specified since it cannot be inferred from the tree.

Notice that this scheme meets the desired property that a developer is insulated from the implementation. A developer simply accesses resources using familiar file-system-like syntax and the deployment process behind the scenes can figure out where that code needs to exist to be served properly. However, if the developer happens to cross shard boundaries with their resource usage then merge blocks become involved which may increase the cost or time to run the code and improving on that performance would require knowing about the specifics of the sharding.

Also note that as an optimization to the deployment process, separable processes (defined briefly in the local group examples) could be deployed to their independent shards (if they exist) as this would cut down on unnecessary merge blocks.

Creating/Destroying Shards

We will assume that at genesis there is a single shard identified by `rchain://root`.

A new shard can be created by proposing a "merge block" between an existing shard (the parent) and the new shard. The merge block would contain two sets of post state information, where the second one serves as the genesis information for the newly created shard. The new genesis information includes the local group identifying the new shard, the validator bond amounts and any parts of the state taken over from the parent. The restrisction here is that the new local group must be contained in the parent (e.g. if the parent was identified by `rchain://root` then the child could identified by `rchain://root/coop` but not `rchain://coop`). Moreover, stake cannot be duplicated or destroyed, therefore the new validator set must be a subset of the parent and bond amounts must be split betweent the two. Note that these validator assignments are not permenant and validator rotation still happens in both shards as per (yet-to-be-determined) protocol rules. This operation would not be done by an average developer using the platform, but instead by one of the validators in the parent shard (perhaps because there is a volume of contracts in a particular subset of their served local group so it makes sense to isolate them). Notice that by the dominance rules the new shard cannot be finalized until it is finalized in the parent shard, meaning that the majority of validators need to agree to the split. Also note that an avergae contract developer does not notice or care about this change. Their existing code will continute to function without being modified because it will be served by either the parent, child or possibly in merge blocks between the two. The only thing which may change for them are the operating costs.

...