The following post intends to show that scaling of checkpoint chains is possible and integratable with a sharded world. A checkpoint chain is a indexed list of checkpoints, where each checkpoint references the previous one. See also https://govern.iota.org/t/tip-selection-variation-for-decentralized-checkpoints/265. Here it is assumed that checkpoints are made through some binary voting mechanism, see https://govern.iota.org/t/making-decentralized-checkpoints-with-fpc-and-drng/227.
In order to guarantee Sybil protection a node’s mana needs to be dedicated to a given shard, or at least split between shards. We assume that there is at least some weak sort of consensus, whether a node is allowed to be responsible for a shard or not. Furthermore, for initial discussion it is required here, that all nodes of a shard follow all txs in the directly neighboring shards. In order to allow for parallel checkpoint chains we require that there is a discrete splitting of shards according to the shard marker.
Splitting may be caused by the network being continuously in proximity of a network congestion. Lets assume that there is a certain threshold \tau for the maximum bandwidth in a shard. Nodes may then request on possibly regular intervals (such as once every checkpoints) a vote on splitting the shard if the average bandwidth is above of it. If the vote succeeds the shard splits according to node-ID, geographic location, optimising the mana distribution or throwing dices. Both shards build on the previous checkpoint chain.
Merging may be caused because the shard’s network is continuously below a minimum network traffic. Lets assume there is a mechanism to identify which shards are possible candidates for merging (e.g. through shard marker, the network congestion level of neighboring shards, optimisation of mana distribution). Shard A, which potentially needs to merge can vote on whether it should merge with a given shard B. The result can be recorded on the tangle, more particularly in the latest checkpoints of A. Since all nodes in B follow the txs in A (see first paragraph) nodes will form an initial opinion whether to merge or not and will after some time initiate also a voting round. Again this can be recorded on the tangle e.g. in the data of B ’s checkpoints. Finally, if B accepted and checkpoints are marked for merging, the next checkpoint candidates reference both A and B’s last checkpoint and nodes consider votes from both A and B.