Browse Source

spec: update evidence in blockchain.md (#108)

now evidence reflects the actual evidence present in the tendermint repo
pull/7804/head
Callum Waters 5 years ago
committed by GitHub
parent
commit
1bd2aacb56
No known key found for this signature in database GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 63 additions and 13 deletions
  1. +1
    -1
      spec/abci/README.md
  2. +1
    -1
      spec/abci/abci.md
  3. +2
    -2
      spec/abci/client-server.md
  4. +59
    -9
      spec/blockchain/blockchain.md

+ 1
- 1
spec/abci/README.md View File

@ -10,7 +10,7 @@ _methods_, where each method has a corresponding `Request` and `Response`
message type. Tendermint calls the ABCI methods on the ABCI application by sending the `Request*`
messages and receiving the `Response*` messages in return.
All message types are defined in a [protobuf file](https://github.com/tendermint/tendermint/blob/master/abci/types/types.proto).
All message types are defined in a [protobuf file](https://github.com/tendermint/tendermint/blob/master/proto/abci/types.proto).
This allows Tendermint to run applications written in any programming language.
This specification is split as follows:


+ 1
- 1
spec/abci/abci.md View File

@ -3,7 +3,7 @@
## Overview
The ABCI message types are defined in a [protobuf
file](https://github.com/tendermint/tendermint/blob/master/abci/types/types.proto).
file](https://github.com/tendermint/tendermint/blob/master/proto/abci/types.proto).
ABCI methods are split across four separate ABCI _connections_:


+ 2
- 2
spec/abci/client-server.md View File

@ -9,7 +9,7 @@ Applications](./apps.md).
## Message Protocol
The message protocol consists of pairs of requests and responses defined in the
[protobuf file](https://github.com/tendermint/tendermint/blob/master/abci/types/types.proto).
[protobuf file](https://github.com/tendermint/tendermint/blob/master/proto/abci/types.proto).
Some messages have no fields, while others may include byte-arrays, strings, integers,
or custom protobuf types.
@ -49,7 +49,7 @@ If GRPC is available in your language, this is the easiest approach,
though it will have significant performance overhead.
To get started with GRPC, copy in the [protobuf
file](https://github.com/tendermint/tendermint/blob/master/abci/types/types.proto)
file](https://github.com/tendermint/tendermint/blob/master/proto/abci/types.proto)
and compile it using the GRPC plugin for your language. For instance,
for golang, the command is `protoc --go_out=plugins=grpc:. types.proto`.
See the [grpc documentation for more details](http://www.grpc.io/docs/).


+ 59
- 9
spec/blockchain/blockchain.md View File

@ -203,22 +203,72 @@ type EvidenceData struct {
## Evidence
Evidence in Tendermint is implemented as an interface.
This means any evidence is encoded using its Amino prefix.
There is currently only a single type, the `DuplicateVoteEvidence`.
Evidence in Tendermint is used to indicate breaches in the consensus by a validator.
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
}
```
// amino name: "tendermint/DuplicateVoteEvidence"
All evidence can be encoded and decoded to and from Protobuf with the `EvidenceToProto()`
and `EvidenceFromProto()` functions. The [Fork Accountability](../consensus/light-client/accountability.md)
document provides a good overview for the types of evidence and how they occur.
`DuplicateVoteEvidence` represents a validator that has voted for two different blocks
in the same round of the same height. Votes are lexicographically sorted on `BlockID`.
```go
type DuplicateVoteEvidence struct {
PubKey PubKey
VoteA Vote
VoteB Vote
VoteA *Vote
VoteB *Vote
}
```
`AmnesiaEvidence` represents a validator that has incorrectly voted for another block in a
different round to the the block that the validator was previously locked on. This form
of evidence is generated differently from the rest. See this
[ADR](https://github.com/tendermint/tendermint/blob/master/docs/architecture/adr-056-proving-amnesia-attacks.md).
```go
type AmnesiaEvidence struct {
*PotentialAmnesiaEvidence
Polc *ProofOfLockChange
}
```
`LunaticValidatorEvidence` represents a validator that has signed for an arbitrary application state.
This attack only applies to Light clients.
```go
type LunaticValidatorEvidence struct {
Header *Header
Vote *Vote
InvalidHeaderField string
}
```
Votes are lexicographically sorted on `BlockID`.
`PhantomValidatorEvidence` represents a validator that has signed for a block where it was not part of the validator set.
This attack also only applies to Light clients. Phantom validators must still be staked. `LastHeightValidatorWasInSet`
indicated the height that they last voted.
See the [pubkey spec](./encoding.md#key-types) for more.
```go
type PhantomValidatorEvidence struct {
Vote *Vote
LastHeightValidatorWasInSet int64
}
```
## Validation


Loading…
Cancel
Save