Page MenuHomePhabricator

[avalanche] Set local stake winner in the contender cache
ClosedPublic

Authored by roqqit on Dec 11 2024, 23:43.

Details

Reviewers
Fabien
Group Reviewers
Restricted Owners Package(Owns No Changed Paths)
Restricted Project
Commits
rABCb1cea59f8291: [avalanche] Set local stake winner in the contender cache
Summary

The locally selected stake winner should be treated as accepted by default and put in the winner set. This way, the cache can flip flop on the voted status without removing the local winner until it is invalidated.

Depends on D17336

Test Plan
ninja check check-functional

Make sure to cover the case where the selected quorum proof happens to be the local winner:

for I in {0..30}; do ./test/functional/test_runner.py abc_p2p_avalanche_contender_voting || break ; done

Event Timeline

Owners added a reviewer: Restricted Owners Package.Dec 11 2024, 23:43
roqqit requested review of this revision.Dec 11 2024, 23:43
Fabien requested changes to this revision.Dec 12 2024, 09:59
Fabien added a subscriber: Fabien.

Questions more than requesting changes

src/avalanche/processor.cpp
914

could this happen ? In this case our vote will be incorrect ?

1062

Shouldn't you loop over all winners here ? So your initial vote is yes for all of them ?

This revision now requires changes to proceed.Dec 12 2024, 09:59
roqqit requested review of this revision.Dec 16 2024, 18:20
roqqit added inline comments.
src/avalanche/processor.cpp
914

Promotion happens when updatedBlockTip is called. My understanding is there are no strong guarantees that updatedBlockTip is called before staking rewards are computed.

The vote could theoretically be incorrect for a very short period (milliseconds) until promotion occurs. I am considering mitigating this by tracking the last block index that was promoted and then voting PENDING for blocks after that.

1062

A near future patch will be doing this for the other potential winners. They are treated slightly differently in that winner 0 is in the winner set while winners 1+ are only accepted until they are finalized by the network. I could do that as part of this patch but I want to do it in the frame of mind that these are distinct behaviors and so deserve separated attention.

Fabien requested changes to this revision.Dec 17 2024, 10:31
Fabien added inline comments.
src/avalanche/processor.cpp
914

I see, indeed updatedBlockTip is on the scheduler thread. But if this is a no-op, what will make the status be updated later ? Afaict this function is only called once

This revision now requires changes to proceed.Dec 17 2024, 10:31
roqqit requested review of this revision.Dec 18 2024, 17:26
roqqit added inline comments.
src/avalanche/processor.cpp
914

It is also called in promoteStakeContendersToTip. One of the calls will succeed.

This revision is now accepted and ready to land.Dec 18 2024, 20:22