* add missing options to config.toml template and docs
Refs #2232
* config#ValidateBasic
Refs #2232
* [config] timeouts as time.Duration, not ints
Why:
- native type provides better guarantees than ", in ms" comment (harder
to shoot yourself in the leg)
- flexibility: you can change units
* follow up to removing some consensus params Refs #2382
* change args type to int64 in state#makeParams
* make valsCount and evidenceCount ints again
* MaxEvidenceBytesPerBlock: include magic number in godoc
* [spec] creating a proposal
* test state#TxFilter
* panic if MaxDataBytes is less than 0
* fixes after review
* use amino#UvarintSize to calculate overhead
0c74291f3b/encoder.go (L85-L90)
* avoid cyclic imports
* you can do better Go, come on
* remove testdouble package
* Make mempool aware of MaxGas requirement
* update spec
* Add tests
* Switch GasWanted from kv store to persistent kv store
* Fix typo in test name
* switch back to using kvstore, not persistent kv store
* remove ConsensusParams.TxSize and ConsensusParams.BlockGossip
Refs #2347
* block part size is now fixed
Refs #2347
* use max data size, not max bytes for tx limit
Refs #2347
- state.MakeBlock takes a proposerAddr
- validateBlock only checks that the ProposerAddress is in the validator
set
- fix raceyness from bad proposer test:
- use privValidator to get the proposer address (instead of racy
state)
- note we had to remove the test that checked the correct proposer was
included for higher rounds because we don't have a good way to test
this with multiple consensus states and not using the
privValidator.Address while calling createProposalBlock was a hack!
Refs #2072
We most probably shouldn't be running any further when there is some
unexpected panic. Some unknown error happened, and so we don't know if
that will result in the validator signing an invalid thing. It might be
worthwhile to explore a mechanism for manual resuming via some console
or secure RPC system, but for now, halting the chain upon unexpected
consensus bugs sounds like the better option.
* #1920 try to fix race condition on proposal height for published txs
- related to create_empty_blocks=false
- published height for accepted tx can be wrong (too low)
- use the actual mempool height + 1 for the proposal
- expose Height() on mempool
* #1920 add initial test for mempool.Height()
- not sure how to test the lock
- can the mutex reference be of type Locker?
-- this way, we can use a "mock" of the mutex to test triggering
* #1920 use the ConsensusState height in favor of mempool
- gets rid of indirections
- doesn't need any "+1" magic
* #1920 cosmetic
- if we use cs.Height, it's enough to evaluate right before propose
* #1920 cleanup TODO and non-needed code
* #1920 add changelog entry
* When create_empty_blocks=false, we don't enterPropose until we
* receive a transaction, but if we then receive a complete proposal,
* we should enterPrevote. A guard in addProposalBlockPart was checking if
* step==Propose before calling enterPrevote, but we need it to be step<=Propose,
* since we may not have seen a tx.
* This was discovered by disabling mempool broadcast, sending txs to
* peers one a time, and observing their consensus logs.
* updateToState exits early if the state isn't new, which happens after
* fast syncing. This results in not sending a NewRoundStep message. The mempool
* reactor depends on PeerState, which is updated by NewRoundStep
* messages. If the peer never sends a NewRoundStep, the mempool reactor
* will think they're behind, and never forward transactions. Note this
* only happens when `create_empty_blocks = false`, because otherwise
* peers will move through the consensus state and send a NewRoundStep
* for a new step soon anyways. Simple fix is just to send the
* NewRoundStep message during updateToState even if exit early
Anton Kaliaev
Matthew Slipper
Zarko Milosevic
Dev Ojha
Ethan Buchman
Jae Kwon
srmo
Zach Ramsay
Liamsi