-
Notifications
You must be signed in to change notification settings - Fork 200
Improve BFT resilience of BlockBuffer stores #8196
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
base: master
Are you sure you want to change the base?
Conversation
this should allow removing some type overhead in the BlockBuffer types
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
remove some ai-generated tests and adjust implementation and docs
it already exists in the compliance engine as well, but including in mempool provides stronger localized guarantee of behaviour
| // | ||
| //structwrite:immutable | ||
| type proposalVertex[T module.BufferedProposal] struct { | ||
| proposal flow.Slashable[T] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about caching the header to avoid overhead of calling the ProposalHeader() and additional functions in each call?
durkmurder
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🏅 This is great, I like it a lot, a clean implementation and a very useful concept.
This PR refactors the
PendingBlockBufferused by compliance engines to store disconnected blocks.Proposaltypes using generics (similar to Block)PendingBlockBufferusing generics, so we have one type-safe implementationPendingBlockBufferto useLevelledForestinstead of bespokebackendDropForParentIDmethod, becauseLevelledForesthas no parallel of this (it's a very minor memory optimization, and has the potential to drop unprocessed blocks in a concurrent environment)ActiveViewRangeSizeto thePendingBlockBuffer, which puts an upper limit on what views we will accept when adding blocks.SkipNewProposalsThreshold), however including it at thePendingBlockBufferlayer as well is inexpensive and provides a more isolated guarantee that the memory usage is bounded, so I was inclined to include it here as well.See #8170 for detail.
NOTE: Some of these changes (primarily the test suite) were done with AI (Cursor CLI - Composer 1). I marked commits which were substantially authored by AI with an
ai:prefix (just so you are aware -- I have reviewed them 😃).