jito-foundation / stakenet Goto Github PK

Is your feature request related to a problem? Please describe.
Running a keeper for StakeNet isn't as efficient as it could be. There are likely too many transactions being sent on-chain.

Describe the solution you'd like
Find a better way to upload transactions by bulk writing transactions or potentially leveraging address lookup tables.

Note
Please comment below in the issue to claim this task.

Is your feature request related to a problem? Please describe.
If users want to explore StakeNet data, they need to use solana libraries and anchor. There should be an API implementation that anyone can host that acts as a proxy, cache, and translation layer which allows easily querying of the ValidatorHistoryAccount in a JSON format.

This API can be useful for any website that wants to show historical information on validator performance!

Describe the solution you'd like
A rust, axum-based API in this repository that allows one to query StakeNet data over a variety of endpoints to get information on validator performance.

The server arguments should include the bind IP and port, an RPC URL, the stakenet program IDs (validator history for now), and others. It should spin up an HTTP server and host a variety of endpoints that allow querying the performance of validators at given points in time.

Some of these endpoints can look like the following (I am not an API engineer, please take this with a grain of salt):

• GET /api/v1/validator_history/{vote_account}
• GET /api/v1/validator_history/{vote_account}?epoch={epoch}

Is your feature request related to a problem? Please describe.
Some validators run misconfigured for long periods of time, producing only non-vote blocks. In a stake delegation strategy, this should be heavily penalized.

Describe the solution you'd like
Determine how to measure this and build it. For instance, it could be something like:

• number of blocks with <5 non-vote transactions.
• number of blocks with 0 non-vote transactions.
• ???

Is your feature request related to a problem? Please describe.
The ValidatorHistoryAccount should track the block skip rate of every validator. It should be updated in semi-realtime.

Describe the solution you'd like
There's a few pieces of information that need to get stored on-chain to do this.

1. The leader schedule, which can be uploaded by the stake_authority, a permissioned authority that has the ability to update certain parameters that aren't stored on-chain. If it fits in a single account, it may make sense to store it there. If not, can potentially store it a PDA keyed by the validator's vote/identity account and the epoch with some lifetime associated with it to save on rent and state bloat. Need to keep in mind the account access patterns.
2. The SlotHistory sysvar can be used to check if a slot was skipped or not. The API requires a slot, so the slot -> pubkey mapping is needed.

This will be a tricky one, looking forward to seeing the implementation :)

Is your feature request related to a problem? Please describe.
It's not possible to compute the APY for a validator on-chain, but it should be possible with StakeNet and other contextual information that StakeNet can handle.

Describe the solution you'd like
In each validator's ValidatorHistoryAccount, store the staker APY for the validator given the validators commission, vote credits, epoch length, and any other variables required to compute the epoch. It probably makes sense to just store the current epoch's APY and do some averaging over the last N epochs using the circular buffer.

It may also make sense to add information about historical epochs to this program, such as the epoch start slot, start time, end slot, and end time. It makes sense for the stake_authority to handle as an administrator unless its fields already available on-chain. If there is other information that's needed that isn't available, one can create instructions for those accounts as well.

It may also be desirable to include the validator's MEV in the APY as that may be a significant contributing factor to a validator's staking APY. This can be leveraged by combining #6 with the validator's MEV commission also stored in the validator history account.

Is your feature request related to a problem? Please describe.
For indexing purposes and for blockahin explorers like Dune, it would be nice to log the state of a ValidatorHistoryAccount on every update.

Describe the solution you'd like
Any update that causes a change in a ValidatorHistoryAccount for a given epoch is logged. This logs can use emit! or even better, emit_cpi!, which doesn't suffer from log truncation inside RPCs.

Additional context
Ensure that any logs are compatible with most block explorers and Dune!

Note
Please comment below in the issue to claim this task.

Is your feature request related to a problem? Please describe.
In order to better track APY of validators and stake pools on chain, we need to know the real world time that epochs started. The ClusterHistory account is the logical place to store this network-level field.

Describe the solution you'd like
Use the epoch_start_ timestamp from the Clock sysvar to read this field on chain for the current epoch and store it in the ClusterHistoryEntry for this epoch. This can be done in the copy_cluster_info instruction.

Describe alternatives you've considered
N/A

Additional context
N/A

Is your feature request related to a problem? Please describe.
During a previous refactor, the engineers of this program accidentally re-arranged fields in the ValidatorHistoryEntry and corrupted data. It was fixed, but easy to do again in the future.

Describe the solution you'd like
Add tests to ensure the field layout of the ValidatorHistoryAccount doesn't change if fields are added, removed, or changed.

Is your feature request related to a problem? Please describe.
The ValidatorHistoryAccount should track the MEV earned per epoch for every validator on-chain. This allows one to determine the MEV / stake amount on-chain to determine how much MEV relative to stake every validator is receiving.

Describe the solution you'd like
The MEV earned every epoch is stored in the TipDistributionAccount, a PDA owned by the tip distribution program. After the merkle root is uploaded, the max_total_claim field can be referenced to find the total amount of MEV earned by the validator for a given epoch.

This can likely be copied over to the ValidatorHistory account in a modified version of the update_mev_comission instruction, which loads the tip distribution account. There would be a slight change to relax the epoch constraint and pass in the epoch as instruction data and ensure the MEV tips update the ValidatorHistoryAccount for the correct epoch.

In fact, it may be worth it to relax the epoch constraint on the update_mev_comission instruction as well to allow one to backfill missed epochs.

Is your feature request related to a problem? Please describe.
No, no problem per se

Describe the solution you'd like
Tracking the validators that make up the top 33% of stake
I haven't given much thought to this but it should be relatively easy to implement. Just track what validators make up 33% of total stake.

Describe alternatives you've considered
Computing this value off-chain but that seems to defeat the purpose of stakenet

Additional context
This feature is one step on the way to what I hope will be JIP-6. Do not stake to validators in Superminority

Is your feature request related to a problem? Please describe.
In the rare scenario that the Solana network goes down, the speed that validators start up is extremely important for resuming operations. StakeNet should be able to measure how fast validators come back online and track this data, penalizing validators that are slow to respond.

Describe the solution you'd like
StakeNet can track how fast a validator gets back online and keep track of it.

Describe alternatives you've considered
N/A

Additional context
N/A