Add blocktree and repair_service to SUMMARY.md (#4738)

book/src/SUMMARY.md

@@ -58,6 +58,7 @@
   - [Validator](validator-proposal.md)
 
 - [Implemented Design Proposals](implemented-proposals.md)
+  - [Blocktree](blocktree.md)
   - [Cluster Software Installation and Updates](installer.md)
   - [Deterministic Transaction Fees](transaction-fees.md)
   - [Fork Selection](fork-selection.md)
@@ -66,4 +67,5 @@
   - [Passive Stake Delegation and Rewards](passive-stake-delegation-and-rewards.md)
   - [Persistent Account Storage](persistent-account-storage.md)
   - [Reliable Vote Transmission](reliable-vote-transmission.md)
+  - [Repair Service](repair-service.md) 
   - [Testing Programs](testing-programs.md)

book/src/repair-service.md

@@ -35,9 +35,9 @@ The different protocol strategies to address the above challenges:
         * Insert an empty `SlotMeta` in blocktree for `p.slot` if it doesn't already exist.
         * If `p.slot` does exist, update the parent of `p` based on `parents`
 
-        Note: that once these empty slots are added to blocktree, the `Blob Repair` protocol should attempt to fill those slots.
+    Note: that once these empty slots are added to blocktree, the `Blob Repair` protocol should attempt to fill those slots.
 
-        Note: Validators will only accept responses containing blobs within the current verifiable epoch (epoch the validator has a leader schedule for).
+    Note: Validators will only accept responses containing blobs within the current verifiable epoch (epoch the validator has a leader schedule for).
 
 3. Repairmen (Addresses Challenge #3):
     This part of the repair protocol is the primary mechanism by which new nodes joining the cluster catch up after loading a snapshot. This protocol works in a "forward" fashion, so validators can verify every blob that they receive against a known leader schedule.