Skip to content

Add blob schedule support #15272

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

Merged
merged 8 commits into from
May 22, 2025
Merged

Add blob schedule support #15272

merged 8 commits into from
May 22, 2025

Conversation

terencechain
Copy link
Collaborator

@terencechain terencechain commented May 12, 2025

This PR adds blob schedule support from ethereum/consensus-specs#4277

Note to the reviewer:
MaxBlobsPerBlockByVersion is no longer safe to use after BPO, so it's better to remove it. Its only usage is in mev-boost to check that the number of blobs doesn't exceed the limit, and in that case, we can just pass the slot directly into the function.

@terencechain terencechain force-pushed the blob-schedule branch 2 times, most recently from 815868e to 787a904 Compare May 12, 2025 20:14
if len(bb.BlobKzgCommitments) > params.BeaconConfig().MaxBlobsPerBlockByVersion(version.Electra) {
return nil, fmt.Errorf("blob commitment count %d exceeds the maximum %d", len(bb.BlobKzgCommitments), params.BeaconConfig().MaxBlobsPerBlockByVersion(version.Electra))
if len(bb.BlobKzgCommitments) > params.BeaconConfig().MaxBlobsPerBlock(slot) {
return nil, fmt.Errorf("blob commitment count %d exceeds the maximum %d", len(bb.BlobKzgCommitments), params.BeaconConfig().MaxBlobsPerBlock(slot))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe can we set the result of params.BeaconConfig().MaxBlobsPerBlock into a variable to avoid double calls?

}

if v >= version.Electra {
case epoch >= b.ElectraForkEpoch:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the advantage to go from an if pattern to a switch pattern here?
As a personal taste, I find the if pattern clearer.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, do we still need those Deneb/Electra cases if they are already overwritten in blob schedule?
https://github.com/GabrielAstieres/consensus-specs/blob/7c5b431f40b71bedc2cc5a07a16d8be45d8abfe1/configs/mainnet.yaml#L196-L202

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think once there are more than two if statements, using a switch becomes cleaner. But I don't feel strongly about this nit, so feel free to overrule me if anyone has a strong preference.

I'm also not sure if we still need this, my only concern was someone running the latest Prysm version but loading an old mainnet YAML without a blob schedule, which could cause issues. This acts as a backup safety check that we can remove later if needed.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but thinking more even if loads an old yaml, the latest prysm version should still have blob version schedule as default, I think we are fine. Removing them now

@terencechain terencechain force-pushed the blob-schedule branch 3 times, most recently from 4442b1f to 84ab56e Compare May 19, 2025 15:32
@terencechain terencechain force-pushed the blob-schedule branch 2 times, most recently from 51bdd19 to da62dc6 Compare May 21, 2025 15:44
james-prysm
james-prysm previously approved these changes May 21, 2025
Copy link
Contributor

@james-prysm james-prysm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM i think might want to wait for manu?

nalepae
nalepae previously approved these changes May 21, 2025
nalepae
nalepae previously approved these changes May 21, 2025
if epoch >= b.FuluForkEpoch {
return b.DeprecatedMaxBlobsPerBlockFulu
if len(b.BlobSchedule) > 0 {
// Assume BlobSchedule is already sorted ascending by Epoch
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do you enforce this? That isn't a guarantee?

if epoch >= b.FuluForkEpoch {
return b.DeprecatedMaxBlobsPerBlockFulu
if len(b.BlobSchedule) > 0 {
// Assume BlobSchedule is already sorted ascending by Epoch
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this assumption is bad when we could implement a struct or something to reliably return the correct data, sorted or unsorted.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But that adds implementation complexity and comes at a cost.

My thinking is there's no real difference between using a config with completely wrong values and using one where the values are just in the wrong order. Either way, your code won’t work. If the blob schedule isn't sorted correctly, it’s just as bad as having invalid values, and the spec does require it to be sorted.

@terencechain terencechain added this pull request to the merge queue May 22, 2025
Merged via the queue into develop with commit 99cd90f May 22, 2025
15 checks passed
@terencechain terencechain deleted the blob-schedule branch May 22, 2025 03:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants