From 2bd673c8eb00acb6ba4ae0e1c6e556e757c6306e Mon Sep 17 00:00:00 2001 From: Marko Date: Wed, 29 Jul 2020 08:24:42 +0200 Subject: [PATCH] blockchain: remove duplicate evidence sections (#124) --- spec/core/data_structures.md | 11 ----------- spec/reactors/consensus/consensus.md | 6 +++--- 2 files changed, 3 insertions(+), 14 deletions(-) diff --git a/spec/core/data_structures.md b/spec/core/data_structures.md index 86c51d704..c92395831 100644 --- a/spec/core/data_structures.md +++ b/spec/core/data_structures.md @@ -522,17 +522,6 @@ func (vote *Vote) Verify(chainID string, pubKey crypto.PubKey) error { where `pubKey.Verify` performs the appropriate digital signature verification of the `pubKey` against the given signature and message bytes. -## Evidence - -There is currently only one kind of evidence, `DuplicateVoteEvidence`. - -DuplicateVoteEvidence `ev` is valid if - -- `ev.VoteA` and `ev.VoteB` can be verified with `ev.PubKey` -- `ev.VoteA` and `ev.VoteB` have the same `Height, Round, Address, Index, Type` -- `ev.VoteA.BlockID != ev.VoteB.BlockID` -- `(block.Height - ev.VoteA.Height) < MAX_EVIDENCE_AGE` - # Execution Once a block is validated, it can be executed against the state. diff --git a/spec/reactors/consensus/consensus.md b/spec/reactors/consensus/consensus.md index ff15af746..c85b3b8f2 100644 --- a/spec/reactors/consensus/consensus.md +++ b/spec/reactors/consensus/consensus.md @@ -16,7 +16,7 @@ explained in a forthcoming document. For efficiency reasons, validators in Tendermint consensus protocol do not agree directly on the block as the block size is big, i.e., they don't embed the block inside `Proposal` and `VoteMessage`. Instead, they reach agreement on the `BlockID` (see `BlockID` definition in -[Blockchain](https://github.com/tendermint/spec/blob/master/spec/blockchain/blockchain.md#blockid) section) +[Blockchain](https://github.com/tendermint/spec/blob/master/spec/core/data_structures.md#blockid) section) that uniquely identifies each block. The block itself is disseminated to validator processes using peer-to-peer gossiping protocol. It starts by having a proposer first splitting a block into a number of block parts, that are then gossiped between @@ -67,7 +67,7 @@ type Proposal struct { VoteMessage is sent to vote for some block (or to inform others that a process does not vote in the current round). Vote is defined in the -[Blockchain](https://github.com/tendermint/spec/blob/master/spec/blockchain/blockchain.md#blockidd) +[Blockchain](https://github.com/tendermint/spec/blob/master/spec/core/data_structures.md#blockidd) section and contains validator's information (validator address and index), height and round for which the vote is sent, vote type, blockID if process vote for some block (`nil` otherwise) and a timestamp when the vote is sent. The @@ -81,7 +81,7 @@ type VoteMessage struct { ## BlockPartMessage -BlockPartMessage is sent when gossipping a piece of the proposed block. It contains height, round +BlockPartMessage is sent when gossiping a piece of the proposed block. It contains height, round and the block part. ```go