feat: make pools history endpoint #121
Closed
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
…lock producing by vrf_key_hashes - Add blocks to keep track of temporary block number and minter's vrf_key_hash, because BlockFees message has no clue of vrf_key_hash - Include fees to EpochActivityMessage - Update test cases to check fee - update vrf_key_hashes state name to blocks_minted for better readability
- add active_stakes to store active_stakes for few epochs by spo key hash - remove active_stakes_history state - update get_pools_active_stakes function and handle_spdd function to accept new state and to update history - Updated state management to conditionally store epoch history based on configuration. - use and updated for performance
- Introduced VrfVkeyHashEpochState to track blocks minted and fees for vrf vkey hashes. - Updated State struct to conditionally store vrf vkey hashes history based on configuration. - Added methods to retrieve epoch state for vrf vkey hashes. - Improved logging for storing history configuration.
- Removed unnecessary Arc wrapping for the spo_stakes variable. - Simplified the parallel processing of stakes by using for_each instead of for_each_init. - Improved readability and performance of the stake aggregation logic.
- Introduced SPORewardState and SPORewardStateMessage structs to handle reward data for stake pools. - Updated generate_spdd function to return both stake distribution and reward state. - Implemented SPORewardStatePublisher for publishing reward state messages.
- Added PoolEpochHistory struct to store detailed information about each pool's performance per epoch, including blocks minted, active stake, delegators count, rewards, and fees. - Updated PoolHistory struct to include a vector of PoolEpochHistory. - Enhanced SPOState to retrieve pool history based on the new structure and handle SPO reward state updates accordingly. - Implemented query handling for pool history in the Blockfrost API.
…save blocks_minted count by spo - Added active_delegators_count to DelegatedStake to track active delegators. - Improved handling of epochs history and added functionality to retrieve SPO from vrf_key_hash.
- Added calculation of total active stake to determine the active size ratio for each epoch.
- Introduced PoolEpochStateRest struct to serialize epoch state data for REST responses. - Updated the pool history query to convert PoolEpochState to PoolEpochStateRest, enhancing the API's response structure.
- Introduced SPORewardsMessage struct to encapsulate rewards data for pool operators. - Implemented SPORewardsPublisher for publishing SPO rewards messages in accounts-state. - Added subscription handling for SPO rewards messages in SPOState.
- Corrected the comment in the publish_spo_rewards method to accurately reflect its purpose of publishing SPO rewards.
- Added a note clarifying that the calculated SPO rewards data is one epoch off compared to blockfrost's response.
- Added functionality to retrieve the latest epoch from the epoch state. - Updated pool history query to filter out epoch states that are greater than or equal to the latest epoch, ensuring accurate historical data retrieval.
golddydev
changed the title
whankinsiv
reviewed
Aug 26, 2025
| pub epoch: u64, | ||
| pub blocks_minted: u64, | ||
| pub active_stake: u64, | ||
| pub active_size: RationalNumber, |
There was a problem hiding this comment.
active_size could be computed in the REST handler if total_active_stake was stored by epoch.
There was a problem hiding this comment.
Well, that is why I used RationalNumber, decimal is only calculated on demand (rest handler)
There was a problem hiding this comment.
The current design is storing total_active_stake for each PoolEpochState as the denominator when this RationalNumber could be constructed in the REST handler.
| @@ -14,7 +14,7 @@ pub struct State { | |||
| current_epoch: u64, | |||
|
|
|||
| // Map of counts by VRF key hashes | |||
| vrf_vkey_hashes: HashMap<KeyHash, usize>, | |||
| blocks_minted: HashMap<KeyHash, usize>, | |||
There was a problem hiding this comment.
Nice. I found the previous name confusing as well.
modules/spo_state/src/state.rs
Outdated
| @@ -37,29 +44,35 @@ impl BlockState { | |||
| epoch: u64, | |||
| spos: HashMap<Vec<u8>, PoolRegistration>, | |||
| pending_deregistrations: HashMap<u64, Vec<Vec<u8>>>, | |||
| vrf_key_hashes: HashMap<Vec<u8>, Vec<u8>>, | |||
There was a problem hiding this comment.
It's difficult at a quick glance to determine what is actually being stored here. Consider providing a more descriptive name.
There was a problem hiding this comment.
Change that to vrf_key_to_pool_id_map
…rds publisher - Updated variable names from to for better clarity in the context of handling and publishing SPO rewards. - Adjusted comments to accurately describe the purpose of the variables and their relation to previous epochs. - Renamed to in BlockState to better reflect its functionality.
|
I am going to use |
sandtreader
reviewed
Aug 27, 2025
| @@ -19,6 +19,9 @@ pub struct RewardsResult { | |||
|
|
|||
| /// Rewards to be paid | |||
| pub rewards: Vec<(RewardAccount, Lovelace)>, | |||
|
|
|||
| /// SPO rewards | |||
| pub spors: Vec<(KeyHash, SPORewards)>, | |||
There was a problem hiding this comment.
+1 for spo_rewards being a better name
|
Continue with #125 |
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.
Add Pools History Endpoint and SPO Rewards Distribution
Overview
This PR implements a pools history endpoint by adding SPO (Stake Pool Operator) rewards tracking and pub/sub capabilities. The implementation includes new message types, data structures, and parallel processing improvements to support pool history queries.
Key Features
🏊♂️ Pool History Data Structure
PoolEpochStatetype: Tracks epoch-specific pool metrics including:📊 SPO Rewards Distribution (SPRD)
SPORewardsMessage: Publishes SPO rewards data at epoch boundariesSPORewardstype: Captures total rewards and operator rewards for each poolSPORewardsPublisher: Dedicated publisher for SPO rewards messages⚡ Performance Improvements
generate_spdd()DashMapfor thread-safe concurrent updates during parallel processing🔧 Enhanced Data Structures
DelegatedStake: Addedactive_delegators_countfield for pool history trackingRewardsResult: Addedsporsfield to capture SPO rewards dataPoolHistoryquery: Now includes actual history data structureTechnical Details
Message Flow
accounts-state, when an epoch ends,handle_epoch_activity()calculates rewards and returns SPO rewards dataSPORewardsPublishercardano.spo.rewardsfor SPO rewards distributionData Collection
API Integration
GetPoolHistoryquery now returns structuredPoolHistorywith epoch dataConfiguration
New configuration option:
store-history: Inspo-state, we can enable/disable history by setting up this boolean.NOTE:
rewardsandfees(SPO rewards data) are one epoch off from blockfrost's response. And will be fixed in upcoming PRs.