Skip to content

Conversation

@mrmizz
Copy link
Contributor

@mrmizz mrmizz commented Jul 16, 2025

Introduces four new instructions:

  • UpdateStakeBuffer
  • CopyStakeInfo
  • InitializeStakeBuffer
  • ReallocStakeBuffer

ValidatorStakeBuffer is 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 UpdateStakeHistory instruction. 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_account sysvar 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 CopyStakeInfo instruction to read from the buffer and insert a new entry into the CircBuf of 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 CopyStakeBuffer does not require an oracle authority to sign, anyone can actually use this instruction to overwrite a keeper that is still using the UpdateStakeHistory instruction. 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.

tomjohn1028 and others added 30 commits April 15, 2025 11:26
* 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
**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
gzalz and others added 18 commits July 30, 2025 14:26
- 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
```
Base automatically changed from feat/add-priority-fee-support to master August 5, 2025 16:22
@ebatsell
Copy link
Collaborator

ebatsell commented Aug 6, 2025

@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

@mrmizz
Copy link
Contributor Author

mrmizz commented Aug 7, 2025

Closing in favor of #152

@mrmizz mrmizz closed this Aug 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants