Switching to VoteStateV4.#456
Conversation
bw-solana
left a comment
There was a problem hiding this comment.
Can we add a PR description?
Also, it would be nice to create multiple, smaller PRs for things that can be separated. For example dropping solana_bls_signatures::signature::Signature as BlsSignature and just using Signature directly is unrelated cosmetic change and could be forked out
| pub(crate) struct BLSKeypairWithCompressedPubkey { | ||
| pub keypair: Arc<BLSKeypair>, | ||
| pub compressed_pubkey: [u8; BLS_PUBLIC_KEY_COMPRESSED_SIZE], | ||
| } |
There was a problem hiding this comment.
feels a little funky having this since the compressed_pubkey can be derived from the keypair. Should we have separate APIs and let callers decide how they want to access and mix/match things?
There was a problem hiding this comment.
Moving this to another PR later.
That's fair. We don't strictly need anything after a24e3ca, I was just bored and started fixing small inefficiencies. I'll remove that from this PR. |
dbdc7ed to
a24e3ca
Compare
| vote_state.set_epoch_credits(epoch_credits); | ||
| vote_state.serialize_into(vote_account.data_as_mut_slice()); | ||
| let current_credits = vote_state.epoch_credits.last_mut().unwrap(); | ||
| current_credits.1 += 16; |
There was a problem hiding this comment.
Rather than doing current_credits.1, could we do let (x, y, ...) = vote_state.epoch_credits.last_mut().unwrap()?
| account | ||
| .bls_pubkey() | ||
| .map(|bls_pubkey| (*pubkey, *bls_pubkey, *stake)) | ||
| account.vote_state_view().and_then(|vote_state| { |
There was a problem hiding this comment.
This is a bit hard to read - could we unnest / clean this a bit?
| } | ||
|
|
||
| pub fn bls_pubkey(&self) -> Option<&BLSPubkey> { | ||
| pub fn bls_pubkey(&self) -> Option<BLSPubkey> { |
There was a problem hiding this comment.
This doesn't seem right - shouldn't invoking bls_pubkey() return None for TowerBFT and Some(...) for Alpenglow?
There was a problem hiding this comment.
This part is a mess and will go away in the next PR, we will no longer have TowerBFT or Alpenglow option.
| let vote_account_pubkey = context.vote_account_pubkey; | ||
| let authorized_voter_keypair; | ||
| let bls_pubkey_in_vote_account; | ||
| let bls_pubkey_in_vote_account: BLSPubkey; |
There was a problem hiding this comment.
I don't think we need to forward declare this variable - could we move it to the site of initialization and remove the annotated type, unless really needed?
There was a problem hiding this comment.
This is mainly done to release context.authorized_voter_keypairs read lock asap
| VoteAccountState::TowerBFT(vote_state) => vote_state.bls_pubkey_compressed().map(|b| { | ||
| let bls_pubkey_compressed = | ||
| bincode::deserialize::<BLSPubkeyCompressed>(&b).unwrap(); | ||
| BLSPubkeyCompressed::try_as_affine(&bls_pubkey_compressed).unwrap() |
There was a problem hiding this comment.
@samkim-crypto just double checking this is the right transformation
There was a problem hiding this comment.
It's pretty ugly, but should be correct because all local-cluster tests are passing :) We've turned on BLS verification now.
There was a problem hiding this comment.
So VoteStateV4 only says "give me a 48 byte buffer as bls pubkey", it doesn't care what's in it or whether it decodes properly for now. This PR (and anza-xyz/agave#8122 on Agave side) decides we serialize the compressed pubkey into the 48 byte buffer.
There was a problem hiding this comment.
Yes, I confirm that this is the right transformation.
| AlpenglowVoteState::create_account_with_authorized( | ||
| &vote_pubkey, | ||
| vote_state::create_v4_account_with_authorized( | ||
| &solana_pubkey::new_rand(), |
There was a problem hiding this comment.
out of curiosity why does this need to change?
There was a problem hiding this comment.
AlpenglowVoteState::create_account_with_authorized will create a vote state belonging to our new vote program, we are ditching our new vote program everywhere and replacing it with VoteStateV4 accounts.
AshwinSekar
left a comment
There was a problem hiding this comment.
Thanks for doing this! Can we remove the vote state related stuff from votor-messages now?
Not yet, we need to remove the vote-account hack first. I'll get to that today. |
Uh oh!
There was an error while loading. Please reload this page.