Add merkle proof fetching

book/src/proposals/leader-duplicate-block-slashing.md

@@ -178,3 +178,46 @@ shreds for slot `B`.
 4) If no version of slot `A` chains, then deserializie `S_B` to find the first
 tick `T_B`, then make a `Orphan(slot, T_B.hash, T_B.num_hashes)` request
 to get the last shred in the version of slot `A` that chains to slot `B`.
+
+### Replay Failures
+As summarized under the `Dead Slots` column family in the
+`Indexing the Column Families by Blockhash` section above, validators must now
+account for the possibility that some versions of a slot have correctness 
+issues while other versions don't.
+
+Let `V_A` be a version of slot `A` with blockhash `B_A`.
+
+Assume that on replay of `V_A` the validator runs into some correctness issue 
+(entry verification failure, bad tick count, etc.) while replaying the entries.
+
+Define `S` to be the set of shreds as follows:
+
+1) On entry verification failures of entries`E1` and `E2`:
+
+Let `S` be the set of all shreds that contain any part of `E1` and `E2`.
+
+2) On TransactionError in some entry `E`:
+
+Let `S` be the set of all shreds that contain any part of `E`.
+
+3) On Blocktree inability to deserialize an entry from a set of shreds:
+
+Let `S` be the FEC set that failed to deserialize
+
+4) On BlockErrors (InvalidTickCount, InvalidHashCount, TrailingEntry, etc.)
+on some entry `E`
+
+Let `S` be the set of all shreds that contain any part of `E`.
+
+
+Protocol: 
+
+1) The validator queries for a merkle proof of all shreds in `S` to prove that
+all the offending shreds were indeed part of the version `A` with blockhash `B_A`.
+
+2) If the merkle proof checks out, we add `(A, B_A)` to the `Dead Slots` column
+family. No further forks chaining to this slot will be played.
+
+3) If the merkle proof instead shows that there is a different version of some
+shred in `S`, that means we got maliciously sent the wrong shred for version 
+`B_A`. We must then drop those wrong shreds and repair them again.