-
Notifications
You must be signed in to change notification settings - Fork 302
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
app: drop stateful mempool #4627
Conversation
Co-authored-by: dynst <148708712+dynst@users.noreply.github.com> Signed-off-by: Erwan Or <erwan.ounn.84@gmail.com>
0320b47
to
723b61b
Compare
Really solid work here. Especially grateful for the careful commenting throughout, as this work builds on a lot of recent and rather subtle refinements to the constraints on message sizes acceptable to the app. |
Not merging because review from @hdevalence is still outstanding. Once it's got final approval, @erwanor, let's use the new squash-with-commit-comments-preserved workflow we've been discussing to get it in! |
/// The maximum size of a CometBFT block payload (1MB) | ||
const MAX_BLOCK_TXS_PAYLOAD_BYTES: usize = 1024 * 1024; | ||
|
||
/// The maximum size of a single individual transaction (30KB). | ||
const MAX_TRANSACTION_SIZE_BYTES: usize = 30 * 1024; |
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.
Did we ever choose these in a principled way? Should they be parameters rather than hardcoded constants?
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.
This was picked with three things in mind:
- large enough to allow JIT liquidity for multiple pairs
- large enough to allow a ranged collection of positions
- large enough to allow multiple IBC client updates
- small enough to allow many of those actions to be performed in a single block even in the extreme case where each transaction is one of those things
Making them parameters make sense, I didn't do it because it would require more work with penumbra-governance
and hooking them into https://docs.rs/tendermint/latest/tendermint/consensus/params/struct.Params.html
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 we should consider making the constants be parameters, but I'm good to merge either way.
## Describe your changes During team sync today we decided that this new value is superior. ## Issue ticket number and link Follow-up to related work in #4614, #4627, and #4632. ## Checklist before requesting a review - [x] If this code contains consensus-breaking changes, I have added the "consensus-breaking" label. Otherwise, I declare my belief that there are not consensus-breaking changes, for the following reason: > This change does affect consensus and so should be treated carefully. Co-authored-by: Conor Schaefer <conor@penumbralabs.xyz>
Describe your changes
This is a draft PR that removes the stateful mempool from the application, replacing it with:
Checklist before requesting a review
If this code contains consensus-breaking changes, I have added the "consensus-breaking" label. Otherwise, I declare my belief that there are not consensus-breaking changes, for the following reason: