-
Notifications
You must be signed in to change notification settings - Fork 87
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
feat(conductor)!: rate limit sequencer cometbft requests #1068
Conversation
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.
Looks good - I'd have approved apart from my comment on the chosen rate limit's period.
); | ||
Ok(header) | ||
.inspect_err(|e| { | ||
warn!( |
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 used to be info-level before. Probably better as a warn-level, but just wanted to highlight that.
} | ||
}); | ||
// XXX: This number is arbitarily set to the same number os the rate-limit. Does that | ||
// make sense? Should the number be set higher? |
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 it probably does make sense since it should be at least the maximum number of concurrent requests the Buffer
will see, although I also can't see an issue with setting it higher (within reason).
50aa548
to
f0fecad
Compare
Rebased on top of main to fetch bump the charts (should have probably just made a merge commit) |
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.
infra approval
Summary
Limits the number of requests conductor sends to the Sequencer CometBFT endpoint to 100 per minute.
Background
During sync conductor can DOS Sequencer's CometBFT node by sending too many requests for commits and validator sets. With the batching logic introduced in #1049 there can be dozens (or more) blocks stored in each Celestia blob, each of which needs to be checked separately. With several blobs being fetched at once during, this can quickly spiral into hundreds (if not thousands) requests per minute.
Note that only calls to
/commit
and/validators
are rate limited, because there is currently no way to enforce this at the transport layer, see this issue: informalsystems/tendermint-rs#1420However, the only other calls are to
/genesis
(once at startup), and/abci_info
(every block-time period, usually every 2 seconds), which is rare enough to not need a rate limit.Changes
RateLimit
middleware around a tendermint-rsHttpClient
only send up to 100 requests per minute.Breaking changes
ASTRIA_CONDUCTOR_SEQUENCER_REQUESTS_PER_SECOND
to configure rate-limiting of requests sent to the Sequencer CometBFT node for verification of Sequencer block data fetched from Celestia blobsTesting
This needs to be observed end-to-end, potentially letting conductor run for a very long time with only soft commits, and then turning firm commits on.
Related Issues
closes #1064