Skip to content
This repository has been archived by the owner on Jan 13, 2025. It is now read-only.

Fix authorized voter ahead of time #8303

Merged
merged 1 commit into from
Feb 25, 2020

Conversation

carllin
Copy link
Contributor

@carllin carllin commented Feb 15, 2020

Problem

Authorized voter can change at any point during an epoch, making it hard to detect without monitoring vote account.

Working towards: #8232

Summary of Changes

Fix the authorized voter ahead of time, similar to epoch stakes based on the leader_schedule_epoch
Fixes #

@@ -39,6 +39,9 @@ pub enum VoteError {

#[error("authorized voter has already been changed this epoch")]
TooSoonToReauthorize,

#[error("cannot set same authorized voter as latest authorized voter")]
ReauthorizedSameVoter,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be an error or a noop?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Neither, I got rid of the error and now the behavior locks in the authorized voter again for that future epoch, preventing a switch

@@ -151,6 +157,14 @@ pub struct VoteState {
pub votes: VecDeque<Lockout>,
pub root_slot: Option<u64>,

/// the signer for vote transactions
authorized_voter: BTreeMap<u64, Pubkey>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is sorted so doesn't break consistency but make sure it doesn't grow unbounded.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can only grow as large as the number of epochs that we're using for the leader_schedule_offset + 1, so by default should be at most 2

@mvines
Copy link
Contributor

mvines commented Feb 15, 2020

This is an ABI change that'll break compatibility with v0.23.x, so we'll need to figure out a migration plan. Let's chat more on Monday

cc: @ryoqun

@carllin carllin force-pushed the FixVoteState branch 3 times, most recently from 9211718 to 546a37f Compare February 16, 2020 00:00
@codecov
Copy link

codecov bot commented Feb 16, 2020

Codecov Report

Merging #8303 into master will increase coverage by <.1%.
The diff coverage is 97%.

@@           Coverage Diff            @@
##           master   #8303     +/-   ##
========================================
+ Coverage    80.2%   80.3%   +<.1%     
========================================
  Files         253     254      +1     
  Lines       55975   56218    +243     
========================================
+ Hits        44929   45164    +235     
- Misses      11046   11054      +8

F: Fn(Pubkey) -> Result<(), InstructionError>,
{
let epoch_authorized_voter = self.get_and_update_authorized_voter(epoch).expect(
"the clock epoch is monotonically increasinig, so authorized voter must be known",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"the clock epoch is monotonically increasinig, so authorized voter must be known",
"the clock epoch is monotonically increasing, so authorized voter must be known",

@mvines
Copy link
Contributor

mvines commented Feb 16, 2020

Problem

Authorized voter can change at any point during an epoch, making it hard to detect without monitoring vote account.

Carl, what problem is this actually solving? It doesn't seem to to fix anything. Just trying to assess whether we should even make this change at all given it breaks ABI

mvines
mvines previously requested changes Feb 16, 2020
Copy link
Contributor

@mvines mvines left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.

@carllin
Copy link
Contributor Author

carllin commented Feb 16, 2020

@mvines, it allows for the ability to check for the authorized voter at the beginning of an epoch, and then have the confidence that that authorized voter will not change for the duration of the epoch without having to constantly checking the status of vote accounts

I need this to build an observer on gossip to count how much stake has been voting on a fork, which requires making sure the vote is coming from the authorized voter

@mergify mergify bot dismissed mvines’s stale review February 16, 2020 05:33

Pull request has been modified.

@mvines
Copy link
Contributor

mvines commented Feb 16, 2020

@mvines, it allows for the ability to check for the authorized voter at the beginning of an epoch, and then have the confidence that that authorized voter will not change for the duration of the epoch without having to constantly checking the status of vote accounts

I need this to build an observer on gossip to count how much stake has been voting on a fork, which requires making sure the vote is coming from the authorized voter

Thanks, that helps. What Github issue are you working towards on this? I'd generally expect new features like this to reference an issue and not seemingly come out of the air :-/

@@ -133,15 +148,6 @@ pub struct VoteState {
/// the node that votes in this account
pub node_pubkey: Pubkey,

/// the signer for vote transactions
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To preserve compatibility with 0.23.x, one option will be to create a VoteState023 struct that matches what's on 0.23.x. The master Vote program will then need to support deserializing VoteState023 into VoteState in its process instruction and elsewhere.

@carllin
Copy link
Contributor Author

carllin commented Feb 16, 2020

@mvines Updated with the relevant issue!

rob-solana
rob-solana previously approved these changes Feb 16, 2020
Copy link
Contributor

@rob-solana rob-solana left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@mergify mergify bot dismissed rob-solana’s stale review February 17, 2020 11:24

Pull request has been modified.

@carllin carllin force-pushed the FixVoteState branch 5 times, most recently from cf015b7 to 3fb9002 Compare February 18, 2020 06:27
@carllin carllin added the v0.23 label Feb 19, 2020
@carllin carllin force-pushed the FixVoteState branch 4 times, most recently from cfca8ed to c75fb53 Compare February 20, 2020 05:03
@carllin carllin mentioned this pull request Feb 20, 2020
@carllin carllin force-pushed the FixVoteState branch 2 times, most recently from 6db62a9 to 9f820a7 Compare February 21, 2020 22:03
@mvines mvines added the v1.0 label Feb 22, 2020
@carllin carllin force-pushed the FixVoteState branch 2 times, most recently from ea0ca05 to 2781420 Compare February 24, 2020 20:19
@carllin carllin added the automerge Merge this Pull Request automatically once CI passes label Feb 25, 2020
@solana-grimes solana-grimes merged commit 39282be into solana-labs:master Feb 25, 2020
@carllin carllin added the v1.0 label Feb 28, 2020
mergify bot pushed a commit that referenced this pull request Feb 28, 2020
automerge

(cherry picked from commit 39282be)
solana-grimes pushed a commit that referenced this pull request Feb 28, 2020
carllin pushed a commit to carllin/solana that referenced this pull request Mar 3, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
automerge Merge this Pull Request automatically once CI passes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants