-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Add blob schedule support #15272
Conversation
815868e
to
787a904
Compare
api/client/builder/types.go
Outdated
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)) |
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.
Maybe can we set the result of params.BeaconConfig().MaxBlobsPerBlock
into a variable to avoid double calls?
config/params/config.go
Outdated
} | ||
|
||
if v >= version.Electra { | ||
case epoch >= b.ElectraForkEpoch: |
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.
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.
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.
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
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 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.
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.
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
4442b1f
to
84ab56e
Compare
51bdd19
to
da62dc6
Compare
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.
LGTM i think might want to wait for manu?
914164d
to
b78839f
Compare
b78839f
to
74300c2
Compare
config/params/config.go
Outdated
if epoch >= b.FuluForkEpoch { | ||
return b.DeprecatedMaxBlobsPerBlockFulu | ||
if len(b.BlobSchedule) > 0 { | ||
// Assume BlobSchedule is already sorted ascending by Epoch |
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 do you enforce this? That isn't a guarantee?
config/params/config.go
Outdated
if epoch >= b.FuluForkEpoch { | ||
return b.DeprecatedMaxBlobsPerBlockFulu | ||
if len(b.BlobSchedule) > 0 { | ||
// Assume BlobSchedule is already sorted ascending by Epoch |
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 this assumption is bad when we could implement a struct or something to reliably return the correct data, sorted or unsorted.
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.
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.
74300c2
to
3cba0d4
Compare
3cba0d4
to
c3966f1
Compare
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.