This document describes how to we plan to upgrade from the Rchain State Proposal to a sharded version. The word name group and shard are used interchangeably.
...
The nomenclature still needs some work. For now, I've drawn a potential valid Rchain blockDAG simulation below.
The time axis goes from bottom to top and the horizontal axis is built of columns of individual shards - I tried to keep it so that the columns are clear but it sort of gets messier towards the top. The diagram provides an example of how child shards S1, S2, and S3 are forked off the root shard. It then gives an example of how a sub-hierarchy change is made: someone deploys a contract that has names that span S1 and S2. If one shard dominates over another, then the former can force the latter to accept a merge block and thus change its fork choice. Thus by the end of the diagram the root shard dominates over \{S1, S2\} and S3. And \{S1, S2\} dominates over S1 and S2.
...
Sharding introduces "merge blocks", blocks that are validated across shards in the sharding hierarchy. Merge blocks can only occur along the branch lines of the sharding hierarchy. For example, from the above diagram, we can have a merge block between "S1" and "{S1,S2}"; "S2" and "{S1,S2}"; and "S1", "S2", and "{S1,S2}". But not "S1" and "S2". A "merge block" spans multiple shards and is part of the blockchain of all the constituent shards. Instead of a single state root, each merge block will have multiple state roots (and most importantly multiple Casper contract instances) - one for each shard it merges. Each Casper contract defines the master shard (set) of its children blocks. The master shard (set) chain must not contain cycles.