Choosing a proposer is incorrect

[JekaMas]

Type:

Issue

What happened? / What do you need?:

The voter selection algo is incorrect and its possible that some validators won't be chosen:

=== RUN   TestVoters_UpdateWeightChangesProposerElectionsWith2VotersEventual
--- FAIL: TestVoters_UpdateWeightChangesProposerElectionsWith2VotersEventual (4.21s)
	Error Trace:	voters_test.go:287
	Error:      	Should be true
	Messages:   	address '0x5000000000000000000000000000000000000000' hadn't been chosen
	Error Trace:	voters_test.go:290
	Error:      	Relative error is too high: 0.005 (expected)
	            	        < 1 (actual)
	Messages:   	expected for '0x5000000000000000000000000000000000000000' 0.1000, got 0.0000
	Error Trace:	voters_test.go:290
	Error:      	Relative error is too high: 0.005 (expected)
	            	        < 0.11111166666666672 (actual)
	Messages:   	expected for '0x6000000000000000000000000000000000000000' 0.6000, got 0.6667
	Error Trace:	voters_test.go:290
	Error:      	Relative error is too high: 0.005 (expected)
	            	        < 0.11111000000000001 (actual)
	Messages:   	expected for '0x7000000000000000000000000000000000000000' 0.3000, got 0.3333

and even if everyove voter has been chosen, the probabilities of such events are different from expected:

=== RUN   TestVoters_UpdateWeightChangesProposerElectionsWith2VotersEventual
--- FAIL: TestVoters_UpdateWeightChangesProposerElectionsWith2VotersEventual (4.28s)
	Error Trace:	voters_test.go:290
	Error:      	Relative error is too high: 0.005 (expected)
	            	        < 0.09208327272727271 (actual)
	Messages:   	expected for '0x5000000000000000000000000000000000000000' 0.3056, got 0.2774
	Error Trace:	voters_test.go:290
	Error:      	Relative error is too high: 0.005 (expected)
	            	        < 0.016552000000000008 (actual)
	Messages:   	expected for '0x6000000000000000000000000000000000000000' 0.3241, got 0.3187
	Error Trace:	voters_test.go:290
	Error:      	Relative error is too high: 0.005 (expected)
	            	        < 0.09045170000000001 (actual)
	Messages:   	expected for '0x7000000000000000000000000000000000000000' 0.3704, got 0.4039

It was checked for 10000, 1000000, 10000000 and 1000000000 rounds. The result is stable.

E.g for 3 validators with 100,300,600 deposits first 20 rounds looks like
round 0: 200 600+ 600
round 1: 300 600+ 900
round 2: 400 600+ 1200
round 3: 500 1200 1200+
round 4: 600 1200+ 1500
round 5: 700 1200+ 1800
round 6: 800 1800 1800+
round 7: 900 1800+ 2100
round 8: 1000 1800+ 2400
round 9: 1100 2400 2400+
round 10: 1200 2400+ 2700
round 11: 1300 2400+ 3000
round 12: 1400 3000 3000+
round 13: 1500 3000+ 3300
round 14: 1600 3000+ 3600
round 15: 1700 3600 3600+
round 16: 1800 3600+ 3900
round 17: 1900 3600+ 4200
round 18: 2000 4200 4200+
round 19: 2100 4200+ 4500

'+' stands for selected voter
numbers - weights for 1,2,3 voter corresponding

So 2nd and 3rd voters increase it's weights faster than 1st.

In opposite Tendermint with the same values works fine even for 20 rounds tendermint/tendermint@master...JekaMas:test/proper-selection (https://github.com/JekaMas/tendermint/tree/test/proper-selection)

It looks like that client/core/types/voters.go NextProposer() doesn't work properly.

If it's a request, what do you need it for?:

To make the probability to be chosen as a proposer corresponding to validators' weights.

If it's an issue, how can we reproduce it?:

Run tests in client/core/types/voters_test.go in 12907c4

Priority:

Medium

[JekaMas]

The second problem:
if validator starts away after others, it states will be different from the entire network.

It seems that voting is a part of a replicated state machine and somehow should be syncked.