fluencelabs/tendermint

mirror of https://github.com/fluencelabs/tendermint synced 2025-05-09 05:22:13 +00:00

History

Ethan Buchman ff99ca7cdf bump wal test timeout

2017-12-29 17:51:13 -05:00

..

update consensus/test_data/many_blocks.cswal

2017-12-26 20:27:40 -05:00

EvidencePool

2017-12-26 20:24:54 -05:00

byzantine_test.go

int64 height

2017-12-01 19:04:53 -06:00

common_test.go

move fireEvents to ApplyBlock

2017-12-28 23:15:54 -05:00

mempool_test.go

excessive logging. update tmlibs for timer fix

2017-12-16 19:16:08 -05:00

reactor_test.go

change voting power change, not number of vals

2017-12-25 17:49:36 -06:00

reactor.go

final updates for state

2017-12-28 23:15:54 -05:00

README.md

some comments

2016-08-09 20:31:53 -04:00

replay_file.go

fixes from review

2017-12-28 23:15:54 -05:00

replay_test.go

bump wal test timeout

2017-12-29 17:51:13 -05:00

replay.go

fixes from review

2017-12-28 23:15:54 -05:00

state_test.go

separate block vs state based validation

2017-12-21 16:49:47 -05:00

state.go

ValidateBlock is a method on blockExec

2017-12-28 23:15:54 -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_fuzz.go

add gofuzz test for consensus wal

2017-12-15 11:56:24 -06:00

wal_generator.go

fixes from review

2017-12-28 23:15:54 -05:00

wal_test.go

handle data corruption errors

2017-12-11 19:48:20 -06:00

wal.go

Updates -> ValidatoSetUpdates

2017-12-19 13:03:39 -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.