vote-interface: add fast deserialize for VoteStateVersions
#383
Conversation
|
|
||
| let variant = solana_serialize_utils::cursor::read_u32(&mut cursor)?; | ||
| match variant { | ||
| // V0_23_5 not supported. |
There was a problem hiding this comment.
Let's return InstructionError::UninitializedAccount for this instead of InvalidAccountData
| let vote_state = | ||
| unsafe { Box::from_raw(Box::into_raw(vote_state) as *mut VoteState1_14_11) }; |
There was a problem hiding this comment.
looks like you can do this without the into/from
| let vote_state = | |
| unsafe { Box::from_raw(Box::into_raw(vote_state) as *mut VoteState1_14_11) }; | |
| let vote_state = unsafe { vote_state.assume_init() }; |
There was a problem hiding this comment.
You can, but only for Rust 1.82 and above. I would have to reconfigure the MSRV checks on the workspace in order to allow vote-interface to move past everything else, or bump everything to 1.82.
| // | ||
| // V1_14_11 | ||
| 1 => { | ||
| let mut vote_state = Box::new(std::mem::MaybeUninit::uninit()); |
There was a problem hiding this comment.
nit: can you import MaybeUninit locally as well?
| /// | ||
| /// This is a convenience wrapper around `bincode::serialize_into`. | ||
| #[cfg(feature = "bincode")] | ||
| pub fn serialize(&self, output: &mut [u8]) -> Result<(), InstructionError> { |
There was a problem hiding this comment.
We can ride without it for now. If we need it later we can add it.
| unsafe { addr_of_mut!((*vote_state).authorized_withdrawer) }, | ||
| )?; | ||
| let commission = read_u8(cursor)?; | ||
| let votes = read_votes_as_lockouts(cursor)?; // `Vec<Lockout>` |
There was a problem hiding this comment.
This feels incredibly pedantic.
There was a problem hiding this comment.
haha yeah but it's also not the correct type so it stood out :P
403f4c2 to
66f0045
Compare
Problem
So far, we've mostly been serializing
VoteStateVersionswithbincode, or using the optimized path on either recent vote state (VoteStateV3::deserializeorVoteStateV4::deserialize). However, the former is not performant enough and the latter will coerce the underlying type into the target version upon deserialization regardless of its actual serialized version.The coercion of the underlying type is actually a problem and should be eliminated in future breaking changes to the vote interface. However, in the immediate term, we require an optimized path for deserializing
VoteStateVersionsin the Vote program without coercing the underlying type at all.Summary of Changes
Similar to
VoteStateV3andVoteStateV4, adds an optimized deserialization API forVoteStateVersions. Simply includes one more crate-private free function to deserialize into aV1_14_11vote state pointer and hooks up the deserializers to a newVoteStateVersions::deserializefunction that will deserialize intoVoteStateVersionsas-is with no coercion.I made the choice to disallow support for
V0_23_5, since it's been entirely phased out on all networks, it's not supported by the Vote program, and it has never really had deserialization support in this library. TheV0_23_5variant should be deprecated as well, which we can do in follow-up work.