Restrict number of concurrent requests from conductor to sequencer #1064
Assignees
Labels
conductor
pertaining to the astria-conductor crate
Comments
github-merge-queue bot
pushed a commit
that referenced
this issue
May 27, 2024
## 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#1420 However, 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 - Use a tower `RateLimit` middleware around a tendermint-rs `HttpClient` only send up to 100 requests per minute. ## Breaking changes - Adds an environment variable `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 blobs ## Testing 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 --------- Co-authored-by: Jordan Oroshiba <jordan@astria.org>
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Conductor is DOSing sequencer during sync by requesting too many headers at once (to verify blobs).
The text was updated successfully, but these errors were encountered: