EPIC: Add IBC rate limiting mechanism

[adizere]

Summary

A rate limiting mechanism ensures that, intuitively, only a limited amount of value can flow between an IBC channel on the Hub and a counterparty network. By value we can mean different things: token value, number of transfers, number of transfers per signer, number of transfers or value per destination, for example.

Problem Definition

Why do we need this feature? What problems may be addressed by introducing this feature?

In conjunction with a circuit breaker mechanism (SDK feature), rate limiting can help temper the impact of certain security problems by preventing anomalous transfers of funds across networks. The BNB hack is an example of a problem that could have been alleviated by a rate limiter.

Are there any disadvantages of including this feature?

Development time, testing, configuration, and maintenance of the rate limiter module is not for free. Another disadvantage is that a misconfiguring a rate limiter can mean that legitimate user transfers might be prevented (i.e., the rate limiter could have false positives) and also means that not all types of attacks will be addressed (can have false negatives).

Context

Osmosis team already adopted a rate limiter implemented as a wasm contract and had a few iterations on refining/bug fixes (here, here for example) their solution.

I think the Hub team has 2 options:

1. Adopt the Osmosis solution, either partly or entirely.

   • Since it is CosmWasm-based, this implies the Wasm runtime or at least in a limited capacity. Maybe a shim layer (as the Strangelove team is trying to do with Wasm light clients) is possible towards deploying the Wasm rate limiter on the Hub, but needs investigation (cc @jackzampolin).

2. Re-implement the Osmosis solution as a Go module.

   • It seems the Stride team is planning to implement rate limiting in Go (cc @asalzmann) also, so a potential cross-team collaboration there is possible.
   • Update: Stride WIP PR kicked-off here: Rate limiter Stride-Labs/stride#492
   • Update: Stride PR implementing the ratelimit module IBC Rate Limiting Stride-Labs/stride#556

Resources

• The Informal team is preparing a specification of the Osmosis solution: https://github.com/informalsystems/interchain/blob/main/security/rate-limiter.md
• The Osmosis team did a very thorough job of documenting their module, including the rationale and a design discussion centered on configuration/parametrization: https://github.com/osmosis-labs/osmosis/tree/main/x/ibc-rate-limit

This issue is merely a signal. Most likely, it will need to be broken down into multiple sub-issues and tracked accordingly.

Task list

Must have

Beta Give feedback

1. decide on params for the rate limit module
2. put out a signaling proposal -- https://www.mintscan.io/cosmos/proposals/890
3. align with Stride on rate limit module implementation IBC Rate Limiting Stride-Labs/stride#556
4. IBC Rate Limit integration #3000
   type: feature-request +1
   
5. add rate limits cf gov proposal #3041
   +0
   

Nice to have

Beta Give feedback

No tasks being tracked yet.

[asalzmann]

Our golang solution (mostly implemented using the Osmosis spec) will be done in a few weeks. I think it might make sense to upstream it into ibc-go, because 1) it's an ibc middleware 2) I imagine lots of teams might want to use this. Thoughts @crodriguezvega ?

[ValarDragon]

Theres also an axelar implementation of ours (or a similar) rate limiter in golang as well.

[asalzmann]

@ValarDragon can you point me to the code?

[asalzmann]

@adizere our rate limiter is probably going to be merged in the next week or so. Please feel free to review

[adizere]

Thanks Aidan! Note the Informal team also reviewed the Osmosis solution and wrote an English spec for it (informalsystems/interchain#4).

Our golang solution (mostly implemented using the Osmosis spec) will be done in a few weeks. I think it might make sense to upstream it into ibc-go, because 1) it's an ibc middleware 2) I imagine lots of teams might want to use this. Thoughts @crodriguezvega ?

This is a good idea. Will also discuss this with the IBC-go team.
In the short term, the Gaia team needs this the most, so it makes sense to keep the conversation here for the moment.

[crodriguezvega]

@adizere our rate limiter is probably going to be merged in the next week or so. Please feel free to review

As soon as it gets merged we can add a link to it in ibc-go's registry.

[mpoke]

We should first put out a signaling proposal.

[mmulji-ic]

Doc in review, after ok, will put on forum.

[mpoke]

Closing this as completed. Stride's implementation of the IBC rate limit module will be part of Gaia v16.