vote-program: outfit to fully support vote state v4#8163
vote-program: outfit to fully support vote state v4#8163buffalojoec wants to merge 7 commits intoanza-xyz:masterfrom
Conversation
|
The Firedancer team maintains a line-for-line reimplementation of the |
buffalojoec
changed the title
buffalojoec
force-pushed
the
vote-state-handler-v4-variant-configure
branch
from
1a55688 to
6f1fcb3
Compare
| if vote_state_v4_enabled { | ||
| // v4 is always "initialized" per SIMD-0185. | ||
| let v4 = VoteStateV4::deserialize(accounts[0].data(), &vote_pubkey).unwrap(); | ||
| // After deinitialize, it contains default state. | ||
| assert_eq!(v4, VoteStateV4::default()); | ||
| } else { |
There was a problem hiding this comment.
This test is very strange to me. Why not keep the same check for v4?
let post_state: VoteStateVersions = accounts[0].state().unwrap();
assert!(post_state.is_uninitialized());There was a problem hiding this comment.
Because .is_uninitialized() is always false for v4. Maybe it's a smell?
There was a problem hiding this comment.
But it would be deserialized as v1 since we zero the entire account
| ) -> Result<VoteStateHandler, InstructionError> { | ||
| let mut vote_state = | ||
| VoteStateHandler::deserialize_and_convert(vote_account, VoteStateTargetVersion::V3)?; | ||
| let mut vote_state = VoteStateHandler::deserialize_and_convert(vote_account, target_version)?; |
There was a problem hiding this comment.
The implementation of VoteStateV4::deserialize for zeroed account data is not ideal. It will successfully deserialize into an uninitialized v1 and then convert to VoteStateV4::default() which will incorrectly be considered to be "initialized." Ideally we first deserialize VoteStateVersions here and then do the initialization check before converting to v4.
|
Closing in favor of several other piecemeal PRs to land this feature. |
2 participants
Problem
Now that #8120 has landed,
VoteStateV4is now compatible with theVoteStateHandleAPI used by the Vote program. However, both the handler and the program themselves don't directly support v4 vote state.In order to enable this support and thus complete the implementation of SIMD-0185, the Vote program must be outfitted to support
VoteStateV4.Summary of Changes
First add a new
TargetVoteStateVersion::V4variant to theVoteStateHandlerstruct and flesh out the unit tests for the handler. Then, plumb atarget_version: TargetVoteStateVersionparameter throughout the Vote program.With the addition of the new parameter I overhauled a bunch of tests but tried to keep everything pinned to v3-only, until finally adding the feature gate in the second-last commit and converting the rest of the tests.
In the final commit, I took a stab at addressing some offline discussion @jstarry and I were having about v1 vote account states being accidentally deserialized as initialized v4 states, since v4 are always initialized.