Use StateRoot as Key for Cache #7540
Conversation
| } | ||
| if proposerIndices != nil { | ||
| return proposerIndices[state.Slot()%params.BeaconConfig().SlotsPerEpoch], nil | ||
| } | ||
| } | ||
| if err := UpdateProposerIndicesInCache(state, e); err != nil { |
There was a problem hiding this comment.
Should we move UpdateProposerIndicesInCache inside !bytes.Equal(r, params.BeaconConfig().ZeroHash[:]) as well?
| return nil, nil | ||
| } | ||
|
|
||
| b.lock.RLock() |
There was a problem hiding this comment.
i think the lock should be before b.state.StateRoots == nil? It's a read there
There was a problem hiding this comment.
True, although this is a general pattern in all our getters which in hindsight looks incorrect. I can fix it in another pr.
| return 0, errors.Wrap(err, "could not interface with committee cache") | ||
| } | ||
| if proposerIndices != nil { | ||
| return proposerIndices[state.Slot()%params.BeaconConfig().SlotsPerEpoch], nil |
There was a problem hiding this comment.
Perhaps a length check here, just to be extra defensive even if it is unlikely to happen
There was a problem hiding this comment.
@rauljordan I think there is sufficient length check above. We know that len(proposerIndices) is exactly SlotsPerEpoch so when we do slot%SlotsPerEpoch, we know that there cannot be out of bounds since the max value of that operation would be the last value in the slice.
… into changeCacheKey
Codecov Report
@@ Coverage Diff @@
## master #7540 +/- ##
==========================================
- Coverage 61.70% 61.68% -0.03%
==========================================
Files 424 424
Lines 29884 29925 +41
==========================================
+ Hits 18441 18459 +18
- Misses 8484 8496 +12
- Partials 2959 2970 +11 |
| @@ -348,9 +349,9 @@ func UpdateCommitteeCache(state *stateTrie.BeaconState, epoch uint64) error { | |||
|
|
|||
| // UpdateProposerIndicesInCache updates proposer indices entry of the committee cache. | |||
| func UpdateProposerIndicesInCache(state *stateTrie.BeaconState, epoch uint64) error { | |||
| // The cache uses the block root at the last epoch slot as key. (e.g. for epoch 1, the key is root at slot 31) | |||
| // The cache uses the state root at the last epoch slot as key. (e.g. for epoch 1, the key is root at slot 31) | |||
There was a problem hiding this comment.
This comment is still correct?
There was a problem hiding this comment.
Thanks will fix it tomorrow
| if err != nil { | ||
| return 0, errors.Wrap(err, "could not interface with committee cache") | ||
| } | ||
| if proposerIndices != nil && len(proposerIndices) == int(params.BeaconConfig().SlotsPerEpoch) { |
There was a problem hiding this comment.
I would argue that if length does not equal to slots per epoch, It should return an error here. The consumers should know why this fail and proposer cache is not working since there will be performance penalties
| return 0, errors.Wrap(err, "could not interface with committee cache") | ||
| } | ||
| if proposerIndices != nil { | ||
| return proposerIndices[state.Slot()%params.BeaconConfig().SlotsPerEpoch], nil |
There was a problem hiding this comment.
@rauljordan I think there is sufficient length check above. We know that len(proposerIndices) is exactly SlotsPerEpoch so when we do slot%SlotsPerEpoch, we know that there cannot be out of bounds since the max value of that operation would be the last value in the slice.
|
LGTM. We ran this PR in production environment for 12 hours without significant issue. |
What type of PR is this?
Feature Improvement
What does this PR do? Why is it needed?
Which issues(s) does this PR fix?
Other notes for review
cc @terencechain