-
Notifications
You must be signed in to change notification settings - Fork 286
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
Export function to determine max blob bytes in a block #2108
Comments
I think the proposed function will return an upper bound for blob size but it won't be an exact maximum size due to the number of bytes occupied by the PFB tx. In other words, smaller blobs than this upper bound may also be invalid. We should consider fuzz testing by attempting to submit blobs of various sizes and confirming that blob sizes > the returned value from the proposed function(s) are never included in a block. |
Idea from @evan-forbes is for the first version of this to assume the default values for |
@rootulp, I am fine with such solution initially. Still, would be nice to think of the long term approach and if not complicated to aim to implement it first. The stateful approach is annoying, but we can keep it inside stateful blob.Service. It already imports chain state methods and can query any param on start and reuse it throughout its lifespan. At even later point, we may implement listening for param changes in runtime. |
Specifically https://github.com/celestiaorg/celestia-node/blob/main/blob/service.go ?
Does it already do this? Can you please link to an example? I'm not sure how celestia-node knows which major version of celestia-app it is connected to? |
My bad, I mean technically/in-theory can. It does not do this right now. The BlobSubmitter api can be extended with MaxBlobSize or something method that it could use. |
This was discussed with @rootulp synchronously, but I think the best approach here is to validate the size of the blob statelessly using validate basic, and then adding an antehandler that will check the tx size using the stateful parameters upon submission. This way we get protection locally before we even submit the blob, and then final protection at the mempool level that is stateful and complete |
I think we can close this issue as won't do in favor of #2156 |
Agree with the decision. Only wonderting how stateless verification would work then or how what error will it incorporate |
A stateless check on blob size can validate that the blob is < max blob size where max blob size is based on the upper bounds for max square size and max block bytes. |
Context
celestia-node would like to add a validation step on blobs that checks that the blob size does not exceed the maximum possible bytes that a single blob can occupy in a block.
Proposal
Export a function from celestia-app that informs celestia-node what is the maximum possible bytes in a block. The amount of data in a block is constrained by two parameters (see ADR-021):
MaxBytes
andGovMaxSquareSize
.Rough steps:
GovMaxSquareSize
andMaxBytes
. Note celestia-node has access to the celestia-app version but both these params are governance modifiable so they require a state accessGovMaxSquareSize
MaxBytes
cc: @Wondertan @renaynay @musalbas
The text was updated successfully, but these errors were encountered: