SIMD-0185: Vote Account v4 #185
Conversation
jstarry
force-pushed
the
vote-account-v4
branch
from
3fc627d to
9d8dedb
Compare
| `authorized_voters` field that correspond to epochs less than the current epoch, | ||
| only purge entries less than the previous epoch (current epoch - 1). This will | ||
| mean that the `authorized_voters` field can now hold up to 4 entries for the | ||
| epochs in the range `[current_epoch - 1, current_epoch + 2]`. Keeping the |
There was a problem hiding this comment.
is there a reason we need to store current_epoch + 2?
There was a problem hiding this comment.
Yeah that's the current design and I think it kinda makes sense because otherwise you could set a new authorized voter at the end of an epoch and immediately start using it in the next block in the new epoch and leaders would need an up to date view on any new authorized voters for each fork crossing the epoch boundary
|
I'm sorry, why is |
Up for debate still, but I put it there for now since it's easier to update the vote account all in one go. If that field remains unused by the protocol it can be used for something else in the future. |
|
Is this about a new instruction to pay the leader who landed a successful transaction? |
|
I updated the proposal to use basis points for commission values and to remove any special handling for block tips for now. |
|
@AshwinSekar I've updated the SIMD to only remove the |
Got it, happy to approve. I do think it would be a lot faster if we could get away with one migration to remove |
Yeah maybe that's still the best approach. There's just a lot of changes I want to make:
Would we use a single feature gate for all of these changes? I think that could be fine. We will have a separate feature gate for SIMD-0123 anyways to actually make use of these new fields. |
This reverts commit 68a231b.
|
Can this be incorporated into this SIMD? |
|
Just pushed another update to this SIMD to add more detail to the required changes section and some other minor cleanup and renaming. It'd be great to get another review pass from anza devs @AshwinSekar @buffalojoec @t-nelson and fd devs @lidatong @topointon-jump |
| The existing withdraw instruction MUST be modified to completely zero vote | ||
| account data for fully withdrawn vote accounts. The old behavior partially | ||
| zeroed the account data following the vote state version discriminant and is | ||
| less intuitive. |
There was a problem hiding this comment.
I felt this was a nice to have change. This way we know that any vote account with the version discriminant bytes 03 00 00 00 is still initialized. Other vote state versions require checking fields for initialized values to be sure of initialization which is a footgun IMO.
| If a modified vote account's size is smaller than `3762` bytes, first resize the | ||
| account to `3762` bytes before updating the account data. The vote program does | ||
| not need to check if the resulting account is rent exempt, the runtime will | ||
| enforce that check. This differs from the prior vote program implementation which | ||
| falls back to store vote state as v2 if the account size cannot be resized while | ||
| keeping the account rent exempt. |
There was a problem hiding this comment.
I felt this was nice to have because it simplifies the vote program implementation and ensures that all v4 vote accounts have the same size. Here's the current code in question that this will clean up:
No description provided.