vote-interface: add read api #357
Conversation
There was a problem hiding this comment.
Each method here is used by some component in Agave, such as CLI, RPC, Core, or Stakes, as well as the Stake program.
| /// Returns the inflation rewards commission in basis points. | ||
| fn inflation_rewards_commission_bps(&self) -> u16; |
There was a problem hiding this comment.
I went with "inflation rewards" instead of "commission", since it's a more accurate name for even the legacy field, and basis points rather than percentage to avoid a future breaking change. It's also easier to test with v4 in Agave if we can get the value in basis points, even though the program floors to the nearest percentage anyway.
| VoteStateVersions::V0_23_5(_state) => { | ||
| // V0_23_5 does not have AuthorizedVoters struct. | ||
| unimplemented!("V0_23_5 does not support authorized_voters.") | ||
| } |
There was a problem hiding this comment.
Obviously this is a bit problematic. It has an authorized_voter field, but it doesn't allow us to return a reference to an actual AuthorizedVoters type.
We have a few options:
- Refactor this method and use a trait-based accessor for querying authorized voters. Many callsites in Agave only care about the length, but a few do actually want an iterator over voters or some way to query an authorized voter by epoch.
- Either panic here or make the function fallible (ie.
Result<&AuthorizedVoters, InstructionError>. - Remove
V0_23_5fromVoteStateVersions.
The last one is probably the best call IMO, since it's not used anywhere in Agave and we know there are no v1 vote accounts on-chain anymore.
There was a problem hiding this comment.
We will still probably want to keep an enum variant in VoteStateVersions for deserializing Uninitialized state. Maybe we add a separate enum for vote state versions which excludes v1 and only includes the versions which have authorized voters
| fn votes(&self) -> &VecDeque<LandedVote> { | ||
| match self { | ||
| VoteStateVersions::V0_23_5(_state) => { | ||
| // V0_23_5 uses VecDeque<Lockout>, not VecDeque<LandedVote>. | ||
| unimplemented!("V0_23_5 does not support votes.") | ||
| } | ||
| VoteStateVersions::V1_14_11(_state) => { | ||
| // V1_14_11 uses VecDeque<Lockout>, not VecDeque<LandedVote>. | ||
| unimplemented!("V1_14_11 does not support votes.") | ||
| } | ||
| VoteStateVersions::V3(state) => state.votes(), | ||
| VoteStateVersions::V4(state) => state.votes(), | ||
| } | ||
| } |
There was a problem hiding this comment.
Here we can probably remedy the variance in votes types between older vote states and newer ones by making this function return an iterator over LandedVote items. However, a generic iterator doesn't guarantee any dequeue behavior. The program would still need access to &VecDequeue<LandedVote>, but that can live under the VoteStateHandle trait if need be.
There was a problem hiding this comment.
do we need VecDeque in the read api?
|
@jstarry I actually think - if we're going to go this route - the best move is to just only include the ones that are straightforward for now, and see if we can live without Adding new methods is technically breaking, but this change right now isn't. |
8563ac2 to
01c7c94
Compare
01c7c94 to
16e7ff3
Compare
Adds a read-only API that covers
VoteStateVersions,VoteStateV4andVoteStateV3.