More MGR (#464)

docs/merry-go-round-sync.md

@@ -15,11 +15,41 @@ The process of syncing happens in cycles. During each cycle, all participants at
 Ethereum state to each other. Therefore the duration of one cycle for the Ethereum mainnet is likely to be some hours.
 Cycle is divided into ticks. For convinience, we can say that each ticks starts after the mining of certain block, and lasts
 for some predetermined amount of time, let's say, 30 seconds. This definition means that the ticks will often overlap, but not
-always, as shown onn the picture below.
+always, as shown on the picture below.
 
 ![cycles-and-ticks](mgr-sync-1.png)
 
+If chain reorgs occur, and the timings of recent Ethereum blocks change as a result, we can accept these rules to prevent
+the reorgs to be used to disrupt the sync. Imaginge the tick started at block A (height H), and then due to reorg, block A
+was replaced by block B (also height H).
 
+ * If timestamp(B) < timestamp(A), the tick does not shorten, but proceeds until timestamp(A) + tick_duration.
+
+ * If timestamp(B) >= timestamp(A), the tick gets extended to proceed until timestamp(B) + tick_duration.
+
+ As one would guess, we try to distribute the entire Ethereum state into as many pieces as many ticks there are in one cycle.
+ Each piece would be exchanged over the duration of one tick. Obviously, we would like to make the distribution as even as possible.
+ Therefore, there is still a concern about situations when the blocks are coming in quick sucession, and the ticks corresponding
+ to those blocks would largely overlap.
+
+## Sync schedule
+
+When we split the entire Ethereum state into pieces and plan to exchange each piece during one tick, we are creating a sync
+schedule. Sync schedule is a mapping from the tick number (which can be derived from the block number) to the piece of state.
+These pieces need to be efficient to extract from the State Database (for a seeder), and add to the State Database (for a leecher).
+Probably the most convinient way of specifying such a piece of state is a pair of bounds - lower bound and upper bound.
+Each of the bounds would correspond to either Keccak256 hash of an address, or to a combination of Keccak256 hash of an address,
+and Keccak256 hash of a storage location in some contract. In other words, there could be four types of specification for a piece
+of state:
+
+1. `[ keccak256(address1); keccak256(address2) )`
+2. `[ keccak256(address1), keccak256(location1); keccak256(address2) )`
+3. `[ keccak256(address1); keccak256(address2), keccak256(location2) )`
+4. `[ keccak256(address1), keccak256(location1); keccak256(address2), keccak256(location2) )`
+
+In the last type, addresses `address1` and `address2` may mean the same address. If they mean different addresses, then `location1` and `location2` may mean the same locations.
 
 ## How will seeders produce sync schedule
 
+Seeders should have the ability to generate the sync schedule by the virtue of having the entire Ethreum state available. No
+extra coordination should be necessary.