mirror of
https://github.com/tendermint/tendermint.git
synced 2026-01-06 21:36:26 +00:00
ci: add markdown linter (#146)
This commit is contained in:
Marko
GitHub
@@ -1,54 +1,53 @@
|
||||
# BFT Time
|
||||
|
||||
Tendermint provides a deterministic, Byzantine fault-tolerant, source of time.
|
||||
Time in Tendermint is defined with the Time field of the block header.
|
||||
Tendermint provides a deterministic, Byzantine fault-tolerant, source of time.
|
||||
Time in Tendermint is defined with the Time field of the block header.
|
||||
|
||||
It satisfies the following properties:
|
||||
|
||||
- Time Monotonicity: Time is monotonically increasing, i.e., given
|
||||
a header H1 for height h1 and a header H2 for height `h2 = h1 + 1`, `H1.Time < H2.Time`.
|
||||
- Time Validity: Given a set of Commit votes that forms the `block.LastCommit` field, a range of
|
||||
- Time Monotonicity: Time is monotonically increasing, i.e., given
|
||||
a header H1 for height h1 and a header H2 for height `h2 = h1 + 1`, `H1.Time < H2.Time`.
|
||||
- Time Validity: Given a set of Commit votes that forms the `block.LastCommit` field, a range of
|
||||
valid values for the Time field of the block header is defined only by
|
||||
Precommit messages (from the LastCommit field) sent by correct processes, i.e.,
|
||||
Precommit messages (from the LastCommit field) sent by correct processes, i.e.,
|
||||
a faulty process cannot arbitrarily increase the Time value.
|
||||
|
||||
In the context of Tendermint, time is of type int64 and denotes UNIX time in milliseconds, i.e.,
|
||||
corresponds to the number of milliseconds since January 1, 1970. Before defining rules that need to be enforced by the
|
||||
In the context of Tendermint, time is of type int64 and denotes UNIX time in milliseconds, i.e.,
|
||||
corresponds to the number of milliseconds since January 1, 1970. Before defining rules that need to be enforced by the
|
||||
Tendermint consensus protocol, so the properties above holds, we introduce the following definition:
|
||||
|
||||
- median of a Commit is equal to the median of `Vote.Time` fields of the `Vote` messages,
|
||||
where the value of `Vote.Time` is counted number of times proportional to the process voting power. As in Tendermint
|
||||
the voting power is not uniform (one process one vote), a vote message is actually an aggregator of the same votes whose
|
||||
the voting power is not uniform (one process one vote), a vote message is actually an aggregator of the same votes whose
|
||||
number is equal to the voting power of the process that has casted the corresponding votes message.
|
||||
|
||||
Let's consider the following example:
|
||||
- we have four processes p1, p2, p3 and p4, with the following voting power distribution (p1, 23), (p2, 27), (p3, 10)
|
||||
and (p4, 10). The total voting power is 70 (`N = 3f+1`, where `N` is the total voting power, and `f` is the maximum voting
|
||||
power of the faulty processes), so we assume that the faulty processes have at most 23 of voting power.
|
||||
Furthermore, we have the following vote messages in some LastCommit field (we ignore all fields except Time field):
|
||||
- (p1, 100), (p2, 98), (p3, 1000), (p4, 500). We assume that p3 and p4 are faulty processes. Let's assume that the
|
||||
`block.LastCommit` message contains votes of processes p2, p3 and p4. Median is then chosen the following way:
|
||||
the value 98 is counted 27 times, the value 1000 is counted 10 times and the value 500 is counted also 10 times.
|
||||
So the median value will be the value 98. No matter what set of messages with at least `2f+1` voting power we
|
||||
choose, the median value will always be between the values sent by correct processes.
|
||||
|
||||
We ensure Time Monotonicity and Time Validity properties by the following rules:
|
||||
- we have four processes p1, p2, p3 and p4, with the following voting power distribution (p1, 23), (p2, 27), (p3, 10)
|
||||
and (p4, 10). The total voting power is 70 (`N = 3f+1`, where `N` is the total voting power, and `f` is the maximum voting
|
||||
power of the faulty processes), so we assume that the faulty processes have at most 23 of voting power.
|
||||
Furthermore, we have the following vote messages in some LastCommit field (we ignore all fields except Time field):
|
||||
- (p1, 100), (p2, 98), (p3, 1000), (p4, 500). We assume that p3 and p4 are faulty processes. Let's assume that the
|
||||
`block.LastCommit` message contains votes of processes p2, p3 and p4. Median is then chosen the following way:
|
||||
the value 98 is counted 27 times, the value 1000 is counted 10 times and the value 500 is counted also 10 times.
|
||||
So the median value will be the value 98. No matter what set of messages with at least `2f+1` voting power we
|
||||
choose, the median value will always be between the values sent by correct processes.
|
||||
|
||||
We ensure Time Monotonicity and Time Validity properties by the following rules:
|
||||
|
||||
- let rs denotes `RoundState` (consensus internal state) of some process. Then
|
||||
- let rs denotes `RoundState` (consensus internal state) of some process. Then
|
||||
`rs.ProposalBlock.Header.Time == median(rs.LastCommit) &&
|
||||
rs.Proposal.Timestamp == rs.ProposalBlock.Header.Time`.
|
||||
|
||||
- Furthermore, when creating the `vote` message, the following rules for determining `vote.Time` field should hold:
|
||||
- Furthermore, when creating the `vote` message, the following rules for determining `vote.Time` field should hold:
|
||||
|
||||
- if `rs.LockedBlock` is defined then
|
||||
`vote.Time = max(rs.LockedBlock.Timestamp + config.BlockTimeIota, time.Now())`, where `time.Now()`
|
||||
`vote.Time = max(rs.LockedBlock.Timestamp + config.BlockTimeIota, time.Now())`, where `time.Now()`
|
||||
denotes local Unix time in milliseconds, and `config.BlockTimeIota` is a configuration parameter that corresponds
|
||||
to the minimum timestamp increment of the next block.
|
||||
|
||||
- else if `rs.Proposal` is defined then
|
||||
|
||||
- else if `rs.Proposal` is defined then
|
||||
`vote.Time = max(rs.Proposal.Timestamp + config.BlockTimeIota, time.Now())`,
|
||||
|
||||
- otherwise, `vote.Time = time.Now())`. In this case vote is for `nil` so it is not taken into account for
|
||||
the timestamp of the next block.
|
||||
|
||||
|
||||
- otherwise, `vote.Time = time.Now())`. In this case vote is for `nil` so it is not taken into account for
|
||||
the timestamp of the next block.
|
||||
|
||||
@@ -7,12 +7,12 @@ consensus protocol.
|
||||
|
||||
MacTex is Latex distribution for Mac OS. You can download it [here](http://www.tug.org/mactex/mactex-download.html).
|
||||
|
||||
Popular IDE for Latex-based projects is TexStudio. It can be downloaded
|
||||
Popular IDE for Latex-based projects is TexStudio. It can be downloaded
|
||||
[here](https://www.texstudio.org/).
|
||||
|
||||
## How to build project
|
||||
## How to build project
|
||||
|
||||
In order to compile the latex files (and write bibliography), execute
|
||||
In order to compile the latex files (and write bibliography), execute
|
||||
|
||||
`$ pdflatex paper` <br/>
|
||||
`$ bibtex paper` <br/>
|
||||
@@ -22,4 +22,3 @@ In order to compile the latex files (and write bibliography), execute
|
||||
The generated file is paper.pdf. You can open it with
|
||||
|
||||
`$ open paper.pdf`
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ determine the next block. Each round is composed of three _steps_
|
||||
|
||||
In the optimal scenario, the order of steps is:
|
||||
|
||||
```
|
||||
```md
|
||||
NewHeight -> (Propose -> Prevote -> Precommit)+ -> Commit -> NewHeight ->...
|
||||
```
|
||||
|
||||
@@ -59,7 +59,7 @@ parameters over each successive round.
|
||||
|
||||
## State Machine Diagram
|
||||
|
||||
```
|
||||
```md
|
||||
+-------------------------------------+
|
||||
v |(Wait til `CommmitTime+timeoutCommit`)
|
||||
+-----------+ +-----+-----+
|
||||
|
||||
@@ -16,11 +16,11 @@ we account for amino overhead for each transaction.
|
||||
|
||||
```go
|
||||
func MaxDataBytes(maxBytes int64, valsCount, evidenceCount int) int64 {
|
||||
return maxBytes -
|
||||
MaxAminoOverheadForBlock -
|
||||
MaxHeaderBytes -
|
||||
int64(valsCount)*MaxVoteBytes -
|
||||
int64(evidenceCount)*MaxEvidenceBytes
|
||||
return maxBytes -
|
||||
MaxAminoOverheadForBlock -
|
||||
MaxHeaderBytes -
|
||||
int64(valsCount)*MaxVoteBytes -
|
||||
int64(evidenceCount)*MaxEvidenceBytes
|
||||
}
|
||||
```
|
||||
|
||||
@@ -33,10 +33,10 @@ maximum evidence size (1/10th of the maximum block size).
|
||||
|
||||
```go
|
||||
func MaxDataBytesUnknownEvidence(maxBytes int64, valsCount int) int64 {
|
||||
return maxBytes -
|
||||
MaxAminoOverheadForBlock -
|
||||
MaxHeaderBytes -
|
||||
int64(valsCount)*MaxVoteBytes -
|
||||
MaxEvidenceBytesPerBlock(maxBytes)
|
||||
return maxBytes -
|
||||
MaxAminoOverheadForBlock -
|
||||
MaxHeaderBytes -
|
||||
int64(valsCount)*MaxVoteBytes -
|
||||
MaxEvidenceBytesPerBlock(maxBytes)
|
||||
}
|
||||
```
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Tendermint Light Client Protocol
|
||||
|
||||
NOTE: This specification is under heavy development and is not yet complete nor
|
||||
accurate.
|
||||
accurate.
|
||||
|
||||
## Contents
|
||||
|
||||
@@ -51,16 +51,15 @@ full nodes.
|
||||
|
||||
### Synchrony
|
||||
|
||||
Light clients are fundamentally synchronous protocols,
|
||||
Light clients are fundamentally synchronous protocols,
|
||||
where security is restricted by the interval during which a validator can be punished
|
||||
for Byzantine behaviour. We assume here that such intervals have fixed and known minimal duration
|
||||
referred to commonly as a blockchain's Unbonding Period.
|
||||
|
||||
A secure light client must guarantee that all three components -
|
||||
core verification, fork detection, and fork accountability -
|
||||
A secure light client must guarantee that all three components -
|
||||
core verification, fork detection, and fork accountability -
|
||||
each with their own synchrony assumptions and fault model, can execute
|
||||
sequentially and to completion within the given Unbonding Period.
|
||||
|
||||
TODO: define all the synchrony parameters used in the protocol and their
|
||||
relation to the Unbonding Period.
|
||||
|
||||
|
||||
@@ -1,8 +1,9 @@
|
||||
# Fork accountability
|
||||
# Fork accountability
|
||||
|
||||
## Problem Statement
|
||||
|
||||
Tendermint consensus guarantees the following specifications for all heights:
|
||||
|
||||
* agreement -- no two correct full nodes decide differently.
|
||||
* validity -- the decided block satisfies the predefined predicate *valid()*.
|
||||
* termination -- all correct full nodes eventually decide,
|
||||
@@ -13,7 +14,6 @@ does not hold, each of the specification may be violated.
|
||||
|
||||
The agreement property says that for a given height, any two correct validators that decide on a block for that height decide on the same block. That the block was indeed generated by the blockchain, can be verified starting from a trusted (genesis) block, and checking that all subsequent blocks are properly signed.
|
||||
|
||||
|
||||
However, faulty nodes may forge blocks and try to convince users (light clients) that the blocks had been correctly generated. In addition, Tendermint agreement might be violated in the case where more than 1/3 of the voting power belongs to faulty validators: Two correct validators decide on different blocks. The latter case motivates the term "fork": as Tendermint consensus also agrees on the next validator set, correct validators may have decided on disjoint next validator sets, and the chain branches into two or more partitions (possibly having faulty validators in common) and each branch continues to generate blocks independently of the other.
|
||||
|
||||
We say that a fork is a case in which there are two commits for different blocks at the same height of the blockchain. The proplem is to ensure that in those cases we are able to detect faulty validators (and not mistakenly accuse correct validators), and incentivize therefore validators to behave according to the protocol specification.
|
||||
@@ -24,7 +24,6 @@ We say that a fork is a case in which there are two commits for different blocks
|
||||
|
||||
*Remark.* In the case more than 1/3 of the voting power belongs to faulty validators, also validity and termination can be broken. Termination can be broken if faulty processes just do not send the messages that are needed to make progress. Due to asynchrony, this is not punishable, because faulty validators can always claim they never received the messages that would have forced them to send messages.
|
||||
|
||||
|
||||
## The Misbehavior of Faulty Validators
|
||||
|
||||
Forks are the result of faulty validators deviating from the protocol. In principle several such deviations can be detected without a fork actually occurring:
|
||||
@@ -37,13 +36,11 @@ Forks are the result of faulty validators deviating from the protocol. In princi
|
||||
|
||||
*Remark.* In isolation, Point 3 is an attack on validity (rather than agreement). However, the prevotes and precommits can then also be used to forge blocks.
|
||||
|
||||
1. amnesia: Tendermint consensus has a locking mechanism. If a validator has some value v locked, then it can only prevote/precommit for v or nil. Sending prevote/precomit message for a different value v' (that is not nil) while holding lock on value v is misbehavior.
|
||||
1. amnesia: Tendermint consensus has a locking mechanism. If a validator has some value v locked, then it can only prevote/precommit for v or nil. Sending prevote/precomit message for a different value v' (that is not nil) while holding lock on value v is misbehavior.
|
||||
|
||||
2. spurious messages: In Tendermint consensus most of the message send instructions are guarded by threshold guards, e.g., one needs to receive *2f + 1* prevote messages to send precommit. Faulty validators may send precommit without having received the prevote messages.
|
||||
|
||||
|
||||
Independently of a fork happening, punishing this behavior might be important to prevent forks altogether. This should keep attackers from misbehaving: if at most 1/3 of the voting power is faulty, this misbehavior is detectable but will not lead to a safety violation. Thus, unless they have more than 1/3 (or in some cases more than 2/3) of the voting power attackers have the incentive to not misbehave. If attackers control too much voting power, we have to deal with forks, as discussed in this document.
|
||||
|
||||
Independently of a fork happening, punishing this behavior might be important to prevent forks altogether. This should keep attackers from misbehaving: if at most 1/3 of the voting power is faulty, this misbehavior is detectable but will not lead to a safety violation. Thus, unless they have more than 1/3 (or in some cases more than 2/3) of the voting power attackers have the incentive to not misbehave. If attackers control too much voting power, we have to deal with forks, as discussed in this document.
|
||||
|
||||
## Two types of forks
|
||||
|
||||
@@ -53,7 +50,6 @@ As in this case we have two different blocks (both having the same right/no righ
|
||||
|
||||
* Fork-Light. All correct validators decide on the same block for height *h*, but faulty processes (validators or not), forge a different block for that height, in order to fool users (who use the light client).
|
||||
|
||||
|
||||
# Attack scenarios
|
||||
|
||||
## On-chain attacks
|
||||
@@ -64,25 +60,17 @@ There are several scenarios in which forks might happen. The first is double sig
|
||||
|
||||
* F1. Equivocation: faulty validators sign multiple vote messages (prevote and/or precommit) for different values *during the same round r* at a given height h.
|
||||
|
||||
|
||||
### Flip-flopping
|
||||
|
||||
Tendermint consensus implements a locking mechanism: If a correct validator *p* receives proposal for value v and *2f + 1* prevotes for a value *id(v)* in round *r*, it locks *v* and remembers *r*. In this case, *p* also sends a precommit message for *id(v)*, which later may serve as proof that *p* locked *v*.
|
||||
In subsequent rounds, *p* only sends prevote messages for a value it had previously locked. However, it is possible to change the locked value if in a future round *r' > r*, if the process receives proposal and *2f + 1* prevotes for a different value *v'*. In this case, *p* could send a prevote/precommit for *id(v')*. This algorithmic feature can be exploited in two ways:
|
||||
|
||||
|
||||
|
||||
* F2. Faulty Flip-flopping (Amnesia): faulty validators precommit some value *id(v)* in round *r* (value *v* is locked in round *r*) and then prevote for different value *id(v')* in higher round *r' > r* without previously correctly unlocking value *v*. In this case faulty processes "forget" that they have locked value *v* and prevote some other value in the following rounds.
|
||||
Some correct validators might have decided on *v* in *r*, and other correct validators decide on *v'* in *r'*. Here we can have branching on the main chain (Fork-Full).
|
||||
|
||||
|
||||
* F3. Correct Flip-flopping (Back to the past): There are some precommit messages signed by (correct) validators for value *id(v)* in round *r*. Still, *v* is not decided upon, and all processes move on to the next round. Then correct validators (correctly) lock and decide a different value *v'* in some round *r' > r*. And the correct validators continue; there is no branching on the main chain.
|
||||
However, faulty validators may use the correct precommit messages from round *r* together with a posteriori generated faulty precommit messages for round *r* to forge a block for a value that was not decided on the main chain (Fork-Light).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Off-chain attacks
|
||||
|
||||
F1-F3 may contaminate the state of full nodes (and even validators). Contaminated (but otherwise correct) full nodes may thus communicate faulty blocks to light clients.
|
||||
@@ -96,10 +84,9 @@ Similarly, without actually interfering with the main chain, we can have the fol
|
||||
|
||||
We consider three types of potential attack victims:
|
||||
|
||||
|
||||
- FN: full node
|
||||
- LCS: light client with sequential header verification
|
||||
- LCB: light client with bisection based header verification
|
||||
* FN: full node
|
||||
* LCS: light client with sequential header verification
|
||||
* LCB: light client with bisection based header verification
|
||||
|
||||
F1 and F2 can be used by faulty validators to actually create multiple branches on the blockchain. That means that correctly operating full nodes decide on different blocks for the same height. Until a fork is detected locally by a full node (by receiving evidence from others or by some other local check that fails), the full node can spread corrupted blocks to light clients.
|
||||
|
||||
@@ -110,15 +97,9 @@ F3 is similar to F1, except that no two correct validators decide on different b
|
||||
In addition, without creating a fork on the main chain, light clients can be contaminated by more than a third of validators that are faulty and sign a forged header
|
||||
F4 cannot fool correct full nodes as they know the current validator set. Similarly, LCS know who the validators are. Hence, F4 is an attack against LCB that do not necessarily know the complete prefix of headers (Fork-Light), as they trust a header that is signed by at least one correct validator (trusting period method).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
The following table gives an overview of how the different attacks may affect different nodes. F1-F3 are *on-chain* attacks so they can corrupt the state of full nodes. Then if a light client (LCS or LCB) contacts a full node to obtain headers (or blocks), the corrupted state may propagate to the light client.
|
||||
|
||||
F4 and F5 are *off-chain*, that is, these attacks cannot be used to corrupt the state of full nodes (which have sufficient knowledge on the state of the chain to not be fooled).
|
||||
|
||||
F4 and F5 are *off-chain*, that is, these attacks cannot be used to corrupt the state of full nodes (which have sufficient knowledge on the state of the chain to not be fooled).
|
||||
|
||||
| Attack | FN | LCS | LCB |
|
||||
|:------:|:------:|:------:|:------:|
|
||||
@@ -128,16 +109,11 @@ F4 and F5 are *off-chain*, that is, these attacks cannot be used to corrupt the
|
||||
| F4 | | | direct |
|
||||
| F5 | | | direct |
|
||||
|
||||
|
||||
|
||||
**Q:** Light clients are more vulnerable than full nodes, because the former do only verify headers but do not execute transactions. What kind of certainty is gained by a full node that executes a transaction?
|
||||
|
||||
As a full node verifies all transactions, it can only be
|
||||
contaminated by an attack if the blockchain itself violates its invariant (one block per height), that is, in case of a fork that leads to branching.
|
||||
|
||||
|
||||
|
||||
|
||||
## Detailed Attack Scenarios
|
||||
|
||||
### Equivocation based attacks
|
||||
@@ -148,6 +124,7 @@ round of some height. This attack can be executed on both full nodes and light c
|
||||
#### Scenario 1: Equivocation on the main chain
|
||||
|
||||
Validators:
|
||||
|
||||
* CA - a set of correct validators with less than 1/3 of the voting power
|
||||
* CB - a set of correct validators with less than 1/3 of the voting power
|
||||
* CA and CB are disjoint
|
||||
@@ -162,14 +139,15 @@ Execution:
|
||||
* Validators from the set CA and CB prevote for A and B, respectively.
|
||||
* Faulty validators from the set F prevote both for A and B.
|
||||
* The faulty prevote messages
|
||||
- for A arrive at CA long before the B messages
|
||||
- for B arrive at CB long before the A messages
|
||||
* for A arrive at CA long before the B messages
|
||||
* for B arrive at CB long before the A messages
|
||||
* Therefore correct validators from set CA and CB will observe
|
||||
more than 2/3 of prevotes for A and B and precommit for A and B, respectively.
|
||||
* Faulty validators from the set F precommit both values A and B.
|
||||
* Thus, we have more than 2/3 commits for both A and B.
|
||||
|
||||
Consequences:
|
||||
|
||||
* Creating evidence of misbehavior is simple in this case as we have multiple messages signed by the same faulty processes for different values in the same round.
|
||||
|
||||
* We have to ensure that these different messages reach a correct process (full node, monitor?), which can submit evidence.
|
||||
@@ -180,11 +158,12 @@ Consequences:
|
||||
|
||||
#### Scenario 2: Equivocation to a light client (LCS)
|
||||
|
||||
|
||||
Validators:
|
||||
|
||||
* a set F of faulty validators with more than 2/3 of the voting power.
|
||||
|
||||
Execution:
|
||||
|
||||
* for the main chain F behaves nicely
|
||||
* F coordinates to sign a block B that is different from the one on the main chain.
|
||||
* the light clients obtains B and trusts at as it is signed by more than 2/3 of the voting power.
|
||||
@@ -202,8 +181,6 @@ In order to detect such (equivocation-based attack), the light client would need
|
||||
|
||||
### Flip-flopping: Amnesia based attacks
|
||||
|
||||
|
||||
|
||||
In case of amnesia, faulty validators lock some value *v* in some round *r*, and then vote for different value *v'* in higher rounds without correctly unlocking value *v*. This attack can be used both on full nodes and light clients.
|
||||
|
||||
#### Scenario 3: At most 2/3 of faults
|
||||
@@ -215,7 +192,7 @@ Validators:
|
||||
|
||||
Execution:
|
||||
|
||||
* Faulty validators commit (without exposing it on the main chain) a block A in round *r* by collecting more than 2/3 of the
|
||||
* Faulty validators commit (without exposing it on the main chain) a block A in round *r* by collecting more than 2/3 of the
|
||||
voting power (containing correct and faulty validators).
|
||||
* All validators (correct and faulty) reach a round *r' > r*.
|
||||
* Some correct validators in C do not lock any value before round *r'*.
|
||||
@@ -224,7 +201,7 @@ Execution:
|
||||
|
||||
*Remark.* In this case, the more than 1/3 of faulty validators do not need to commit an equivocation (F1) as they only vote once per round in the execution.
|
||||
|
||||
Detecting faulty validators in the case of such an attack can be done by the fork accountability mechanism described in: https://docs.google.com/document/d/11ZhMsCj3y7zIZz4udO9l25xqb0kl7gmWqNpGVRzOeyY/edit?usp=sharing.
|
||||
Detecting faulty validators in the case of such an attack can be done by the fork accountability mechanism described in: <https://docs.google.com/document/d/11ZhMsCj3y7zIZz4udO9l25xqb0kl7gmWqNpGVRzOeyY/edit?usp=sharing>.
|
||||
|
||||
If a light client is attacked using this attack with more than 1/3 of voting power (and less than 2/3), the attacker cannot change the application state arbitrarily. Rather, the attacker is limited to a state a correct validator finds acceptable: In the execution above, correct validators still find the value acceptable, however, the block the light client trusts deviates from the one on the main chain.
|
||||
|
||||
@@ -249,7 +226,7 @@ Consequences:
|
||||
* The validators in F1 will be detectable by the the fork accountability mechanisms.
|
||||
* The validators in F2 cannot be detected using this mechanism.
|
||||
Only in case they signed something which conflicts with the application this can be used against them. Otherwise they do not do anything incorrect.
|
||||
* This case is not covered by the report https://docs.google.com/document/d/11ZhMsCj3y7zIZz4udO9l25xqb0kl7gmWqNpGVRzOeyY/edit?usp=sharing as it only assumes at most 2/3 of faulty validators.
|
||||
* This case is not covered by the report <https://docs.google.com/document/d/11ZhMsCj3y7zIZz4udO9l25xqb0kl7gmWqNpGVRzOeyY/edit?usp=sharing> as it only assumes at most 2/3 of faulty validators.
|
||||
|
||||
**Q:** do we need to define a special kind of attack for the case where a validator sign arbitrarily state? It seems that detecting such attack requires a different mechanism that would require as an evidence a sequence of blocks that led to that state. This might be very tricky to implement.
|
||||
|
||||
@@ -257,9 +234,10 @@ Only in case they signed something which conflicts with the application this can
|
||||
|
||||
In this kind of attack, faulty validators take advantage of the fact that they did not sign messages in some of the past rounds. Due to the asynchronous network in which Tendermint operates, we cannot easily differentiate between such an attack and delayed message. This kind of attack can be used at both full nodes and light clients.
|
||||
|
||||
#### Scenario 5:
|
||||
#### Scenario 5
|
||||
|
||||
Validators:
|
||||
|
||||
* C1 - a set of correct validators with 1/3 of the voting power
|
||||
* C2 - a set of correct validators with 1/3 of the voting power
|
||||
* C1 and C2 are disjoint
|
||||
@@ -267,7 +245,6 @@ Validators:
|
||||
* one additional faulty process *q*
|
||||
* F and *q* violate the Tendermint failure model.
|
||||
|
||||
|
||||
Execution:
|
||||
|
||||
* in a round *r* of height *h* we have C1 precommitting a value A,
|
||||
@@ -278,7 +255,6 @@ Execution:
|
||||
* F and *fp* "go back to the past" and sign precommit message for value A in round *r*.
|
||||
* Together with precomit messages of C1 this is sufficient for a commit for value A.
|
||||
|
||||
|
||||
Consequences:
|
||||
|
||||
* Only a single faulty validator that previously precommited nil did equivocation, while the other 1/3 of faulty validators actually executed an attack that has exactly the same sequence of messages as part of amnesia attack. Detecting this kind of attack boil down to mechanisms for equivocation and amnesia.
|
||||
@@ -289,16 +265,17 @@ Consequences:
|
||||
|
||||
In case of phantom validators, processes that are not part of the current validator set but are still bonded (as attack happen during their unbonding period) can be part of the attack by signing vote messages. This attack can be executed against both full nodes and light clients.
|
||||
|
||||
#### Scenario 6:
|
||||
#### Scenario 6
|
||||
|
||||
Validators:
|
||||
|
||||
* F -- a set of faulty validators that are not part of the validator set on the main chain at height *h + k*
|
||||
|
||||
Execution:
|
||||
|
||||
* There is a fork, and there exist two different headers for height *h + k*, with different validator sets:
|
||||
- VS2 on the main chain
|
||||
- forged header VS2', signed by F (and others)
|
||||
* VS2 on the main chain
|
||||
* forged header VS2', signed by F (and others)
|
||||
|
||||
* a light client has a trust in a header for height *h* (and the corresponding validator set VS1).
|
||||
* As part of bisection header verification, it verifies the header at height *h + k* with new validator set VS2'.
|
||||
@@ -314,7 +291,7 @@ Consequences:
|
||||
the light client involving a phantom validator will have needed to be initiated by 1/3+ lunatic
|
||||
validators that can forge a new validator set that includes the phantom validator. Only in
|
||||
that case will the light client accept the phantom validators vote. We need only worry about
|
||||
punishing the 1/3+ lunatic cabal, that is the root cause of the attack.
|
||||
punishing the 1/3+ lunatic cabal, that is the root cause of the attack.
|
||||
|
||||
### Lunatic validator
|
||||
|
||||
|
||||
@@ -68,7 +68,6 @@ get trust for `hp`, and `hp` can be used to get trust for `snh`. If this is the
|
||||
if not, we continue recursively until either we found set of headers that can build (transitively) trust relation
|
||||
between `h` and `h1`, or we failed as two consecutive headers don't verify against each other.
|
||||
|
||||
|
||||
## Definitions
|
||||
|
||||
### Data structures
|
||||
@@ -110,6 +109,7 @@ In the following, only the details of the data structures needed for this specif
|
||||
|
||||
For the purpose of this light client specification, we assume that the Tendermint Full Node
|
||||
exposes the following functions over Tendermint RPC:
|
||||
|
||||
```go
|
||||
// returns signed header: Header with Commit, for the given height
|
||||
func Commit(height int64) (SignedHeader, error)
|
||||
@@ -119,6 +119,7 @@ exposes the following functions over Tendermint RPC:
|
||||
```
|
||||
|
||||
Furthermore, we assume the following auxiliary functions:
|
||||
|
||||
```go
|
||||
// returns true if the commit is for the header, ie. if it contains
|
||||
// the correct hash of the header; otherwise false
|
||||
@@ -137,8 +138,6 @@ Furthermore, we assume the following auxiliary functions:
|
||||
func hash(v2 ValidatorSet) []byte
|
||||
```
|
||||
|
||||
### Functions
|
||||
|
||||
In the functions below we will be using `trustThreshold` as a parameter. For simplicity
|
||||
we assume that `trustThreshold` is a float between `1/3` and `2/3` and we will not be checking it
|
||||
in the pseudo-code.
|
||||
@@ -399,15 +398,13 @@ func fatalError(err) bool {
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
|
||||
### The case `untrustedHeader.Height < trustedHeader.Height`
|
||||
|
||||
In the use case where someone tells the light client that application data that is relevant for it
|
||||
can be read in the block of height `k` and the light client trusts a more recent header, we can use the
|
||||
In the use case where someone tells the light client that application data that is relevant for it
|
||||
can be read in the block of height `k` and the light client trusts a more recent header, we can use the
|
||||
hashes to verify headers "down the chain." That is, we iterate down the heights and check the hashes in each step.
|
||||
|
||||
*Remark.* For the case were the light client trusts two headers `i` and `j` with `i < k < j`, we should
|
||||
*Remark.* For the case were the light client trusts two headers `i` and `j` with `i < k < j`, we should
|
||||
discuss/experiment whether the forward or the backward method is more effective.
|
||||
|
||||
```go
|
||||
@@ -449,31 +446,30 @@ func VerifyHeaderBackwards(trustedHeader Header,
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
*Assumption*: In the following, we assume that *untrusted_h.Header.height > trusted_h.Header.height*. We will quickly discuss the other case in the next section.
|
||||
|
||||
We consider the following set-up:
|
||||
|
||||
- the light client communicates with one full node
|
||||
- the light client locally stores all the headers that has passed basic verification and that are within light client trust period. In the pseudo code below we
|
||||
write *Store.Add(header)* for this. If a header failed to verify, then
|
||||
the full node we are talking to is faulty and we should disconnect from it and reinitialise with new peer.
|
||||
- If `CanTrust` returns *error*, then the light client has seen a forged header or the trusted header has expired (it is outside its trusted period).
|
||||
* In case of forged header, the full node is faulty so light client should disconnect and reinitialise with new peer. If the trusted header has expired,
|
||||
- In case of forged header, the full node is faulty so light client should disconnect and reinitialise with new peer. If the trusted header has expired,
|
||||
we need to reinitialise light client with new trusted header (that is within its trusted period), but we don't necessarily need to disconnect from the full node
|
||||
we are talking to (as we haven't observed full node misbehavior in this case).
|
||||
|
||||
|
||||
## Correctness of the Light Client Protocols
|
||||
|
||||
### Definitions
|
||||
|
||||
* `TRUSTED_PERIOD`: trusted period
|
||||
* for realtime `t`, the predicate `correct(v,t)` is true if the validator `v`
|
||||
- `TRUSTED_PERIOD`: trusted period
|
||||
- for realtime `t`, the predicate `correct(v,t)` is true if the validator `v`
|
||||
follows the protocol until time `t` (we will see about recovery later).
|
||||
* Validator fields. We will write a validator as a tuple `(v,p)` such that
|
||||
+ `v` is the identifier (i.e., validator address; we assume identifiers are unique in each validator set)
|
||||
+ `p` is its voting power
|
||||
* For each header `h`, we write `trust(h) = true` if the light client trusts `h`.
|
||||
- Validator fields. We will write a validator as a tuple `(v,p)` such that
|
||||
- `v` is the identifier (i.e., validator address; we assume identifiers are unique in each validator set)
|
||||
- `p` is its voting power
|
||||
- For each header `h`, we write `trust(h) = true` if the light client trusts `h`.
|
||||
|
||||
### Failure Model
|
||||
|
||||
@@ -487,7 +483,6 @@ Formally,
|
||||
2/3 \sum_{(v,p) \in validators(h.NextValidatorsHash)} p
|
||||
\]
|
||||
|
||||
|
||||
The light client communicates with a full node and learns new headers. The goal is to locally decide whether to trust a header. Our implementation needs to ensure the following two properties:
|
||||
|
||||
- *Light Client Completeness*: If a header `h` was correctly generated by an instance of Tendermint consensus (and its age is less than the trusted period),
|
||||
@@ -532,14 +527,15 @@ is correct, but we only trust the fact that less than `1/3` of them are faulty (
|
||||
*`VerifySingle` correctness arguments*
|
||||
|
||||
Light Client Accuracy:
|
||||
|
||||
- Assume by contradiction that `untrustedHeader` was not generated correctly and the light client sets trust to true because `verifySingle` returns without error.
|
||||
- `trustedState` is trusted and sufficiently new
|
||||
- by the Failure Model, less than `1/3` of the voting power held by faulty validators => at least one correct validator `v` has signed `untrustedHeader`.
|
||||
- as `v` is correct up to now, it followed the Tendermint consensus protocol at least up to signing `untrustedHeader` => `untrustedHeader` was correctly generated.
|
||||
We arrive at the required contradiction.
|
||||
|
||||
|
||||
Light Client Completeness:
|
||||
|
||||
- The check is successful if sufficiently many validators of `trustedState` are still validators in the height `untrustedHeader.Height` and signed `untrustedHeader`.
|
||||
- If `untrustedHeader.Height = trustedHeader.Height + 1`, and both headers were generated correctly, the test passes.
|
||||
|
||||
@@ -550,10 +546,10 @@ Light Client Completeness:
|
||||
However, in case of (frequent) changes in the validator set, the higher the `trustThreshold` is chosen, the more unlikely it becomes that
|
||||
`verifySingle` returns with an error for non-adjacent headers.
|
||||
|
||||
|
||||
* `VerifyBisection` correctness arguments (sketch)*
|
||||
- `VerifyBisection` correctness arguments (sketch)*
|
||||
|
||||
Light Client Accuracy:
|
||||
|
||||
- Assume by contradiction that the header at `untrustedHeight` obtained from the full node was not generated correctly and
|
||||
the light client sets trust to true because `VerifyBisection` returns without an error.
|
||||
- `VerifyBisection` returns without error only if all calls to `verifySingle` in the recursion return without error (return `nil`).
|
||||
@@ -568,12 +564,8 @@ This is only ensured if upon `Commit(pivot)` the light client is always provided
|
||||
|
||||
With `VerifyBisection`, a faulty full node could stall a light client by creating a long sequence of headers that are queried one-by-one by the light client and look OK,
|
||||
before the light client eventually detects a problem. There are several ways to address this:
|
||||
* Each call to `Commit` could be issued to a different full node
|
||||
* Instead of querying header by header, the light client tells a full node which header it trusts, and the height of the header it needs. The full node responds with
|
||||
|
||||
- Each call to `Commit` could be issued to a different full node
|
||||
- Instead of querying header by header, the light client tells a full node which header it trusts, and the height of the header it needs. The full node responds with
|
||||
the header along with a proof consisting of intermediate headers that the light client can use to verify. Roughly, `VerifyBisection` would then be executed at the full node.
|
||||
* We may set a timeout how long `VerifyBisection` may take.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- We may set a timeout how long `VerifyBisection` may take.
|
||||
|
||||
@@ -4,7 +4,7 @@ cards: true
|
||||
|
||||
# Consensus
|
||||
|
||||
Specification of the Tendermint consensus protocol.
|
||||
Specification of the Tendermint consensus protocol.
|
||||
|
||||
## Contents
|
||||
|
||||
|
||||
@@ -14,12 +14,12 @@ being signed. It is defined in Go as follows:
|
||||
type SignedMsgType byte
|
||||
|
||||
const (
|
||||
// Votes
|
||||
PrevoteType SignedMsgType = 0x01
|
||||
PrecommitType SignedMsgType = 0x02
|
||||
// Votes
|
||||
PrevoteType SignedMsgType = 0x01
|
||||
PrecommitType SignedMsgType = 0x02
|
||||
|
||||
// Proposals
|
||||
ProposalType SignedMsgType = 0x20
|
||||
// Proposals
|
||||
ProposalType SignedMsgType = 0x20
|
||||
)
|
||||
```
|
||||
|
||||
@@ -48,13 +48,13 @@ BlockID is the structure used to represent the block:
|
||||
|
||||
```go
|
||||
type BlockID struct {
|
||||
Hash []byte
|
||||
PartsHeader PartSetHeader
|
||||
Hash []byte
|
||||
PartsHeader PartSetHeader
|
||||
}
|
||||
|
||||
type PartSetHeader struct {
|
||||
Hash []byte
|
||||
Total int
|
||||
Hash []byte
|
||||
Total int
|
||||
}
|
||||
```
|
||||
|
||||
@@ -64,7 +64,7 @@ We introduce two methods, `BlockID.IsZero()` and `BlockID.IsComplete()` for thes
|
||||
`BlockID.IsZero()` returns true for BlockID `b` if each of the following
|
||||
are true:
|
||||
|
||||
```
|
||||
```go
|
||||
b.Hash == nil
|
||||
b.PartsHeader.Total == 0
|
||||
b.PartsHeader.Hash == nil
|
||||
@@ -73,7 +73,7 @@ b.PartsHeader.Hash == nil
|
||||
`BlockID.IsComplete()` returns true for BlockID `b` if each of the following
|
||||
are true:
|
||||
|
||||
```
|
||||
```go
|
||||
len(b.Hash) == 32
|
||||
b.PartsHeader.Total > 0
|
||||
len(b.PartsHeader.Hash) == 32
|
||||
@@ -85,13 +85,13 @@ The structure of a proposal for signing looks like:
|
||||
|
||||
```go
|
||||
type CanonicalProposal struct {
|
||||
Type SignedMsgType // type alias for byte
|
||||
Height int64 `binary:"fixed64"`
|
||||
Round int64 `binary:"fixed64"`
|
||||
POLRound int64 `binary:"fixed64"`
|
||||
BlockID BlockID
|
||||
Timestamp time.Time
|
||||
ChainID string
|
||||
Type SignedMsgType // type alias for byte
|
||||
Height int64 `binary:"fixed64"`
|
||||
Round int64 `binary:"fixed64"`
|
||||
POLRound int64 `binary:"fixed64"`
|
||||
BlockID BlockID
|
||||
Timestamp time.Time
|
||||
ChainID string
|
||||
}
|
||||
```
|
||||
|
||||
@@ -115,18 +115,18 @@ The structure of a vote for signing looks like:
|
||||
|
||||
```go
|
||||
type CanonicalVote struct {
|
||||
Type SignedMsgType // type alias for byte
|
||||
Height int64 `binary:"fixed64"`
|
||||
Round int64 `binary:"fixed64"`
|
||||
BlockID BlockID
|
||||
Timestamp time.Time
|
||||
ChainID string
|
||||
Type SignedMsgType // type alias for byte
|
||||
Height int64 `binary:"fixed64"`
|
||||
Round int64 `binary:"fixed64"`
|
||||
BlockID BlockID
|
||||
Timestamp time.Time
|
||||
ChainID string
|
||||
}
|
||||
```
|
||||
|
||||
A vote is valid if each of the following lines evaluates to true for vote `v`:
|
||||
|
||||
```
|
||||
```go
|
||||
v.Type == 0x1 || v.Type == 0x2
|
||||
v.Height > 0
|
||||
v.Round >= 0
|
||||
@@ -157,9 +157,9 @@ Assume the signer keeps the following state, `s`:
|
||||
|
||||
```go
|
||||
type LastSigned struct {
|
||||
Height int64
|
||||
Round int64
|
||||
Type SignedMsgType // byte
|
||||
Height int64
|
||||
Round int64
|
||||
Type SignedMsgType // byte
|
||||
}
|
||||
```
|
||||
|
||||
@@ -175,7 +175,7 @@ s.Type = m.Type
|
||||
|
||||
A signer should only sign a proposal `p` if any of the following lines are true:
|
||||
|
||||
```
|
||||
```go
|
||||
p.Height > s.Height
|
||||
p.Height == s.Height && p.Round > s.Round
|
||||
```
|
||||
@@ -187,7 +187,7 @@ Once a proposal or vote has been signed for a given height and round, a proposal
|
||||
|
||||
A signer should only sign a vote `v` if any of the following lines are true:
|
||||
|
||||
```
|
||||
```go
|
||||
v.Height > s.Height
|
||||
v.Height == s.Height && v.Round > s.Round
|
||||
v.Height == s.Height && v.Round == s.Round && v.Step == 0x1 && s.Step == 0x20
|
||||
|
||||
Reference in New Issue
Block a user