perf(state-transition): reduce amount of withdrawals processed #2110
Conversation
|
Warning Rate limit exceeded@abi87 has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 6 minutes and 19 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. WalkthroughThe changes in this pull request focus on the Changes
Possibly related PRs
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
abi87
changed the title
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2110 +/- ##
==========================================
- Coverage 26.46% 26.07% -0.39%
==========================================
Files 357 360 +3
Lines 16155 16580 +425
Branches 12 12
==========================================
+ Hits 4276 4324 +48
- Misses 11609 11978 +369
- Partials 270 278 +8
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
📒 Files selected for processing (1)
- mod/state-transition/pkg/core/state/statedb.go (1 hunks)
🔇 Additional comments (1)
mod/state-transition/pkg/core/state/statedb.go (1)
246-262: LGTM! Performance optimization achieved.The changes successfully optimize withdrawal processing by:
- Eliminating unnecessary intermediate variables
- Reducing memory allocations
- Only processing withdrawals for eligible validators (fully or partially withdrawable)
This aligns well with the PR objective of reducing the amount of withdrawals processed.
Signed-off-by: nidhi-singh02 <trippin@berachain.com>
This reverts commit 099716d.
Signed-off-by: nidhi-singh02 <trippin@berachain.com>
Signed-off-by: nidhi-singh02 <trippin@berachain.com>
abi87
force-pushed
the
fix-maximum-number-withdrawals
branch
2 times, most recently
from
2778c79
to
09eee8e
Compare
| // TODO: hack to avoid failure of EL checks on withdrawals | ||
| if p.Withdrawals == nil { | ||
| p.Withdrawals = make([]*engineprimitives.Withdrawal, 0) | ||
| } |
There was a problem hiding this comment.
post Shangai an EL explicitly check that Withdrawals are not nil (instead empty slices are fine).
Currently BeaconKit duly builds a block with Withdrawals set to empty slice (if not withdrawals are available) but as soon as the block is returned by CometBFT for verification, the SSZ decoding sets the empty slice to nil.
This code change solves the issue.
abi87
force-pushed
the
fix-maximum-number-withdrawals
branch
from
765cc61
to
6dde55a
Compare
| @@ -131,11 +132,12 @@ func (sp *StateProcessor[ | |||
| } | |||
|
|
|||
| // TODO: Modify balance here and then effective balance once per epoch. | |||
| newBalance := min( | |||
| updatedBalance := types.ComputeEffectiveBalance( | |||
There was a problem hiding this comment.
fixing faulty merge conflict from previous merge
abi87
force-pushed
the
fix-maximum-number-withdrawals
branch
from
eb5bedc
to
6574f67
Compare
abi87
force-pushed
the
fix-maximum-number-withdrawals
branch
from
6574f67
to
3cfb23e
Compare
No need to process for withdrawal validators that are not fully or partially withdrawable
Note: this PR (and those built on top) seems to break once we update erigon from 2.60.1 to 2.60.9.
Geth seems to give the following error:
Note: keep on investigating with @dezzeus. It looks like withdrawals are duly set to an empty slice when the block is built, but as soon as the block is returned from consensus to middleware for verification, the slice is nil. SSZ serialization seems to be responsible for this. Investigation ongoing
Investigation ongoing
Note: found a solution: expliciting make Withdrawals slice when SSZ unmarshalling.