-
Notifications
You must be signed in to change notification settings - Fork 30
Epoch Stake Syscall #133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Epoch Stake Syscall #133
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* ValidatorHistoryEntry now tracks the merkle_root_upload_authority * Steward includes a binary score related to merkle root upload authority merkle_root_upload_authority_score * Steward will allow instant unstake if there's an unacceptable merkle_root_upload_authority
Co-authored-by: gzalz <[email protected]>
**Problem** - Refactored functions need to be updated in tests - It is not clear that the byte array in realloc_test happy path is an old Config **Solution** - Update function names - Explicitly serialize an old Config for the realloc happy path test
Co-authored-by: Eric Gonzalez <[email protected]>
- Update README (mention about dependencies to build projects)
- Support JSON output
- `cluster-history-status`
- `history`
- `cranker-status`
```
cargo r -p validator-history-cli -- history J1to1yufRnoWn81KYg1XkTWzmKjnYSnmE2VY8DGUJ9Qv --start-epoch 825 --print-json | jq
{
"epochs": [
{
"epoch": 825,
"validator_history": {
"client_type": "[NULL]",
"client_version": "[NULL]",
"commission": "4",
"epoch_credits": "6804172",
"ip": "[NULL]",
"last_update_slot": "356791902",
"mev_commission": "800",
"mev_earned": "9.02",
"priority_fee_commission": "5000",
"priority_fee_tips": "18.007397451",
"rank": "71",
"stake": "1280689149832777",
"superminority": "0",
"total_leader_slots": "1412",
"total_priority_fees": "39.372700447"
}
},
{
"epoch": 826,
"validator_history": {
"client_type": "[NULL]",
"client_version": "[NULL]",
"commission": "4",
"epoch_credits": "3481756",
"ip": "[NULL]",
"last_update_slot": "357050804",
"mev_commission": "800",
"mev_earned": "[NULL]",
"priority_fee_commission": "65535",
"priority_fee_tips": "18446744073.709553",
"rank": "70",
"stake": "1286776095780864",
"superminority": "0",
"total_leader_slots": "1436",
"total_priority_fees": "32.62989773"
}
}
],
"validator": "J1to1yufRnoWn81KYg1XkTWzmKjnYSnmE2VY8DGUJ9Qv",
"validator_history_account": "3agAXJk2bvTJ8VmEGMDXbt22irKjYxZ2XybCRnUontvN"
}
```
- Support `--version`
```bash
cargo r -p validator-history-cli -- --version
validator-history-cli 0.1.0
```
Collaborator
|
@mrmizz added some small comments -- think it's in a pretty good place now. Could you clean up this PR at some point to remove all the extra commits from the priority fee merge (maybe cherry picking your changes onto a new branch, or rebasing) cause it's hard to see the isolated changes now |
2ab3929 to
cea6615
Compare
Contributor
Author
|
Closing in favor of #152 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Introduces four new instructions:
ValidatorStakeBufferis a new singleton account that allocates a (rather large) buffer, where we can insert active epoch stake amounts for vote accounts.The intent is to provide a permission-less variant of the
UpdateStakeHistoryinstruction. For this -- we need to observe the active stake amounts of all vote accounts and compute a sorted rank, onchain.We use the
get_epoch_stake_for_vote_accountsysvar to observe the stake amounts onchain, one by one for each vote account, and insert them into this fat buffer with sorted descending order.Once all vote accounts (that have validator history accounts) have been observed and inserted, the buffer is finalized. With the finalized buffer we can then use the
CopyStakeInfoinstruction to read from the buffer and insert a new entry into theCircBufof the validator history account.It is important to note that the buffer can only be written to, finalized, and read from, in the current epoch. That is because the syscall used to populate the buffer only reports current epoch data. There is no historic data available. This means that if the keeper clients were to miss an epoch, we would not be able to backfill without an oracle signer.
Another important note, is that because this new
CopyStakeBufferdoes not require an oracle authority to sign, anyone can actually use this instruction to overwrite a keeper that is still using theUpdateStakeHistoryinstruction. We could mitigate this by adding an oracle signer to this new instruction, for the time being. Although, this is a not a huge issue because an oracle signer can always backfill with final say so long as we keep that instruction around.The size of the buffer is also interesting to comment on. At 50,000 elements, the worst case insert into the buffer consumes roughly 700,000 CUs (half the maximum). The best case insert (tail push) consumes roughly 17,000 CUs, irrespective of buffer size. This was extensively tested with integration tests, included in this PR.
Lastly, the buffer size does not inherently limit the number of validator history accounts the program can initialize. Rather, there is as race to fill the buffer. And that race is finalized when either all validator history accounts have been inserted, or the end of the buffer is reached.