tendermint/consensus
Ethan Frey 960b25408f Store LastConsensusHash in State as well
Update all BlockValidation that it matches the last state
2017-12-19 12:28:08 -05:00
..
types Add default timestamp to all instances of *types.Vote 2017-12-12 12:59:51 +01: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 Add default timestamp to all instances of *types.Vote 2017-12-12 12:59:51 +01:00
mempool_test.go excessive logging. update tmlibs for timer fix 2017-12-16 19:16:08 -05:00
reactor.go remove some debugs 2017-12-19 10:11:37 -05:00
reactor_test.go crank city 2017-12-16 19:55:04 -05:00
replay.go Merge pull request #965 from tendermint/573-handle-corrupt-wal-file 2017-12-15 14:33:16 -05:00
replay_file.go service#Start, service#Stop signatures were changed 2017-11-29 10:38:58 -06:00
replay_test.go excessive logging. update tmlibs for timer fix 2017-12-16 19:16:08 -05:00
state.go Store LastConsensusHash in State as well 2017-12-19 12:28:08 -05:00
state_test.go linting: apply errcheck part2 2017-11-27 22:39:11 +00: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 correct maxMsgSizeBytes 2017-12-15 11:42:53 -06:00
wal_fuzz.go add gofuzz test for consensus wal 2017-12-15 11:56:24 -06:00
wal_generator.go Merge branch 'develop' into 977-wal-generator 2017-12-19 11:11:26 -05: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.