Core BPF Development Notes

[buffalojoec]

Core BPF Development Notes

Notes as of 04-11-2024.

State Refactoring

Vote state is spread across the SDK and the Vote program itself in the monorepo.
This will no longer be the case.

Any state required by the program will be defined in the program's crate, and
whatever can be hoisted to the client will be hoisted.

The transaction helpers in vote_transaction should probably get their own
crate or live somewhere in an existing monorepo crate, for nodes to use to send
vote transactions. However, it's relevant to leverage the new BPF Vote program's
client, at least.

As a side note: many previously public functions - especially those exported by
vote_state - will no longer be accessible. They were not used internally by
other crates in the monorepo, and many are processor-specific functions, so the
breakage should be minimal. A deprecation of the entire vote module in the SDK
should do the trick.

Examples:

• initialize_account
• authorize

Sysvar Use

Heavy use:

• Clock
• Rent

Partial use:

• EpochSchedule
• SlotHashes

Details on use of SlotHashes are described in
this issue,
but in summary, SlotHashes is used to verify vote slots are present in the
slot hashes (valid block-producing slots). Only after these checks are done is
when the actual Hash part of a slot hashes entry is needed.

This use of SlotHashes can easily be implemented with the new syscall
introduced in SIMD 0127.

Feature Gates

Active features:

• vote_state_add_vote_latency
  • When setting vote state, used to determine whether or not to use the newer
    vote state.
• commission_updates_only_allowed_in_first_half_of_epoch
  • Restricts commission updates to the first half of the epoch in the
    update_commission instruction.

Inactive features:

• allow_commission_decrease_at_any_time
  • Essentially overrides the restrictions (first half of epoch) enforced by
    commission_updates_only_allowed_in_first_half_of_epoch for commission
    decreases.
• timely_vote_credits
  • When processing a vote slot, latency is computed (previously 0) and then
    later used to calculate the vote credit based on latency.
• deprecate_unused_legacy_vote_plumbing
  • Combined with timely_vote_credits, this feature cleans up some plumbing in
    the vote instruction. There's not a lot of documentation on this one, but
    I'm assuming it comes after timely_vote_credits?

SIMD 0138

SIMD 0138 plans to deprecate the instructions Vote, UpdateVoteState and
CompactUpdateVoteState. We can likely remove these from the BPF
implementation, depending on migration feature gate timing..