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.)
Currently, the
BakerPoolRewardDetailsare stored in an LFMBTree usingBufferedRefreferences: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.HashedBufferedRefshould avoid this.Related to this,
bsoMarkFinalizationAwakeBakersactually touches all of the entries inBakerPoolRewardDetailsfor 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 usingHashedBufferedRefwould likely be diminished, as much of the tree would be rehashed anyway.)