-
-
Notifications
You must be signed in to change notification settings - Fork 291
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
feat: decouple the deneb blob and block production #5492
Conversation
Performance Report✔️ no performance regression detected Full benchmark results
|
// Prune old blobSidecars for block production, those are only useful on their slot | ||
if (this.config.getForkSeq(slot) >= ForkSeq.deneb) { | ||
if (this.producedBlobSidecarsCache.size > 0) { | ||
for (const [key, {slot: blobSlot}] of this.producedBlobSidecarsCache) { |
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.
not related to this PR, why don't we have producedBlobSidecarsCache
with slot or block number as key so that we don't have to do a full scan here? I think we should have slot/block number in all of the consumer of the cache
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.
because its not re-org safe
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.
I mean we cache by slot, and then by block hash, and when we search we filter by slot first, then by block hash (I notice all of the consumers have slot).
it'd be easier to prune by slot
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.
hmmm can be done but sounds like an overkill since the freshest blobs are the most likely to be used in the proposal and are added to cache by increasing slot order, so pruning out by max naturally follows that order
add some breathing room reduce diff apply feedback use typeguards fix typo update comment
packages/types/src/deneb/sszTypes.ts
Outdated
signedBlobSidecars: SignedBlobSidecars, | ||
}, | ||
{typeName: "SignedBlockContents", jsonCase: "eth2"} | ||
); |
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.
Is this a spec'ed type? Types in packages/types
should exclusively include spec'ed types, which need merkleization and / or serialization. Else define in beacon-node package
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.
i think its just beacon-apis serialization type, might be useful in eventually supporting ssz encoded/decoded responses in api, but for now will move into beacon-api package itself and import/use from there 👍
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.
@dapplion have done some refactoring on this, let me know if you find it suitable now
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.
Looks great!
🎉 This PR is included in v1.9.0 🎉 |
As part of by parts integration of free the blobs PR
Update the blob and block production and signing flow as per the decoupled blob spec
implements: