tendermint/consensus
Ethan Buchman f55135578c state: move methods to funcs 2017-12-28 23:15:54 -05:00
..
test_data update consensus/test_data/many_blocks.cswal 2017-12-26 20:27:40 -05:00
types EvidencePool 2017-12-26 20:24:54 -05:00
README.md some comments 2016-08-09 20:31:53 -04:00
byzantine_test.go int64 height 2017-12-01 19:04:53 -06:00
common_test.go evidence linked with consensus/node. compiles 2017-12-26 20:26:21 -05:00
mempool_test.go excessive logging. update tmlibs for timer fix 2017-12-16 19:16:08 -05:00
reactor.go consensus: remove log stmt. closes #987 2017-12-26 10:41:31 -05:00
reactor_test.go change voting power change, not number of vals 2017-12-25 17:49:36 -06:00
replay.go state: move methods to funcs 2017-12-28 23:15:54 -05:00
replay_file.go evidence linked with consensus/node. compiles 2017-12-26 20:26:21 -05:00
replay_test.go fixes from rebase 2017-12-26 20:42:34 -05:00
state.go state.ApplyBlock takes evpool and calls MarkEvidenceAsCommitted 2017-12-26 20:27:32 -05:00
state_test.go separate block vs state based validation 2017-12-21 16:49:47 -05:00
ticker.go consensus: Fix typo on ticker.go documentation 2017-12-09 13:14:53 +01:00
version.go all: no more anonymous imports 2017-10-04 16:40:45 -04:00
wal.go Updates -> ValidatoSetUpdates 2017-12-19 13:03:39 -06:00
wal_fuzz.go add gofuzz test for consensus wal 2017-12-15 11:56:24 -06:00
wal_generator.go change directory for each call, not only for each test 2017-12-28 11:17:15 -06:00
wal_test.go handle data corruption errors 2017-12-11 19:48:20 -06:00

README.md

The core consensus algorithm.

  • state.go - The state machine as detailed in the whitepaper
  • reactor.go - A reactor that connects the state machine to the gossip network

Go-routine summary

The reactor runs 2 go-routines for each added peer: gossipDataRoutine and gossipVotesRoutine.

The consensus state runs two persistent go-routines: timeoutRoutine and receiveRoutine. Go-routines are also started to trigger timeouts and to avoid blocking when the internalMsgQueue is really backed up.

Replay/WAL

A write-ahead log is used to record all messages processed by the receiveRoutine, which amounts to all inputs to the consensus state machine: messages from peers, messages from ourselves, and timeouts. They can be played back deterministically at startup or using the replay console.