Skip to content
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

BakerPoolRewardDetails hashing and updating improvements #1109

Open
td202 opened this issue Dec 13, 2023 · 0 comments
Open

BakerPoolRewardDetails hashing and updating improvements #1109

td202 opened this issue Dec 13, 2023 · 0 comments
Labels
[Size] Small [Type] Change Request Some visible functionality should be change. [Type] Maintenance Cleanup or handling of technical debt.

Comments

@td202
Copy link
Contributor

td202 commented Dec 13, 2023

Currently, the BakerPoolRewardDetails are stored in an LFMBTree using BufferedRef references:

      -- | The details of rewards accruing to baker pools.
      --  These are indexed by the index of the baker in the capital distribution (_not_ the BakerId).
      bakerPoolRewardDetails :: !(LFMBT.LFMBTree Word64 BufferedRef BakerPoolRewardDetails),

One problem with this is that the reward details of the baker of a block (at least) are updated every block, and so the hash needs to be recomputed. For BufferedRef, the hashes of nodes in the LFMBTree are not cached, and will be recomputed for the entire tree when we need the hash. HashedBufferedRef should avoid this.

Related to this, bsoMarkFinalizationAwakeBakers actually touches all of the entries in BakerPoolRewardDetails for bakers that are to be marked as awake for finalization (even if they already are). This results in unnecessary data being written to the block state database on almost every block. Instead, the reward details should only be updated when a change is actually being made. (Without this, the benefits of using HashedBufferedRef would likely be diminished, as much of the tree would be rehashed anyway.)

@td202 td202 added [Size] Small [Type] Change Request Some visible functionality should be change. [Type] Maintenance Cleanup or handling of technical debt. labels Dec 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Size] Small [Type] Change Request Some visible functionality should be change. [Type] Maintenance Cleanup or handling of technical debt.
Projects
None yet
Development

No branches or pull requests

1 participant