Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

This is part 3 of a series about IBC (interblockchain communication) token rate limiting. They have a nice dashboard that shows all of the rate limits on Osmosis. In this article, they attempt to make some improvements to IBC rate limits.

Right now, the rate limits must be approved via a governance proposal. This means that new tokens don't have limits and that's a bummer. So, they recommended including a default rate limit when it's a new token on chain. This PR is still open though.

The next issue they tackle is boundary attacks. The way that the rate limit is designed is using periods instead of a running time box. So, an attacker can transfer all of the tokens they can at the end of a period then a bunch more at the beginning of the period. The period is reset within the execution of a given transaction.

Instead, they recommend using a automatic period rollover for the rate limiting for A) security and B) usability. They implemented this by resetting the limit within the EndBlocker once the period has ended.

This is still susceptible to boundary attacks though. So, they have a two period averaging algorithm. The idea behind this is to calculate the average values of the capacity between two periods. They decided to add a decay on the earlier periods in order to make it more user friendly on UIs. Again, there is an open PR for both of these changes.

Another idea is to add notional value rate limits. However, this requires Oracles in order to do correctly, which has its own security risks. Depending on where the values are coming from, they can be manipulated or have times of volatility.

Having speed bumps or timelocks can allow for action to be taken. The same thing can be done for large transactions - simply delaying them for some static amount of time can allow for actions to take place.

To make life better for big parties, having conditional bypasses can be good as well. For instance, a sender based allowlist, transaction type or whatever else. However, doing this can open things up to an attack if they can be abused.

Overall, these seem good; it's awesome having it documented though. Wormhole has a rolling time period to prevent boundary issues. Additionally, there are notional values that are used from CoinGecko too. The research was good but it's a bummer that most of the PRs haven't been merged into the project.