Feature: support rate limits

[samlaf]

Creating this issue to discuss where is the best place to handle rate limits and backpressure in general.

With new op-batcher that supports concurrent dispersal requests (see https://github.com/Layr-Labs/optimism-exp/pull/3), we need to start considering how to make sure not to go over the disperser rate-limits if multiple blob requests are being sent in parallel.

We could add a rate limiter in the op-batcher code, but wondering if it wouldn't be best to add the rate limiter as part of the eigenda-proxy middleware. Probably could allow a buffer of requests to wait before dropping requests to put backpressure.

Pros:

• don't have to deal with rate limiting behavior in op-batcher. keeps implementation simpler because we can just use an errgroup to span goroutines

Cons:

• ?

[epociask]

• 1 to this idea - rate limiting within proxy directly will provide benefits to other rollup implementations. Also the rate limiting could be exceeded in other scenarios as well; e.g, if providers are using a single instance of proxy for communication between N number of sequencer nodes on a cluster or are using a single instance of proxy across heterogeneous rollup stacks at once.

[epociask]

Continuing this thread - how do we determine a customer's rate limit without having them specifying it manually? CC - @samlaf, @bxue-l2, @teddyknox

[samlaf]

Continuing this thread - how do we determine a customer's rate limit without having them specifying it manually? CC - @samlaf, @bxue-l2, @teddyknox

Honestly rethinking about this.. is it really needed? Feels like a simple exponential backoff should be enough? Prob not worth overcomplicating things unless absolutely needed?

[samlaf]

Closing as not planned. This is too complicated and not needed, at least for now. Can reopen if some customer is interested.