fix: clone attestations for block inclusion #6174
Merged
Conversation
This file contains 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
g11tech
approved these changes
Dec 9, 2023
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## unstable #6174 +/- ##
=========================================
Coverage 80.02% 80.02%
=========================================
Files 19 19
Lines 1717 1717
Branches 155 155
=========================================
Hits 1374 1374
Misses 341 341
Partials 2 2 |
jeluard
reviewed
Dec 9, 2023
| if (i >= MAX_ATTESTATIONS) { | ||
| break; | ||
| } | ||
| // attestations could be modified in this op pool, so we need to clone for block |
There was a problem hiding this comment.
Nice one! I'm wondering if this could be tested somehow?
Also immutable data structure (à la immutable.js) could be considered if the cloning is identified as a perf issue (here or elsewhere).
There was a problem hiding this comment.
Nice one! I'm wondering if this could be tested somehow?
testing this requires setting up the pool and add attestations and produce blocks at the same time, I think it's not worth it. We do have a lot of unit tests for this file https://github.com/ChainSafe/lodestar/blob/unstable/packages/beacon-node/test/unit/chain/opPools/aggregatedAttestationPool.test.ts
Also immutable data structure (à la immutable.js) could be considered if the cloning is identified as a perf issue (here or elsewhere).
we only need to do the clone in this specific scenario, we do use immutable.js in this PR #6042 where it's really needed
There was a problem hiding this comment.
Makes sense!
Also might be clearer to just add the cloning part in the existing map, as map already returns a new array anyway. A matter of taste probably.
There was a problem hiding this comment.
Also might be clearer to just add the cloning part in the existing map
Yes I agree there. No need to be so much more verbose with named intermediate variables.
There was a problem hiding this comment.
clone() made the code a little bit slower, so I just want to use a single for loop to hopefully keep the same performance. There was already an issue with producing slow beacon block body #5793
Performance Report✔️ no performance regression detected Full benchmark results
|
|
🎉 This PR is included in v1.12.1 🎉 |
|
🎉 This PR is included in v1.13.0 🎉 |
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.
Motivation
After attestations are included for block, they could be modified by gossip, see
lodestar/packages/beacon-node/src/chain/opPools/aggregatedAttestationPool.ts
Line 251 in 8bd19f4
This lead to the produced block and the published block (the block we received in
publishBlockapi) could be differentDescription
Clone attestations to include for block