evidence: update data structures (#165)

This commit is contained in:
Callum Waters
2020-09-29 14:05:44 +02:00
committed by GitHub
parent 109a73f672
commit 733b020899
5 changed files with 42 additions and 34 deletions

View File

@@ -115,7 +115,8 @@ enum EvidenceType {
```
There are two forms of evidence: Duplicate Vote and Light Client Attack. More
information can be found [here](https://github.com/tendermint/spec/blob/master/spec/light-client/accountability.md)
information can be found in either [data structures](https://github.com/tendermint/spec/blob/master/spec/core/data_structures.md)
or [accountability](https://github.com/tendermint/spec/blob/master/spec/light-client/accountability.md)
## Determinism

View File

@@ -345,14 +345,6 @@ a block minus it's overhead ( ~ `MaxBytes`).
The amount must be a positive number.
### EvidenceParams.ProofTrialPeriod
This is the duration in terms of blocks that an indicted validator has to prove a
correct lock change in the event of amnesia evidence when a validator voted more
than once across different rounds.
This must be positive and less then `EvidenceParams.MaxAgeNumBlocks`.
### Updates
The application may set the ConsensusParams during InitChain, and update them during

View File

@@ -17,7 +17,7 @@ we account for amino overhead for each transaction.
```go
func MaxDataBytes(maxBytes int64, valsCount, evidenceCount int) int64 {
return maxBytes -
MaxAminoOverheadForBlock -
MaxOverheadForBlock -
MaxHeaderBytes -
int64(valsCount)*MaxVoteBytes -
int64(evidenceCount)*MaxEvidenceBytes
@@ -28,15 +28,13 @@ func MaxDataBytes(maxBytes int64, valsCount, evidenceCount int) int64 {
Before we accept a transaction in the mempool, we check if it's size is no more
than {MaxDataSize}. {MaxDataSize} is calculated using the same formula as
above, except because the evidence size is unknown at the moment, we subtract
maximum evidence size (1/10th of the maximum block size).
above, except we subtract the max number of evidence, {MaxNum} by the maximum size of evidence
```go
func MaxDataBytesUnknownEvidence(maxBytes int64, valsCount int) int64 {
return maxBytes -
MaxAminoOverheadForBlock -
MaxOverheadForBlock -
MaxHeaderBytes -
int64(valsCount)*MaxVoteBytes -
MaxEvidenceBytesPerBlock(maxBytes)
(maxNumEvidence * MaxEvidenceBytes)
}
```

View File

@@ -207,15 +207,10 @@ It is implemented as the following interface.
```go
type Evidence interface {
Height() int64 // height of the equivocation
Time() time.Time // time of the equivocation
Address() []byte // address of the equivocating validator
Bytes() []byte // bytes which comprise the evidence
Hash() []byte // hash of the evidence
Verify(chainID string, pubKey crypto.PubKey) error // verify the evidence
Equal(Evidence) bool // check equality of evidence
ValidateBasic() error
String() string
Hash() []byte // hash of the evidence (this is also used for equality)
ValidateBasic() error // consistency check of the data
String() string // string representation of the evidence
}
```
@@ -231,16 +226,14 @@ in the same round of the same height. Votes are lexicographically sorted on `Blo
```go
type DuplicateVoteEvidence struct {
VoteA *Vote
VoteB *Vote
Timestamp time.Time
VoteA *Vote
VoteB *Vote
}
```
Valid Duplicate Vote Evidence must adhere to the following rules:
- Validator Address, Height, Round and Type of vote must be the same for both votes
- Validator Address, Height, Round and Type must be the same for both votes
- BlockID must be different for both votes (BlockID can be for a nil block)
@@ -248,7 +241,31 @@ Valid Duplicate Vote Evidence must adhere to the following rules:
- Vote signature must be valid (using the chainID)
- Time must be equal to the block time
- Evidence must not have expired: either age in terms of height or time must be
less than the age stated in the consensus params. Time is the block time that the
votes were a part of.
### LightClientAttackEvidence
```go
type LightClientAttackEvidence struct {
ConflictingBlock *LightBlock
CommonHeight int64
}
```
Valid Light Client Attack Evidence encompasses three types of attack and must adhere to the following rules
- If the header of the light block is invalid, thus indicating a lunatic attack, the node must check that
they can use `verifySkipping` from their header at the common height to the conflicting header
- If the header is valid, then the validator sets are the same and this is either a form of equivocation
or amnesia. We therefore check that 2/3 of the validator set also signed the conflicting header
- The trusted header of the node at the same height as the conflicting header must have a different hash to
the conflicting header.
- Evidence must not have expired. The height (and thus the time) is taken from the common height.
## Validation