Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
fix: reject BlobTxs larger than 2 MiB #4084
fix: reject BlobTxs larger than 2 MiB #4084
Changes from 8 commits
ab11446
bc55122
19b5053
9cad25d
bcbfc60
4350f35
4943be3
c4fc1f6
aa314e9
951e78b
826f56b
f0fca5b
cbd099a
0e99e30
5cddecc
8fd03d4
7b109bd
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
nit: Does the expected log really help if we now have error codes we can assert
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 guess it's redundant in check tx
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.
[question] why does this test case have to change?
Do we need to make the checkTx invocation versioned?
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.
CheckTx and PrepareProposal doesn't need version gating. please check me on this @evan-forbes
that needs to change because we want to hit ErrBlobsTooLarge ref #4084 (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.
we should be good not to version in this case yeah
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.
[uber nit] in some places we call the max tx size a "limit". In other places we call it a "threshold". It would be nice if we always referred to this with the same vocabulary.
In my opinion it would be sufficient to call it
MaxTxSize
and not use "limit" or "threshold" because the prefix "max" already conveys that.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.
5cddecc
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.
why not check sizes of PFBs since that's what we care about? This would also allow us to keep logic in antehandlers instead of making a special case and having to remember that we have this logic hidden in this function.
side note: in theory, a consensus breaking version would be handled in the
ValidateBasic
method since this is a stateless check on PFBs only. We can't do that now without also passing the app version to all validate basic methods, but we need to that eventually anyway ref #4088There 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.
@cmwaters suggested that we should reject encoded transactions directly if the size is over 2MiB. This makes sense to me since we care about transactions not being over limit not only the blobs right? because when this tx is getting gossiped it'd be encoded right?
I'm not sure we can change the AnteHandler in non breaking way. I see it as a temporary fix in place until we can clean this up and break things in v4.
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.
We could have the check in the antehandler, we would just need to have specific logic for the case of a PFB where we count the the blob sizes as well as the the tx bytes in the context.
Antehandlers aren't the only source of validation, we do a lot of blob specific validity checks outside the antehandlers
Having it prior to being unmarshalled is the simplest and most likely safest way to implement a max tx size limit. There is no custom logic based on specific messages
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'm good with putting the logic in umarshaling or an antehandler 👍 I still don't like the idea of not being able to version validate basic logic.
I think its already a block validity that everything must be decodable. do we pass the app version to the encoding and decoding logic?
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.
My view of validate basic was that it's a stateless (i.e. the function has no arguments). The app version is part of state. Having the app version being an argument to
ValidateBasic
seems incorrect (to me). The antehandler seems the right place to put version based checks inNo, the codec currently contains all types, thus types across all versions can be marshalled or unmarshalled.
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.
if we checking this in checkTx, we don't need to add it here too, correct?
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.
Yes I think so. In theory we should be able to remove this and rely just on
CheckTx
. There might be an edge cases when we change versionThere 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.
5cddecc