From d6fa659fc80abd37e065a9d564a0ec01cf84abb3 Mon Sep 17 00:00:00 2001 From: Carl Date: Mon, 23 Dec 2019 18:32:45 -0800 Subject: [PATCH] Add merkle proof fetching --- .../leader-duplicate-block-slashing.md | 53 ++++++++++++++++--- 1 file changed, 46 insertions(+), 7 deletions(-) diff --git a/book/src/proposals/leader-duplicate-block-slashing.md b/book/src/proposals/leader-duplicate-block-slashing.md index 860b116a6cb779..999caeaa4cd671 100644 --- a/book/src/proposals/leader-duplicate-block-slashing.md +++ b/book/src/proposals/leader-duplicate-block-slashing.md @@ -115,12 +115,8 @@ then the two versions must be distinguishable. An issue to note here is that if some version of a slot violates correctness before the slot is finished, then the validator does not know what the ending blockhash is and thus cannot store the slot as dead. In these cases we can drop -the entire slot and wait for repair. Because repair will include a merkle proof -of each shred for each repair (which includes the final blockhash `B`), -then the advantage there is if a repaired shred fails to play, we know the -entire version of that slot with blockhash `B` is no good, and we can store -`(slot, B)` in the Dead Slots column family and ignore all forks that build on - top of `(slot, B)`. +the entire slot and wait for repair. More details in the `Replay Failures` +section below. ### Repairing Multiple versions of the Same Slot Repair is augmented with a blockhash. The various types of repairs: @@ -175,6 +171,49 @@ to avoid waiting for multiple shreds). version of `B` is detected before this version is completed, we drop all the shreds for slot `B`. 3) For all possible versions of slot `A` see which version chains to `E_B` -4) If no version of slot `A` chains, then deserializie `S_B` to find the first +4) If no version of slot `A` chains, then deserialize `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. \ No newline at end of file