new short term election algorithm#3270
Conversation
|
The latest Buf updates on your PR. Results from workflow Buf / buf (pull_request).
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## release/v6.4 #3270 +/- ##
================================================
+ Coverage 58.33% 58.39% +0.05%
================================================
Files 2091 2091
Lines 172978 172990 +12
================================================
+ Hits 100914 101012 +98
+ Misses 63050 62981 -69
+ Partials 9014 8997 -17
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
| // pos(height,round) := hash(height ++ round) | ||
| // Validators are assigned subintervals of [0,TotalVotingPower) of length | ||
| // equal to their voting poser. | ||
| // Validator i is the leader of (height,round) <=> pos(height,round)%TotalVotingPower \in validator_interval[i] |
There was a problem hiding this comment.
Are we planning to do per-height calculation later?
There was a problem hiding this comment.
yup, for the long term solution. And I would like first to compute what is the actual impact on block latency if we intriduce it.
| totalVotingPower int64 | ||
| } | ||
|
|
||
| func (vals *ValidatorSet) All() iter.Seq[*Validator] { |
There was a problem hiding this comment.
nit: add comment why the returned set is deterministic? We might need to warn future AI agent that do not mutate Validators without sorting them by ValidatorsByVotingPower?
There was a problem hiding this comment.
Renamed to Ordered and documented the function. If the ordering changes, it should be caught by the change detector test that I've added.
| // If this validator is the proposer of this round, and the previous block time is later than | ||
| // our local clock time, wait to propose until our local clock time has passed the block time. | ||
| if key, ok := cs.privValidatorPubKey.Get(); ok && cs.isProposer(key.Address()) { | ||
| if key, ok := cs.privValidatorPubKey.Get(); ok && cs.roundState.Leader() == key { |
There was a problem hiding this comment.
nit: Would bytes.Equal(leader.Address(), key.Address()) be more future proof?
There was a problem hiding this comment.
why would it? Address is derived from public key. Honestly I don't understand why the concept of Address exists - to save space maybe?
f72a7e3 to
e6b9338
Compare
|
/backport |
|
Successfully created backport PR for |
Backport of #3270 to `release/v6.5`. Co-authored-by: Grzegorz Prusak <pompon.pompon@gmail.com>
The new algorithm is choosing leader of (height,round), based on hash(height,round) and weights of validators (public lottery). The new algorithm is enabled via config flag: Consensus.StatelessLeaderElection (false by default). It will be the only option in 6.5. Additional changes: