Skip to content

Proposer priority value is not carried over after round skips #3044

@hendrikhofstadt

Description

@hendrikhofstadt

We are seeing proposers being reselected for a few blocks in a row in the game_of_stakes network

image

Here is what we were able to see:

Proposer Round of polka Height Proposer Priority of proposer
703 DF8C99E762662D4D575E3709C96B1A0FDC81B27D 0 -1001008
702 DA80EAEC28CB97523FCD34EAC3A48F3591338129 0 -965470
701 2B8ABD3EE563B006D71156784DB4D539E691C812 0 -955206
700 2B8ABD3EE563B006D71156784DB4D539E691C812 1 1828306
699 83AB321E012C57746689FED3A6064DF331F81007 0 -937074
698 83AB321E012C57746689FED3A6064DF331F81007 1 1832205
697 50C18305F49BE332E4C6BCDE0DEECD4A22B1D6A4 0 -931810
696 FBC7F1617ADECC38BEF6329F01F7E0123689C2CD 0 -939515
695 FBC7F1617ADECC38BEF6329F01F7E0123689C2CD 1 1820486
694 FBC7F1617ADECC38BEF6329F01F7E0123689C2CD 2 1810486
693 FBC7F1617ADECC38BEF6329F01F7E0123689C2CD 3 1800486
692 B2971B2E464209C6A925649252E5D2848B0A20AF 0 -992613
691 B2971B2E464209C6A925649252E5D2848B0A20AF 1 1776443
690 B2971B2E464209C6A925649252E5D2848B0A20AF 2 1761344
689 B2971B2E464209C6A925649252E5D2848B0A20AF 3 1746245
688 CD8EC884F2A65119F1AA953DE5BFCAF2C3A8B4DE 0 -1033338
687 B4D271B369B728E0A716300193E16DF68010B062 0 -1035199
686 B4D271B369B728E0A716300193E16DF68010B062 1 1733793
685 B4D271B369B728E0A716300193E16DF68010B062 2 1718814
684 B4D271B369B728E0A716300193E16DF68010B062 3 1687937
683 B4D271B369B728E0A716300193E16DF68010B062 4 1672959
682 6B275FFA0571EEFC4482CD7A6CAE836F5785CB4E 0 -1070297
681 6B275FFA0571EEFC4482CD7A6CAE836F5785CB4E 1 1688521
680 6B275FFA0571EEFC4482CD7A6CAE836F5785CB4E 2 1678521
679 6B275FFA0571EEFC4482CD7A6CAE836F5785CB4E 3 1668521
678 6B275FFA0571EEFC4482CD7A6CAE836F5785CB4E 4 1658521
677 6B275FFA0571EEFC4482CD7A6CAE836F5785CB4E 5 1648521
676 6B275FFA0571EEFC4482CD7A6CAE836F5785CB4E 6 1652793

This looks like that in rounds > 0 the proposer priority is not decremented for the actual proposer. This is most likely a bug in the proposer selection.

What is actually happening is:

Block 1 R0: Val C: round skip <- prio decremented
Block 1 R1: Val B: round skip
Block 1 R2: Val A: Proposes

Block 2 R0: Val B: round skip <- prio decremented
Block 2 R1: Val C: propose

Block 3 R0: Val C: propose <- prio decremented

==

I would expect the following:

Block 1 R0: Val C: round skip <- prio decremented
Block 1 R1: Val B: round skip <- prio decremented
Block 1 R2: Val A: Proposes <- prio decremented

Block 2 R1: Val D: propose <- prio decremented

==

NextValidators is already specified 1 block ahead so any updates to the proposer priority at the previous height are ignored (e.g. round skips).

In updateState instead of nValSet.IncrementProposerPriority(1) we could do nValSet.IncrementProposerPriority(n_rounds_prev_block)

CC: @ebuchman @zmanian @jaekwon @ValarDragon @milosevic @melekes

Metadata

Metadata

Assignees

No one assigned

    Labels

    C:consensusComponent: Consensusstalefor use by stalebot

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions