github.com/Team-Kujira/tendermint@v0.34.24-indexer/spec/light-client/attacks/isolate-attackers_001_draft.md (about) 1 2 # Lightclient Attackers Isolation 3 4 > Warning: This is the beginning of an unfinished draft. Don't continue reading! 5 6 Adversarial nodes may have the incentive to lie to a lightclient about the state of a Tendermint blockchain. An attempt to do so is called attack. Light client [verification][verification] checks incoming data by checking a so-called "commit", which is a forwarded set of signed messages that is (supposedly) produced during executing Tendermint consensus. Thus, an attack boils down to creating and signing Tendermint consensus messages in deviation from the Tendermint consensus algorithm rules. 7 8 As Tendermint consensus and light client verification is safe under the assumption of more than 2/3 of correct voting power per block [[TMBC-FM-2THIRDS]][TMBC-FM-2THIRDS-link], this implies that if there was an attack then [[TMBC-FM-2THIRDS]][TMBC-FM-2THIRDS-link] was violated, that is, there is a block such that 9 10 - validators deviated from the protocol, and 11 - these validators represent more than 1/3 of the voting power in that block. 12 13 In the case of an [attack][node-based-attack-characterization], the lightclient [attack detection mechanism][detection] computes data, so called evidence [[LC-DATA-EVIDENCE.1]][LC-DATA-EVIDENCE-link], that can be used 14 15 - to proof that there has been attack [[TMBC-LC-EVIDENCE-DATA.1]][TMBC-LC-EVIDENCE-DATA-link] and 16 - as basis to find the actual nodes that deviated from the Tendermint protocol. 17 18 This specification considers how a full node in a Tendermint blockchain can isolate a set of attackers that launched the attack. The set should satisfy 19 20 - the set does not contain a correct validator 21 - the set contains validators that represent more than 1/3 of the voting power of a block that is still within the unbonding period 22 23 # Outline 24 25 **TODO** when preparing a version for broader review. 26 27 # Part I - Basics 28 29 For definitions of data structures used here, in particular LightBlocks [[LCV-DATA-LIGHTBLOCK.1]](https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md#lcv-data-lightblock1), cf. [Light Client Verification][verification]. 30 31 # Part II - Definition of the Problem 32 33 The specification of the [detection mechanism][detection] describes 34 35 - what is a light client attack, 36 - conditions under which the detector will detect a light client attack, 37 - and the format of the output data, called evidence, in the case an attack is detected. The format is defined in 38 [[LC-DATA-EVIDENCE.1]][LC-DATA-EVIDENCE-link] and looks as follows 39 40 ```go 41 type LightClientAttackEvidence struct { 42 ConflictingBlock LightBlock 43 CommonHeight int64 44 } 45 ``` 46 47 The isolator is a function that gets as input evidence `ev` 48 and a prefix of the blockchain `bc` at least up to height `ev.ConflictingBlock.Header.Height + 1`. The output is a set of *peerIDs* of validators. 49 50 We assume that the full node is synchronized with the blockchain and has reached the height `ev.ConflictingBlock.Header.Height + 1`. 51 52 #### **[FN-INV-Output.1]** 53 54 When an output is generated it satisfies the following properties: 55 56 - If 57 - `bc[CommonHeight].bfttime` is within the unbonding period w.r.t. the time at the full node, 58 - `ev.ConflictingBlock.Header != bc[ev.ConflictingBlock.Header.Height]` 59 - Validators in `ev.ConflictingBlock.Commit` represent more than 1/3 of the voting power in `bc[ev.CommonHeight].NextValidators` 60 - Then: A set of validators in `bc[CommonHeight].NextValidators` that 61 - represent more than 1/3 of the voting power in `bc[ev.commonHeight].NextValidators` 62 - signed Tendermint consensus messages for height `ev.ConflictingBlock.Header.Height` by violating the Tendermint consensus protocol. 63 - Else: the empty set. 64 65 # Part IV - Protocol 66 67 Here we discuss how to solve the problem of isolating misbehaving processes. We describe the function `isolateMisbehavingProcesses` as well as all the helping functions below. In [Part V](#part-v---Completeness), we discuss why the solution is complete based on result from analysis with automated tools. 68 69 ## Isolation 70 71 ### Outline 72 73 > Describe solution (in English), decomposition into functions, where communication to other components happens. 74 75 #### **[LCAI-FUNC-MAIN.1]** 76 77 ```go 78 func isolateMisbehavingProcesses(ev LightClientAttackEvidence, bc Blockchain) []ValidatorAddress { 79 80 reference := bc[ev.conflictingBlock.Header.Height].Header 81 ev_header := ev.conflictingBlock.Header 82 83 ref_commit := bc[ev.conflictingBlock.Header.Height + 1].Header.LastCommit // + 1 !! 84 ev_commit := ev.conflictingBlock.Commit 85 86 if violatesTMValidity(reference, ev_header) { 87 // lunatic light client attack 88 signatories := Signers(ev.ConflictingBlock.Commit) 89 bonded_vals := Addresses(bc[ev.CommonHeight].NextValidators) 90 return intersection(signatories,bonded_vals) 91 92 } 93 // If this point is reached the validator sets in reference and ev_header are identical 94 else if RoundOf(ref_commit) == RoundOf(ev_commit) { 95 // equivocation light client attack 96 return intersection(Signers(ref_commit), Signers(ev_commit)) 97 } 98 else { 99 // amnesia light client attack 100 return IsolateAmnesiaAttacker(ev, bc) 101 } 102 } 103 ``` 104 105 - Implementation comment 106 - If the full node has only reached height `ev.conflictingBlock.Header.Height` then `bc[ev.conflictingBlock.Header.Height + 1].Header.LastCommit` refers to the locally stored commit for this height. (This commit must be present by the precondition on `length(bc)`.) 107 - We check in the precondition that the unbonding period is not expired. However, since time moves on, before handing the validators over Cosmos SDK, the time needs to be checked again to satisfy the contract which requires that only bonded validators are reported. This passing of validators to the SDK is out of scope of this specification. 108 - Expected precondition 109 - `length(bc) >= ev.conflictingBlock.Header.Height` 110 - `ValidAndVerifiedUnbonding(bc[ev.CommonHeight], ev.ConflictingBlock) == SUCCESS` 111 - `ev.ConflictingBlock.Header != bc[ev.ConflictingBlock.Header.Height]` 112 - TODO: input light blocks pass basic validation 113 - Expected postcondition 114 - [[FN-INV-Output.1]](#FN-INV-Output1) holds 115 - Error condition 116 - returns an error if precondition is violated. 117 118 ### Details of the Functions 119 120 #### **[LCAI-FUNC-VVU.1]** 121 122 ```go 123 func ValidAndVerifiedUnbonding(trusted LightBlock, untrusted LightBlock) Result 124 ``` 125 126 - Conditions are identical to [[LCV-FUNC-VALID.2]][LCV-FUNC-VALID.link] except the precondition "*trusted.Header.Time > now - trustingPeriod*" is substituted with 127 - `trusted.Header.Time > now - UnbondingPeriod` 128 129 #### **[LCAI-FUNC-NONVALID.1]** 130 131 ```go 132 func violatesTMValidity(ref Header, ev Header) boolean 133 ``` 134 135 - Implementation remarks 136 - checks whether the evidence header `ev` violates the validity property of Tendermint Consensus, by checking agains a reference header 137 - Expected precondition 138 - `ref.Height == ev.Height` 139 - Expected postcondition 140 - returns evaluation of the following disjunction 141 **[[LCAI-NONVALID-OUTPUT.1]]** == 142 `ref.ValidatorsHash != ev.ValidatorsHash` or 143 `ref.NextValidatorsHash != ev.NextValidatorsHash` or 144 `ref.ConsensusHash != ev.ConsensusHash` or 145 `ref.AppHash != ev.AppHash` or 146 `ref.LastResultsHash != ev.LastResultsHash` 147 148 ```go 149 func IsolateAmnesiaAttacker(ev LightClientAttackEvidence, bc Blockchain) []ValidatorAddress 150 ``` 151 152 - Implementation remarks 153 **TODO:** What should we do here? Refer to the accountability doc? 154 - Expected postcondition 155 **TODO:** What should we do here? Refer to the accountability doc? 156 157 ```go 158 func RoundOf(commit Commit) []ValidatorAddress 159 ``` 160 161 - Expected precondition 162 - `commit` is well-formed. In particular all votes are from the same round `r`. 163 - Expected postcondition 164 - returns round `r` that is encoded in all the votes of the commit 165 166 ```go 167 func Signers(commit Commit) []ValidatorAddress 168 ``` 169 170 - Expected postcondition 171 - returns all validator addresses in `commit` 172 173 ```go 174 func Addresses(vals Validator[]) ValidatorAddress[] 175 ``` 176 177 - Expected postcondition 178 - returns all validator addresses in `vals` 179 180 # Part V - Completeness 181 182 As discussed in the beginning of this document, an attack boils down to creating and signing Tendermint consensus messages in deviation from the Tendermint consensus algorithm rules. 183 The main function `isolateMisbehavingProcesses` distinguishes three kinds of wrongly signing messages, namely, 184 185 - lunatic: signing invalid blocks 186 - equivocation: double-signing valid blocks in the same consensus round 187 - amnesia: signing conflicting blocks in different consensus rounds, without having seen a quorum of messages that would have allowed to do so. 188 189 The question is whether this captures all attacks. 190 First observe that the first checking in `isolateMisbehavingProcesses` is `violatesTMValidity`. It takes care of lunatic attacks. If this check passes, that is, if `violatesTMValidity` returns `FALSE` this means that [FN-NONVALID-OUTPUT] evaluates to false, which implies that `ref.ValidatorsHash = ev.ValidatorsHash`. Hence after `violatesTMValidity`, all the involved validators are the ones from the blockchain. It is thus sufficient to analyze one instance of Tendermint consensus with a fixed group membership (set of validators). Also it is sufficient to consider two different valid consensus values, that is, binary consensus. 191 192 **TODO** we have analyzed Tendermint consensus with TLA+ and have accompanied Galois in an independent study of the protocol based on [Ivy proofs](https://github.com/tendermint/spec/tree/master/ivy-proofs). 193 194 # References 195 196 [[supervisor]] The specification of the light client supervisor. 197 198 [[verification]] The specification of the light client verification protocol 199 200 [[detection]] The specification of the light client attack detection mechanism. 201 202 [supervisor]: 203 https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/supervisor/supervisor_001_draft.md 204 205 [verification]: https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md 206 207 [detection]: 208 https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/detection/detection_003_reviewed.md 209 210 [LC-DATA-EVIDENCE-link]: 211 https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/detection/detection_003_reviewed.md#lc-data-evidence1 212 213 [TMBC-LC-EVIDENCE-DATA-link]: 214 https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/detection/detection_003_reviewed.md#tmbc-lc-evidence-data1 215 216 [node-based-attack-characterization]: 217 https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/detection/detection_003_reviewed.md#node-based-characterization-of-attacks 218 219 [TMBC-FM-2THIRDS-link]: https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md#tmbc-fm-2thirds1 220 221 [LCV-FUNC-VALID.link]: https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md#lcv-func-valid2